Where Should Setup.exe Be Used? Is the Windows.old Folder Necessary? When Does PE Come into Play? A Detailed Look at the Windows System Upgrade Mechanism
Where Should Setup.exe Be Used? Is the Windows.old Folder Absolutely Necessary? When Does PE Come into Play? A Deep Dive into the Windows System Upgrade Mechanism
Let’s start this article by creating a bit of confusion.
What Windows update methods and steps have you heard of?
- Downloading and installing updates online via “Update & Security” in Settings
- Using offline downloaded update packages
- Using a Windows ISO installation image
- Performing an in-place upgrade on the current system
- Offline injection of updates via the PE system
- Using DISM commands to integrate update packages
- Installing updates with Dism++
- Double-clicking an update package to install
- ……
Some of the methods above are real, some are fake, and their applicability varies.
Today, I’ll walk you through exactly which Windows update operations are necessary, which are not allowed, and how Microsoft and Windows’ update logic actually works.
Let the real content begin
Rule One: You Can Never
You can never use an ISO installation image to offline upgrade a Windows system within a PE environment.
Example:
My current system is Windows 10 22H2 19045.2262. I have a Windows ISO for Windows 10 22H2 19045.6693. I want to use this ISO to upgrade my system.
Don’t even think about it. In PE, it’s completely impossible to update this Windows. Because when upgrading Windows using a full Windows installation image, a Windows upgrade is not simply a file replacement.
※※ The essence of a Windows “upgrade” is a state machine driven by a running installer (setup.exe):
- Scans the current system
- Determines upgrade eligibility
- Migrates the registry
- Migrates user configuration information
- Writes new version information
- Creates a rollback restore point (Windows.old)
Only setup.exe can do these things.
As you can probably understand, for setup.exe to accomplish the above, it must run on a “living soul.” In other words, it must run within a Windows system to complete the upgrade. Setup.exe in a PE environment cannot perform a “Windows upgrade.”
DISM can never do the above. The most DISM can do is replace files. Using
1 | |
These two commands can update the offline Windows winSxS system components to the version in the latest ISO within PE. However, DISM is not capable of fully configuring a Windows upgrade. Simply updating components is not upgrading Windows. This operation may appear to replace system files, but after restarting Windows and checking the system version, the version number will not change, and the system will remain unchanged.
In simple terms:
DISM =
- Offline deployment
- File/component level
- Not responsible for system “identity change”
setup.exe =
- Running installation
- Responsible for upgrade, migration, rollback, version writing
So, when you “lay” new system files into an old system, Windows thinks: I see the files have changed, but I didn’t experience an upgrade.
In PE, the Windows system is in an offline state. We can only deploy, repair, or overwrite Windows; we cannot roll back or upgrade Windows.
Upgrading Windows is always something that can only be done when Windows is online.
Upgrading Windows is always something only setup.exe can do.
So, please remember:
You can never use an ISO installation image to offline upgrade a Windows system within a PE environment!
If we run setup.exe in PE and choose the upgrade method that preserves personal files and applications, setup.exe will directly report an error: Cannot upgrade Windows in the Windows PE environment. Upgrade Windows in a normal running Windows environment.
See, Microsoft directly throws an error, proving this is truly impossible.
Rule Two: You Can Never
You can never prevent the Windows.old folder from being created.
Whenever you upgrade Windows, the Windows.old folder will inevitably appear.
- The old system before the upgrade = rollback foundation
- Rollback foundation = Windows.old
- No Windows.old = upgrade not allowed
This is internal mandatory logic within setup.exe.
The only thing we can do is delete the Windows.old folder promptly after the Windows upgrade.
Right-click C drive → Properties → Disk Cleanup → Clean up system files → Check Windows.old
Rule Three: You Can
You can use DISM in a PE system to install update patches for a Windows system.
The types of patch files that can be successfully installed in PE are usually:
.msu.cab- Cumulative Updates (LCU)
- Security Updates
- .NET Updates
- Servicing Stack Updates (SSU)
The tools typically used are:
1 | |
Or directly import via Dism++.
An update package ≠ a new Windows
It simply swaps components under the same identity.
A particularly critical, but rarely noticed, point:
When you install an update package in PE, you are actually:
- The update is not truly completed
- It only:
- Imports new WinSxS files
- Marks them as Pending
- Waits for the next normal startup
What truly completes the update is:
- TrustedInstaller
- Windows Modules Installer
- Session Manager
PE only schedules the update;
The actual execution of the update happens after the normal system boots.
※ So, what legitimate methods remain for updating Windows normally?
- Installing Windows update packages in a PE system.
- Installing Windows update packages in a Windows system.
- Running setup.exe in a Windows system, choosing to keep personal files and applications.
Only these three methods!!!
Why is updating Windows once with setup.exe so slow?
It’s not because copying files is slow; it’s because it’s “proving it didn’t break your system.”
Setup.exe does far more than just extract files to the C drive. In fact:
- Full system compatibility scan
- Dual migration of user mode + system mode
- Application migration (this is the slowest part)
- Driver re-enumeration
- Rollback system construction
- Windows.old
- Rollback BCD
- Rollback registry snapshot
“I have to ensure everything you had before the upgrade still works.”
Consistency verification is always slow.
Windows.old itself also slows down the upgrade:
During the upgrade process: the old system is not simply moved; it is copied in batches, verified, and rollback points are marked.
If I don’t choose to keep personal files and applications, will Windows.old still be created?
Yes, even if you don’t choose to keep personal files and applications, Windows.old will still be created.
Without choosing to keep personal files and applications, Windows will still:
- Package the entire old system
- Place it in
C:\Windows.old - Use it as a rollback foundation
What if the C drive doesn’t have enough space for Windows.old?
1️⃣ Directly refuse the upgrade
2️⃣ Fail during the upgrade and roll back
3️⃣ Force you to free up space first, otherwise it won’t proceed
Your Counterargument
You might say: I once used Dism++’s “Apply Image” / “System Restore” function in a PE system to extract the wim/esd file of a newer system version. Without checking “Format,” a Windows.old.001 folder was generated in the root directory, containing the files from the original system version.
So why is it named Windows.old.001 instead of Windows.old?
You might also say: After booting the system, I used “Disk Cleanup” and it scanned for “Previous Windows installation(s),” which is the Windows.old.001 folder, and I could choose to delete it.
Yes, DISM / Dism++ can also generate a folder that looks like Windows.old.
But what it generates is not the “Windows.old for upgrade rollback”; it is: a directory “recognized by Windows as old system remnants.”
So, this
Windows.old.001cannot be used for rollback; it is merely a Windows carcass.