What a Windows 11 feature update does to forensic evidence

A host upgraded during the period of interest reads as clean. I met this on a case. The subject's laptop had no Prefetch, no Amcache, no event log and no USB history older than one particular morning a few weeks before collection, and every one of those sources parsed without error. Every EVTX file, the NTUSER.DAT and UsrClass.dat of every profile, and the profile folders themselves had been created that morning.

My first reading was a reinstallation, with the user's data put back from a backup afterwards. A closer look showed an in-place Windows 11 feature update instead, and three things separated the two:

• The SYSTEM hive held a Source OS key. Setup writes one at the start of every upgrade, as a copy of the old system's CurrentVersion key; a clean install has no old system to copy.
• The user's LNK files, jump lists, documents and DPAPI keys were the original MFT records, created up to 17 months before that morning. A restore from backup writes new records whose $FILE_NAME creation time is the day of the restore, whatever $STANDARD_INFORMATION says.
• The new system's own folders carried the signature of Setup's swap: an install-image creation time, and $FILE_NAME values left by a rename into the volume root (both explained below).

What the published DFIR material says about upgrades fits in four sentences: the install date resets, the event logs are recreated, USB keys are cleared, and the old system sits in Windows.old for a while. All four are true. None of them tells an examiner which sources can still answer a question about the time before the upgrade, how far back each one reaches, or which timestamps the upgrade itself has falsified.

This Field Note answers those three questions with measurements. It covers every file, folder and registry location my timeline collection reads, plus the ones investigators reach for by hand, measured record by record on the MFT and key by key inside the hives, with the mechanism behind each effect.

The short version

The loss is selective and predictable. Setup builds a new operating system, moves selected parts of the old one into it, and rebuilds the rest. Three fates cover almost every source:

• Rebuilt, so empty before the upgrade: Prefetch, PCA, BAM, every EVTX log, the setupapi device logs, the live USBSTOR, USB and MountPoints2 keys, scheduled task files and their TaskCache keys, and the WMI repository.
• Replayed into new hive files, with write times reset: UserAssist, RecentDocs, ShellBags and the Office MRU. Their content survives, and so do the timestamps stored inside UserAssist and Office MRU values.
• Moved across with history intact: jump lists, LNK files, Office MRU caches, browser history and cookies, SRUM, the Search index, Windows Timeline, the notifications database, DPAPI keys, Credential Manager, Outlook stores, the Recycle Bin and user data.

Two registry stores keep device and network history that the rebuilt keys lost: DeviceMigration and NetworkList. On the case host, DeviceMigration still listed four USB storage devices that the live USBSTOR key had forgotten.

The upgrade also plants two timestamp traps. Operating system files carry a creation time copied from the install image, identical to 100 ns on unrelated hosts, which makes every timestomping rule fire. And on the case host the offline phase wrote local time as if it were UTC, which placed the rebuilt user profile before the system it runs on.

What was measured

Three hosts, all upgraded into Windows 11. The sources inventory comes from the 48 artifacts of my Velociraptor timeline collection, extended with the locations investigators check by hand: PSReadLine history, thumbnail caches, the RDP bitmap cache, the WMI repository, BITS, Defender history and quarantine, DPAPI, Credential Manager and shadow copies.

Dates in this Field Note are relative to each host's upgrade, which I call the swap. Times of day are given only where an order of events depends on them.

What happens to each source

Every classification comes from the MFT records a source consists of. A record created by the upgrade cannot hold history from before it; a record that existed before it can. The column "reaches back" gives the oldest surviving record on Host A, which bounds how far that source can still answer questions. Where Host B behaved differently, the row says so.

Execution evidence

Every execution artifact except SRUM starts on the upgrade day on Host A. Amcache is the one source whose fate differed between hosts.

Event and text logs

All 241 EVTX files on Host A were created at the new system's first boot or later. 199 of them share one second, the moment the new event log service started.

Machine registry

Every hive file on the volume is a new record created by the upgrade. Inside them, the device and execution keys start at the swap, while two stores carry older history in timestamps stored inside their values.

For a removable media case, DeviceMigration is the surviving record. The four USB storage devices it holds on Host A (a WD Elements drive, a SanDisk 3.2Gen1 stick and two generic mass-storage instances) appear nowhere else on the live system. The key sits at HKLM\SYSTEM\Setup\Upgrade\Pnp\CurrentControlSet\Control\DeviceMigration. Its key write times belong to Setup; only the LastPresentDate values date the devices.

File access and user activity

File-based user activity survived in every profile that had it. The subject's profile directory and both hives on Host A are records created at the swap, yet 386 Recent LNK files, 57 jump lists and 133 Office MRU cache files moved into it, reaching back about 17 months.

Persistence and credentials

The registry replay: content kept, write times reset

Per-user activity keys are copied into brand new hive files, and every copied key gets the time of the copy. On Host A every BagMRU key in the subject's UsrClass.dat carries the same LastWriteTime, six minutes after the new kernel started. A timeline built on key write times shows a burst of user activity at the moment of the upgrade that never happened.

Host B proves the mechanism, because Windows.old kept the old hives. I read each key family from both hives with the raw registry accessor and compared entries.

UserAssist and the Office MRU are the two registry sources that still date activity before an upgrade. Their values embed their own run and open times, and the copy is byte for byte. On Host A the subject's UserAssist keeps 64 run times from before the upgrade, reaching back 17 months, and the Office MRU keeps 108. Every other replayed key tells you what was used, not when.

The list of dropped families matters as much as the carried one. Open and Save dialog history, typed Explorer paths and Explorer search terms are the keys that show a user deliberately navigating to something, and they are the ones the migration does not carry.

Four timeline traps

1. The install image stamps its own creation times

The $STANDARD_INFORMATION birth of an operating system file identifies the install image, not the host. C:\Windows and C:\Users carry the $SI birth 2024-04-01T07:21:16.1844348Z on all three hosts, identical to 100 ns, and on Host B so do System32, WinSxS and the config folder. A value that precise, on unrelated machines, can only come from the media.

The bulk of the files carry their own stored times. On Host B, 115,875 of 117,356 new files under C:\Windows have an $SI birth that differs from their $FN birth, spread over 177 distinct seconds on two days: 1 April 2024 and 6 June 2026, the two build dates inside a 25H2 image. A timeline sorted by $SI birth places the upgrade's files two years in the past.

WIM images store per-entry timestamps at 100 ns, and the open reference implementation, wimlib, restores them on apply. No Microsoft page states that Setup does the same; the measurements say it does.

2. Every timestomping rule fires

On Host A, 56,958 records have an $SI birth earlier than their $FN birth. That is the pattern every timestomping detector flags, and it is consistent with Setup creating each file and then restoring the image time through the API. Exclude image-stamped records from anomaly rules on any upgraded host, or the one real case of timestomping will sit under fifty thousand false ones.

The inverse rule fails too. 2,335 new records on Host B carry the image time in their $FN birth as well, C:\Windows among them, because they were renamed after being stamped. "$FN birth before the upgrade" is therefore not proof that a record is old. On Host B the two image days never occur on the Windows 10 side (0 of 388,246 Windows.old records), which is what makes them usable as a marker.

3. The offline phase wrote local time as UTC

On Host A, every record written during the Safe OS phase is three hours ahead of true UTC, which is exactly the host's offset. Four measurements establish it:

1. The host runs at UTC+3 with its hardware clock in local time: the TimeZoneInformation key has a bias of -180 and no RealTimeIsUniversal value.
2. The new system logged its first kernel start (Kernel-General event 12) and its event log service start (EventLog 6005) with correct UTC times.
3. No record carries a stored time later than the kernel start plus three hours. System32 has to exist before the new kernel can boot, so its stored creation time, 2 h 45 min after the kernel start, cannot be true UTC.
4. No record carries a true-clock time in the 15 minutes that the shifted cluster fills. The last true-clock write is SRUM's final update of the old system.

The only clock change logged around the swap is a two-second adjustment the next day, so the clock was never wrong. The offset comes from how the offline environment read it. Microsoft's WinPE team documented the mechanism in 2007: Windows keeps the hardware clock in local time, and NTFS computes UTC "by subtracting the timezone offset from the local time in the BIOS clock", so a WinPE image with the wrong time zone writes wrong NTFS times.

Uncorrected, Host A's timeline shows the user profile being rebuilt 2 h 45 min before the system files it depends on. Corrected, every step falls into Microsoft's documented phase order. On a host west of UTC the offline records would read earlier than true UTC, not later.

Host B has no shift, and Setup's own log explains why. It reads "Got SafeOS boot removal OneSetting: TRUE". Setup skipped the Safe OS boot and ran every offline step while Windows 10 was still running, so no record was written by WinPE. Whether a given upgrade shifted its records therefore depends on whether it booted into Safe OS, and Setup's log is where that is recorded.

4. "The upgrade time" is not one moment

On Host B the new operating system was laid down 45 minutes before the reboot, while Windows 10 was still running. 128,995 records, the new C:\Windows tree, the Windows components of Program Files and the new hives, were born in a 13-minute window long before the machine restarted. The user profiles were recreated in the offline apply, also before the reboot. A timeline that anchors "upgrade" on the reboot misplaces all of it.

How Setup swaps the operating system, seen from the MFT

Microsoft documents four phases: Downlevel, SafeOS, First boot and Second boot. It does not document how the new system replaces the old one on the volume. The MFT records it, once you apply the rules for when NTFS rewrites $FILE_NAME times.

The rules come from two peer-reviewed studies, Galhuber and Luh (2021) and Bouma et al. (2023): NTFS writes $FN only when an object is created, renamed or moved, and a rename or move copies the $SI values from just before the operation into $FN. Renaming a parent never rewrites its children's $FN, because a child refers to its parent by record number. With those rules, Host A's volume reconstructs the swap in five steps.

1. Staging, 12 to 13 days before the swap. Downlevel built a staging tree in fresh MFT entries above the old high-water mark; 431,641 of those records are now deleted. The Source OS key dates the start of this phase.
2. Lay-down, 15 minutes. SafeOS created 121,792 records. C:\Windows sits in an MFT slot the staging deletion freed, with sequence number 2, so it is a new allocation, not the old folder.
3. Stamping. Setup overwrote the $SI birth of most new records with the time stored in the image (trap 1).
4. Rename into the root. C:\Windows, C:\Users, C:\Program Files and C:\ProgramData carry the image time in their $FN birth and swap-day times in their other $FN fields. Under the rename rule that combination arises only when an object is created, stamped, then renamed or moved. The top-level folders were built elsewhere and renamed into the root, while their children kept their creation-time $FN. On Host C an undocumented value, HKLM\SYSTEM\Setup!UPGOldOsPieces, lists the old pieces moved aside: Windows, Program Files, Program Files (x86), Users, ProgramData, inetpub, SkyDriveTemp and $WinREAgent.
5. First and second boot. The new kernel started 26 seconds after the last rename. The event logs appeared 24 seconds later, the new profile and hives under a minute after that, the per-user registry apply six minutes in, and the install date was written nine and a half minutes after the kernel start.

Host B records the same sequence with Setup's log as the clock:

Nothing was written in the 32 seconds between the last record of the old system and the first record of the new kernel.

Enablement packages leave the volume alone

Microsoft describes an enablement package as "a small, quick-to-install 'master switch'" over features already installed, and states that 24H2 "is a full OS swap so it isn't available as an enablement package". Host C's 25H2 enablement package left no trace on the volume: its top-level folders still carry the 24H2 image time, BuildLabEx still names the 24H2 build while CurrentBuild reads 26200, and its only Source OS key dates the earlier media upgrade. The effects in this Field Note apply to in-place feature updates that swap the operating system, not to enablement packages or monthly cumulative updates.

Where this design comes from

The swap measured above is a design Microsoft has refined for almost twenty years, and it was last described in public in 2011. Each generation changed where the old system goes and how much of it comes back, and each change moved evidence.

Vista: setup becomes an image

Windows Vista replaced the old file-copy installer with image-based setup: a new setup program "performs the installation, applying a Windows Vista image" from a WIM file, and WIM images "are file-based, enabling them to be applied to an existing partition non-destructively" (Michael Niehaus, TechNet Magazine, 2006). Windows.old existed from this era, created by a custom install over an older Windows on the same drive.

Windows 7: a transport, and a gather in Windows PE

Microsoft's own account of the Windows 7 upgrade comes from the Building Windows 8 team in 2011. Setup preserved applications and user files "by moving each file to a transport location", two folders named Windows.~q and Windows.~tr, then moving them back. Registry values were gathered while the old system was still running, and file content "was then gathered offline during the Windows Pre-Installation Environment (Windows PE) phase". Upgrade time grew with the number of files: Microsoft's own chart timed a PC with 1.44 million files at 513 minutes.

Windows 8: Windows.old becomes the transport

The same post describes the redesign that still shapes the volume today. Microsoft "repurposed the 'Windows.old' naming convention" as the single transport, and instead of copying files out, Setup moves whole folders into Windows.old: Windows, Program Files, Program Files (x86), Users and ProgramData. Files were linked rather than moved ("in upgrades to Windows 8, we use hard link operations instead"), the downlevel gather was dropped because "everything we need to preserve can be extracted from the Windows.old folder", and Windows.old was deleted automatically four weeks after a successful install.

That is the folder list Host C's UPGOldOsPieces value still records, and it is why the top-level folders on an upgraded volume carry rename signatures in their $FN attributes. The design is fourteen years old; the MFT on a 2026 Windows 11 host still shows it.

Windows 10: feature updates, shorter windows, less time offline

• Every feature update became a full in-place upgrade in four phases, with a SafeOS phase in which the PC "is booted into Windows PE" and "an OS rollback is prepared if needed".
• Version 1607 cut the rollback window from 30 days to 10; Microsoft said it "changed the setting to 10 days to free storage space".
• Version 1803 added the DISM commands that set that window, and moved "portions of the work done during the offline phases" to the online phase. Microsoft's figures reported at the time put average offline time at 83 minutes for 1703, 51 for 1709 and 30 for 1803.

Windows 11: full swaps and switches

Windows 11 alternates between the two paths. 24H2 "is a full OS swap", while 22H2 to 23H2 and 24H2 to 25H2 are enablement packages that share "an identical set of system files" and need "a single restart". Setup can also skip the Safe OS boot entirely: Anoop Nair documented physical machines that "skipped the Safe OS phase" under a setting called NEO, and Host B's log records the same decision. Microsoft has not documented it.

Two things this history does not settle. No current Microsoft page says whether Windows 10 and 11 still link files into Windows.old or move them. Host B answers it for its end state: collected 20 minutes after Setup finished, the control records show carried files with no copy left inside Windows.old, and rebuilt files with their old copy there. And no source describes how the per-user registry is replayed into new hives; the measurements in the registry section are, as far as I can find, the first public description of what that replay keeps and drops.

Windows.old, and what outlives it

Windows.old holds a complete copy of every source the upgrade rebuilt, for 10 days by default. The window is configurable from 2 to 60 days with DISM /Set-OSUninstallWindow. On Host B, collected inside the window, it returned 233 Prefetch files reaching back five years, 398 event logs, 14 setupapi logs, the five machine hives and each profile's old NTUSER.DAT and UsrClass.dat.

The Windows.old hives are the state at shutdown, not a snapshot from before Setup started. Windows 10 kept running for 46 minutes of the upgrade and kept writing: 68 of 83 BAM entries in the old hive were written during the upgrade window. Setup also wrote the DeviceMigration store into the old SYSTEM hive during its gather phase, so that store, read from Windows.old, was created by the upgrade too.

On Host B Setup moved its own working folder, including the Panther logs of the upgrade, into Windows.old. The upgrade's own record there lasts exactly as long as Windows.old. Setup's log also records the step "Remove System Restore checkpoints", so restore points that existed before the upgrade are deleted by it.

After the window, the old system survives only as deleted MFT records. On Host A no pre-upgrade copy remained: Windows.old was gone, and the oldest Volume Shadow Copy store was created four days after the swap. A complete whole-volume carve, 2 h 38 min on a 931 GiB NVMe drive, recovered no Prefetch file or event log from before the upgrade. Every carved Prefetch run time postdates the swap. The E01 set was 194 GiB for 244 GiB allocated, so the unallocated space was stored as zeros, which is the signature of blocks the drive had discarded through TRIM.

The MFT is the exception, because TRIM does not touch it. Recycle Bin $I records are small enough to live inside the MFT record, and the carve's MFT phase returned 63 of the subject's deletions from before the upgrade, each with its original path, size and deletion time, reaching back 17 months. 32 of them are Word AutoRecovery files deleted within the same two seconds.

Six rules for an examiner

1. Establish whether and when the host was upgraded before reading any absence as a finding. The Source OS keys under HKLM\SYSTEM\Setup, InstallDate, BuildLabEx against CurrentBuild, and the $FN birth of each NTUSER.DAT answer it.
2. Treat the upgrade as a hard floor for Prefetch, PCA, BAM, EVTX, setupapi and scheduled tasks, and for the write time of every per-user registry key. Report absences before that floor as "not recorded", not "did not happen".
3. Take pre-upgrade USB and network history from DeviceMigration and NetworkList, dated by the values inside them, not by key write times.
4. Reach behind the upgrade with the carried sources: jump lists, LNK files, browser stores, SRUM, the Search index, Windows Timeline, the Recycle Bin, and the embedded times in UserAssist and the Office MRU.
5. Collect Windows.old and $WINDOWS.~BT while they exist, with the same artifact set as the live system, and check shadow copies for any store inside the retention window. When they are gone, carve deleted MFT records.
6. Correct offline-phase records by the host's UTC offset when Setup booted into Safe OS, and never read the $SI birth of a system file as a host event.

Open questions

Four effects are measured on these hosts and not yet generalized. Whether ShimCache carries entries from before the upgrade inside its rewritten value. Whether the WMI repository keeps event subscriptions. Why Amcache was carried on one host and rebuilt on the other. And whether the local-time shift reproduces at other offsets, which Host C, upgraded at UTC+1, should show. I will update this Field Note as each one is settled.

References

Earlier DFIR work on upgrades documented the consequences. Credit where it is due: each of these was first to publish its finding.

Prior DFIR research

• az4n6, When Windows Lies (InstallDate and event logs reset by the 1607 update)
• Magnet Forensics, USB history in the Windows.old SYSTEM hive
• Ilya Kobzar, Windows updates and anti-forensics, part 1 (USB artifacts and DeviceMigration)

NTFS timestamp rules

• Bouma, Jonker, van der Meer and van den Aker, Reconstructing Timelines: From NTFS Timestamps to File Histories (ARES 2023)
• Galhuber and Luh, Time for Truth: Forensic Analysis of NTFS Timestamps (ARES 2021)
• wimlib-imagex-apply: timestamps restored at 100 ns on apply

History of the upgrade design

• Michael Niehaus, image-based setup in Windows Vista (TechNet Magazine, 2006)
• Building Windows 8, Improving the setup experience (2011): the Windows 7 transport and the Windows 8 redesign
• Petri, the rollback window cut from 30 to 10 days in 1607 (2016)
• What's new in Windows 10, version 1803: offline work moved online, DISM uninstall commands
• Computerworld, offline time from 1703 to 1803 (2018)
• Anoop C Nair, the in-place upgrade process, NewOS staging and NEO (2024)

Microsoft

• WinPE team, Daylight Savings Time in WinPE (2007)
• Windows upgrade issues troubleshooting: the four Setup phases
• Windows upgrade log files
• DISM operating system uninstall options: the 2 to 60 day window
• KB5054156, the 25H2 enablement package
• What's new in Windows 11, version 24H2: a full OS swap