BAM Across Windows Versions: 1709, 1809, 11 and Server
Which Windows builds have BAM and DAM, where the key moved in 1809, what an upgraded host looks like, and what to check on Windows 11 and Windows Server.
TL;DR. No BAM before Windows 10 1709. On 1709–1803 it lives under bam\UserSettings; from 1809 (and on Windows 11) under bam\State\UserSettings. Upgraded machines can carry both, and the old key is frozen at upgrade time. DAM only records on Modern Standby hardware and, per Microsoft, isn't present on server SKUs. For Windows Server and the newest Windows 11 releases, verify on the image instead of assuming.
Version matters for two reasons: it tells you where to look, and it tells you how to read an absence. An empty result on Windows 7 means nothing; an empty result on a Windows 11 laptop that was in use all week deserves a question. Start with the BAM/DAM forensics guide if you're new to the artifact.
Version matrix
| Windows | BAM key | DAM key | Notes |
|---|---|---|---|
| XP, Vista, 7 | — | — | Use Prefetch, ShimCache, UserAssist |
| 8 / 8.1 | — | DAM driver exists on connected-standby devices | Microsoft documents DAM for Windows 8 (Learn); no forensic UserSettings records documented |
| 10 1507 – 1703 | — | — | BAM not yet introduced |
| 10 1709 – 1803 | Services\bam\UserSettings\<SID> | Services\dam\UserSettings\<SID> on Modern Standby | "Legacy" layout |
| 10 1809 – 22H2 | Services\bam\State\UserSettings\<SID> | Services\dam\State\UserSettings\<SID> on Modern Standby | Current layout |
| 11 | Services\bam\State\UserSettings\<SID> | same, on Modern Standby | Same layout as 10 1809+ in public documentation |
| Server 2016 | — | — | Based on 1607 |
| Server 2019 and later | Check | Not present on server SKUs per Microsoft | See below |
Sources: the 1709 introduction is recorded by Velociraptor's artifact documentation and early research by padawan-4n6; the 1809 move to State by kacos2000; Windows 10/11 availability by community references such as Psmths/windows-forensic-artifacts.
The 1809 move to State\UserSettings
According to kacos2000's notes, from Windows 10 1809 BAM "stopped updating" bam\UserSettings and writes to bam\State\UserSettings instead, while "old entries may still be found" in the old key.
What that means in practice:
- Tools that only read one path miss data. RegRipper's
bam.pl, for example, walks onlyState\UserSettingsin the current control set (see the tool comparison). On a 1803 image it would report the key as not found. - An upgraded host has two timelines.
bam\UserSettingsholds entries as they stood when the machine was upgraded;bam\State\UserSettingsholds current activity. Because BAM no longer writes there, those entries can be older than the seven-day window that normally limits BAM — a rare view of what users ran before the upgrade. We haven't found a public test of whether the boot-time cleanup still touches the old key, so treat its survival as something to observe, not to promise. - Label them. Our parser reads both layouts in every control set and marks legacy rows ("Legacy layout (Windows 10 1709–1803)" in the detail panel,
LegacyLayoutcolumn in exports). Don't merge them into the current timeline without saying so.
Windows 11
Public documentation of BAM on Windows 11 shows the same State\UserSettings layout and the same value format as Windows 10 1809+ (for example Psmths and the 2026 ElcomSoft registry overview). We have not found a primary source describing a change in retention or format in recent Windows 11 feature updates.
The honest position: the key and format are the same as far as published research goes, but the most detailed reverse engineering (Suhanov, 2020) was done on Windows 10 builds 18363 and 19592. Retention (seven days), the removable/network exclusion and the console-app quirk have not been re-published for Windows 11. If a finding hinges on one of those behaviours, test it on a reference VM with the same build as your evidence.
Windows Server
Two separate questions:
- DAM. Microsoft states that the DAM "is not present on server SKUs" (Learn). Don't expect
Services\damrecords on a server. - BAM. Windows Server 2019 shares the 1809 code base and Server 2022/2025 are newer (Windows Server release information), but we have not found an authoritative statement about whether BAM is active on Server SKUs. Check for
ControlSet00X\Services\bamin the image. If it's there with SID subkeys, use it; if it's missing, fall back to other artifacts.
This matters because servers are where Prefetch is often unavailable, so the execution-evidence toolbox is already thinner. Event logs (4688 with process-creation auditing, Sysmon) and Amcache become the main sources.
How to tell which build you're looking at
Offline, from the SOFTWARE hive:
SOFTWARE\Microsoft\Windows NT\CurrentVersion
ProductName, DisplayVersion (20H2+), ReleaseId (older), CurrentBuild
Rely on CurrentBuild rather than the product string: builds 22000 and above are Windows 11 (see Microsoft's release information for build numbers). From the SYSTEM hive alone, the BAM layout itself is a clue: only bam\UserSettings points to 1709–1803; State\UserSettings to 1809 or later.
Reading absence correctly
| Situation | Likely explanation | Next step |
|---|---|---|
No bam key at all | Pre-1709 Windows, or a Server build without BAM | Confirm build in SOFTWARE; use other artifacts |
bam exists, no SID keys | Freshly booted after a long idle period (7-day pruning), or tampering | Look at Volume Shadow Copies; check key last-write time |
| Your suspect SID missing, others present | The account ran nothing locally recently, or only from removable/network paths | Check Prefetch, Amcache, SRUM |
dam empty or missing | Not a Modern Standby device | Normal on most desktops |
For every item in the last column, the limitations and anti-forensics article has the details. And for the parsing itself, the BAM/DAM Parser handles every layout above automatically; the how-to shows the workflow.
Frequently asked questions
Which Windows versions have BAM?
Windows 10 from version 1709 (Fall Creators Update) onward and Windows 11. Earlier Windows versions have no bam service key. On Windows Server, check the image for a Services\bam key rather than assuming.
Why does my hive have both bam\UserSettings and bam\State\UserSettings?
The host was upgraded from Windows 10 1709–1803. From 1809 BAM writes to State\UserSettings and the old key is no longer updated, but its entries can remain as a snapshot from before the upgrade.