The folders that look like corruption: Panther, $WINDOWS.~BT and $WINDOWS.~WS after a failed feature update

A fleet-wide disk-space alert fires. Someone opens File Explorer on the worst offender, switches on hidden items, and finds two folders sitting in the root of C: that look like the aftermath of a crash: $WINDOWS.~BT and $Windows.~WS. Dollar sign, tilde, truncated names. Everything about them reads as corruption.

They get deleted. The space comes back. Two days later the same device rolls back a feature update for the third time, the ticket escalates, and the only copy of the evidence explaining why is gone.

Those folders are not corruption. They are Windows Setup's working directories, and together with C:\Windows\Panther they are where every log that explains a failed in-place upgrade actually lives. Microsoft documents them — just not in the place most admins look.

This post is the layout: what each directory is, when each one exists, which log lands where at which phase of Setup, what survives a rollback, and how long you have before Windows takes it away. Then how to collect the whole set read-only for a support case, without touching a single byte of it.

The problem: the evidence lives in folders that look like junk

The symptom of a failed in-place upgrade is almost always the same. The device spends an hour on Working on updates, reaches somewhere past halfway, then announces that it is undoing changes and boots back onto the build it started from. Windows Update reports the feature update as failed, usually with 0xC1900101.

Microsoft is explicit that 0xC1900101 is not a root cause. It "is generic and indicates that a rollback occurred", and the guidance is to analyse the extend code to find which phase failed. That analysis happens in log files. There is a registry verdict and an event, and both are covered below — but neither survives as reliably as the files, and neither tells you why.

Which is where the folders come in. On a device that has been through Setup you can find any of these in the root of the system drive, all hidden:

Read from a live Windows 11 25H2 device (build 26200.9168). Only the entries marked as present were actually there — the others are listed because they are what people find and misidentify.

The naming is genuinely awful, and it is inconsistent even on disk. On the lab device the directory listing came back as $WINDOWS.~BT in full caps but $Windows.~WS in mixed case. Microsoft's own documentation writes it three ways across different articles — $Windows.~BT, $Windows.~bt and $WINDOWS.~BT. Any script that compares these names case-sensitively will miss them.

The first command on a suspect device should therefore never be a cleanup. It should be an inventory that changes nothing.

Two things in that output matter more than they look. Hidden explains why nobody has ever seen these folders. NotContentIndexed explains why searching the drive for setupact.log comes back empty even when four copies of it are sitting there.

On the lab device the owner of both working directories was BUILTIN\Administrators, while C:\Windows\Panther was owned by NT AUTHORITY\SYSTEM. That matters for collection: you can read Panther as an admin, but a plain file copy of some of its contents needs the backup privilege, which is covered further down.

Why it happens: four phases, four working directories

The layout stops looking arbitrary the moment you know how Setup executes. Microsoft's description is blunt: "the upgrade process consists of four phases that are controlled by Windows Setup: Downlevel, SafeOS, First boot, and Second boot. The computer will reboot once between each phase." A fifth phase, Uninstall, "occurs if upgrade is unsuccessful".

Now the directories make sense. The down-level phase runs inside the old operating system. It cannot log into the new C:\Windows, because the new C:\Windows does not exist yet. So Setup creates its own workspace on the system drive and logs there.

Microsoft states the location directly: "During the upgrade process, Windows Setup extracts all its source files, including SetupDiag.exe, to the %SystemDrive%\$Windows.~bt\Sources directory." Everything the upgrade needs — the setup host, the setup platform, the diagnostic tool, the image — lands under there. Its log subdirectory is Panther.

The lab device confirms it from Setup's own mouth. The first lines of a real down-level setupact.log print the paths the host chose:

That header is the single most useful block in the whole directory. It tells you the working root, the log root, the source of the image and the exact command line that started the run — before you have read a single error.

Down-level Panther versus the post-upgrade Panther

Once the new OS boots, logging moves. Microsoft's log table places the post-upgrade setupact.log at Windows\Panther, described as "information about setup actions during the installation", to be used to "investigate post-upgrade related issues". The same directory holds miglog.xml, which "contains information about what was migrated during the installation".

So there are two distinct Panther directories and they are not interchangeable:

• C:\$WINDOWS.~BT\Sources\Panther — written by the old OS, before the first reboot. Small. This is where a device that never got past the down-level phase leaves its only trace.
• C:\Windows\Panther — written by the new OS, during and after the install. Large. This is the record of a run that actually got somewhere.

"Large" is not a figure of speech. On the lab device, whose last real in-place upgrade completed on 15 March 2025:

A 547 MiB single-file setupact.log is a real constraint. It will not open in Notepad in any useful time, and it is the reason Microsoft's own advice is to "review the entries in the Setuperr.log file first, then the Setupact.log file second". Nine kilobytes of errors beats half a gigabyte of information.

The rollback directories

Rollback gets its own space, and Microsoft names two locations for it. The down-level rollback log is at $Windows.~BT\Sources\Rollback, holding "information about actions during rollback" and used for "investigating generic rollbacks - 0xC1900101". Alongside it sit the supplemental rollback artefacts: Setupmem.dmp, setupapi.dev.log and event logs (*.evtx).

Setupmem.dmp is worth knowing by name. Microsoft: "if the bug check occurs during an upgrade, Windows Setup extracts a minidump (setupmem.dmp) file", created "in either %SystemDrive%\$Windows.~bt\Sources\Rollback, or in %WinDir%\Panther\NewOS\Rollback depending on when the bug check occurs". If an upgrade bugchecks, that file is your dump — and it will not be in C:\Windows\Minidump.

The second rollback location, C:\Windows\Panther\Rollback, is the one nobody talks about, and it is the most interesting directory on the disk. It is not a log folder. It is a snapshot of the machine's pre-upgrade boot and servicing state, kept so the uninstall path has something to restore from. On the lab device:

Read that as a design, not a list. Setup preserved 26.6 MiB of the previous EFI boot files — boot manager, BCD, code-integrity policies, boot fonts — so a rollback can put the old boot path back exactly. It preserved a Kernel Transaction Manager log set for Component-Based Servicing, so a half-applied servicing transaction can be unwound. And it kept the SafeOS-phase setupapi.offline.log, which is precisely the log Microsoft points you at for driver-install failures during the offline servicing sub-phase.

LogRestore.TXT is 62 bytes of UTF-16 and its entire content is one path: \$WINDOWS.~BT\Sources\Panther. It is a note Setup left itself about where to restore logs from. That single file is the clearest possible statement that the working directory and the Panther tree are two halves of one mechanism.

The rollback plan itself is readable. rollbackinfo.ini on the lab device carries the boot-entry GUIDs for the down-level OS, the rollback entry and the new OS, a [Quarantine.WinOld] section naming Windows.old, and a [Quarantine.NewPaths] list of exactly the six top-level directories Setup intends to swap:

What $Windows.~WS actually is, and what Microsoft does not say

Here the honest answer matters. $Windows.~BT appears by name in Microsoft's upgrade log tables, in the SetupDiag article and in the setup memory-dump guidance. $Windows.~WS appears in none of them. There is no Microsoft product documentation that defines it, states its layout, or says what the letters stand for. The only Microsoft-hosted mentions are community answers on Microsoft Q&A, which are not product documentation.

What can be established without guessing is that it is a genuine Setup working directory with the same internal shape — because a Microsoft-signed Setup binary prints its path and complains about it. From the lab device's own $Windows.~WS error log:

Note the phrase ExecuteDownloadMode. On the lab device the $Windows.~WS logs are timestamped 08:25 to 08:28 and the $WINDOWS.~BT logs 11:24 — same day, three hours earlier. $Windows.~WS also contains Eula.rtf, which an install pass has no reason to stage. The ordering and the contents both say: download and staging first, install second.

One further clue sits in the same file: another failing object in that directory is named CDlpActionGetWebSetupUserInput. "Web setup" is suggestive of what the WS might stand for. It is not confirmation, Microsoft has never stated it, and this post is not going to assert it. Treat $Windows.~WS as an undocumented-but-real Setup working directory that carries a Sources\Panther log set worth collecting.

How to verify: read the directories in phase order

The published mapping is the spine of the whole diagnostic. Here it is in the order you will walk it, with the paths as Microsoft writes them.

Paths from Microsoft's upgrade log-files table, the SetupDiag article and the Windows Setup log-files reference. One caveat from the real device: on disk the folder is NewOs, not NewOS. Case-insensitive on NTFS, but worth knowing if you are string-matching output.

The decision path

Work these in order. Each step either explains the failure or hands you the next directory.

1. Did Setup even start? Check C:\Windows\Logs\Mosetup\BlueBox.log. It records the handoff between setup.exe and Windows Update, and its first lines name the build and the command line that launched the attempt. No BlueBox entries for the date in question means the run never reached Setup.
2. Was there a download or staging pass? If C:\$Windows.~WS\Sources\Panther exists, read its setuperr.log. Failures here are transport failures — BITS, media, offer selection — and they happen before any system change.
3. Read the down-level header. Open the first twenty lines of C:\$WINDOWS.~BT\Sources\Panther\setupact.log and record LoggingPath, CmdLine, Mode and Scenario. This tells you what kind of run you are debugging before you debug it.
4. Read errors before actions. setuperr.log in the same directory, then the matching setupact.log. Microsoft's search strategy is to find the last occurrence of the result code and then look upward, and to grep for the strings Shell application requested abort and Abandoning apply due to error for object.
5. Did it roll back? The existence of C:\$WINDOWS.~BT\Sources\Rollback answers this. If it is there, that is the authoritative log for a 0xC1900101. Check the same directory for Setupmem.dmp.
6. Check Setup's own verdict. Read C:\Windows\Logs\SetupDiag\SetupDiagResults.xml and the registry copy. Setup runs SetupDiag automatically on failure, so the analysis may already be done for you.
7. Decode the codes. Split the result code from the extend code. Take the last four hex digits of the result code and look them up as a Win32 error or NTSTATUS value; take the first digit of the extend code as the phase.
8. Only now look at C:\Windows\Panther. If the failure was down-level, this directory is describing a different, earlier run and will send you chasing ghosts. Check its file timestamps against the failure date before you trust a single line of it.

Step 6 is where most investigations should end, because Setup usually did the work for you. On the lab device the automatic run had already matched a documented rule:

That is the whole point of reading before fixing. A device that reports a failed feature update, with a rollback-flavoured generic code, turned out to have been cancelled. No driver to chase, no image to rebuild, no ticket.

Where Setup keeps its verdict in the registry

Two of the steps above have registry equivalents, which is useful when you are collecting from a fleet rather than sitting at one keyboard. Setup writes its automatic diagnosis to a fixed key.

Two neighbouring keys are worth knowing. When SetupDiag is run manually without /RegPath, its default target is HKLM\SYSTEM\Setup\MoSetup\Volatile\SetupDiag — a different key from the automatic one, which is a genuine trap when you compare devices. And during an upgrade in flight, Microsoft documents progress at HKLM\System\Setup\mosetup\volatile\SetupProgress: "this key is volatile and only present during the upgrade process; it contains a binary value in the range 0-100". Volatile means gone after the reboot, so it is a live-monitoring value only.

The one event log entry that matters, and why it may not be there

Microsoft documents exactly one Windows Error Reporting event for Setup failures, and it lives in the Application channel.

The ten parameters are documented, and P5 and P6 are the two you came for:

Now the reason the directories matter more than the events. On the lab device, which has two documented Setup failures on record from May 2025, a scan of the Application channel returned zero matching WinSetupDiag events. The log had wrapped. Microsoft also flags that these entries "are only available if Windows was updated from a previous version of Windows to a new version of Windows".

The XML in C:\Windows\Logs\SetupDiag, the registry copy under HKLM\SYSTEM\Setup\SetupDiag\Results, and the Panther logs were all still there fifteen months later. The file evidence outlives the event evidence. Plan your collection around the files.

The fix: collect the set read-only, then decide

For this class of problem the fix is not a repair command. It is a collection, done before anything else, because every subsequent action — retrying the upgrade, running Disk Cleanup, letting Storage Sense loose — overwrites or removes what you need.

Microsoft names the folders to take. From the SetupDiag article: "For offline processing, SetupDiag should be run against the contents of the entire folder", and depending on when the upgrade failed, copy one of \$Windows.~bt\sources\panther, \$Windows.~bt\Sources\Rollback, \Windows\Panther or \Windows\Panther\NewOS. Critically: "if the parent folder and all subfolders are copied, SetupDiag automatically searches for log files in all subdirectories".

So take the parents, not individual files. Copy, never move.

With the copies in hand, run the analysis offline. SetupDiag switches to offline mode automatically once /LogsPath is supplied; the old /Mode parameter is deprecated:

One catch that catches everybody: SetupDiag.exe may not exist on the failed device. Microsoft is explicit that on a normal upgrade "the Sources directory including SetupDiag.exe is moved under %SystemDrive%\Windows.Old for cleanup", and "if the Windows.old directory is deleted later, SetupDiag.exe is also removed". The lab device proves the outcome: Windows.old is gone, and SetupDiag.exe is present in neither System32 nor the surviving $WINDOWS.~BT\Sources. Download the current build from Microsoft rather than hunting for a local copy.

How long you actually have

This is where documentation and folklore diverge, so it is worth being precise about which is which.

Documented. The rollback capability is time-boxed. DISM exposes it directly with /Get-OSUninstallWindow, /Set-OSUninstallWindow /Value:<days>, /Initiate-OSUninstall and /Remove-OSUninstall. The stated behaviour: "if you specify a value less than two or greater than 60, the system uses the default value of 10", with the warning "if days elapsed since installation is greater than this value, you cannot go back to the old version of Windows". The same numbers appear in the MDM policy Update/ConfigureFeatureUpdateUninstallPeriod: allowed range [2-60], default value 10.

Not documented. Microsoft publishes no retention period for $Windows.~BT, $Windows.~WS or C:\Windows\Panther. There is no stated number of days, no documented scheduled task that removes them on a timer, and no supported setting that extends their life. Anyone quoting a figure for those three is guessing.

The lab device is a data point rather than a rule, and it points the reassuring way: the C:\Windows\Panther generation dated 15 March 2025 and the $WINDOWS.~BT and $Windows.~WS residue dated 14 May 2025 were all still present when this was written in August 2026. Seventeen and fifteen months, untouched, on a managed corporate build. What is gone is Windows.old — which is exactly the thing the documented 10-day window governs.

Two more honest notes on cleanup mechanics. On the lab device the scheduled tasks present under \Microsoft\Windows\Setup\ were PITRTask and SetupRecoveryDataTask, both Ready. Neither is documented in Microsoft's upgrade-logs articles, so do not build a retention story on either. And C:\Windows\Panther\UnattendGC\setupact.log carried that day's timestamp, seventeen months after the upgrade, so Panther is not a frozen archive. Check each file's modified time individually rather than assuming the whole tree belongs to one event.

The binaries, and why the diagnostic tooling disappears

One structural fact explains a lot of frustration: almost none of the upgrade tooling is part of the installed operating system. It ships inside the Setup payload, lives in the working directory, and goes away with it.

There is one more artefact worth flagging honestly. C:\Windows\Panther contains WinSetupMon.log at 11,924,452 bytes, and Panther\Rollback\WinSetupMon.DAT at 19,448 bytes. Whatever produced them is not resident: there is no WinSetupMon.sys in System32\drivers and no WinSetupMon service key on the device. Collect the two files; do not theorise about the producer.

Proof it worked: one failed run rebuilt from four directories

Here is the whole method applied to a single real incident, reconstructed on a live machine fifteen months after the fact, entirely from files nobody had touched.

Five facts fell out of that, none of which were available from Windows Update, the Application event log or any dashboard: the trigger was a manual tool rather than policy; the first attempt died in transport; the second attempt was media-based; it was cancelled 12 seconds in and the whole run lasted 27 seconds; and no rollback ever executed, so nothing on the device was left half-applied. All of it read-only, in under five minutes.

The RollbackStartTime of 01/01/0001 00:00:00 is the check to keep in your head. A zero there means no uninstall phase ran, which means there is no Sources\Rollback to read and no partially-reverted state to worry about — and the absence of that directory on the device matched, exactly as it should.

One wrinkle that looks like a problem and is not

The lab device reports DisplayVersion 25H2 on build 26200.9168, with a servicing stack at 10.0.26100.9156. Yet the newest full Panther generation on disk is from March 2025 and Windows.old is absent entirely. On the face of it, a version change with no upgrade evidence.

The explanation is the shape of that release, not missing logs. A 25H2 build sitting on a 26100 servicing base arrived through an enablement package rather than a Setup-driven in-place upgrade, so there was no down-level phase, no image apply and no migration — and consequently no new Panther generation and no Windows.old to create.

What good looks like, then, is unglamorous. On a device that upgraded cleanly: a C:\Windows\Panther generation whose timestamps match the upgrade date, a setuperr.log of a few kilobytes containing migration warnings you can safely ignore, no $Windows.~BT\Sources\Rollback at all, a SetupDiag profile of FindSuccessfulUpgrade, and — for as long as the uninstall window lasts — a Windows.old plus a DISM query that returns a number of days instead of error 1168.

And on the device that started the disk-space alert: 417 GiB free, 2.12 GiB of it Panther. The folders that looked like corruption were the cheapest insurance on the machine.

References

• Log files and resolving upgrade errors - the authoritative phase-to-location table for setupact.log, setuperr.log, miglog.xml and BlueBox.log, the supplemental rollback artefacts, the log entry structure (date, level, component, message) and the documented component tags CONX, MOUPG, PANTHR, SP, IBSLIB, MIG, DISM, CSI and CBS.
• SetupDiag - extraction to %SystemDrive%\$Windows.~bt\Sources, the automatic-run parameters and registry path, the four folders to copy for offline analysis, the setupmem.dmp locations, the full parameter reference and the complete rule table including FindAbruptDownlevelFailure.
• Windows upgrade issues troubleshooting - the four phases plus Uninstall, what each does, the reboot between each, and the volatile SetupProgress registry key.
• Upgrade error codes - result codes versus extend codes, the SP_EXECUTION_* phase table used to pick which directory to open, the operation table, and the method for resolving a result code to a Win32 or NTSTATUS error.
• DISM Operating System uninstall command-line options - /Get-OSUninstallWindow, /Set-OSUninstallWindow, /Initiate-OSUninstall and /Remove-OSUninstall, the default of 10 days, the 2-to-60 range, and the warning about the elapsed-days limit.
• Windows error reporting - Application-log event 1001, event names WinSetupDiag02 and WinSetupDiag01, the ten parameters, and the caveat that these entries exist only where Windows was upgraded from a previous version.
• Windows Setup log files and event logs - the %WINDIR%\Panther, %WINDIR%\Inf\Setupapi*.log and %WINDIR%\System32\Sysprep\Panther locations, and the Setup.etl performance trace with the wevtutil and tracerpt commands to read it.
• Upgrade quick fixes - the free-space requirements (16 GB for a 32-bit OS, 20 GB for 64-bit) and the Disk Cleanup "clean up system files" behaviour that removes previous Windows installations, with its own warning to do it only if you do not plan to restore the old version.
• Policy CSP - Update - ConfigureFeatureUpdateUninstallPeriod, allowed range [2-60], default value 10, for setting the uninstall window centrally instead of per device.