Slimdown10_v2.0.2 (continued)

Hi @SunLion,
I also tried doing in-place upgrades starting from various versions of Windows 10 Pro (20H1, 21H1, 21H2) as well as from IoT LTSC 2019 (not slimmed down). In all cases, I encounter the same issue as @ashish1989

Looking at the upgrade logs, the error I found is:

Code:

0x8007007F - 0x2000A Installation failed in SAFE_OS phase during PREPARE_FIRST_BOOT operation

Specifically, the showstopper seems to be this:

Code:

DISM sysprep provider failed to run sysprep specialize 0x8007007F

 

You need to login to view this posts content.

 

Hi,
In the ISO that successfully performed the upgrade, what are the versions of winsetup.dll - the one inside \sources folder and the one inside install.wim [Windows\System32\oobe\winsetup.dll] ?

 

Do you think this guide to completely clean a HDD/SSD with a LinuxLiveCD is any more thorough than diskpart or just unnecessary? TY
https://forums.mydigitallife.net/th...a-new-install-of-w7.86916/page-2#post-1789229

 

My personal concern would be more to documented malware that hides in Windows partition data, but as CaptainKirk1966 points out, if you are concerned about someone eventually recovering something from a drive, then more aggressive wipe routines or tools make sense -- some BIOS firmware even offers these as well now, ASUS, MSI, ASRock et al. but they take a very long time to run.

I wouldn't go as far as the Captain though in calling it 'paranoid', as some people do store some very sensitive, high risk data directly on their drives without any manner of encrypted container -- but would add the chances of someone going through the trouble of attempting to recover data from an SSD or HDD unless they know you have something worth purloining is low.

I'm not a security expert, I just follow those that are, and a lot of people have been rooted, and/or have malware hiding in places like partition data and don't even know about it -- so, my primary concern in mentioning this is regarding more immediate threats and things that may throw a curve to properly executing a clean install of Windows, with tools like Slimdown10 or otherwise, that could for example throw an error code like 0x8007007F.

 

I’ve finally managed to solve the issue (or rather, the issues) that were preventing the in-place upgrade from completing — at least in my case.

@hoak
All my tests — including the earlier ones — were done completely from scratch using VMs with brand-new disks.
All source IOSs were checked and I confirm that are genuine (by using Windows & Office Genuine ISO Verifier).
I did this specifically to rule out any issues caused by malware, leftover clutter, or inconsistencies in the original OS.

@ all
I tested with several genuine Windows versions and ran the SD10_Renewed script with almost all slimming-down options enabled and I enabled the option to download the latest security updates.
After that, I added the missing in-place setup files and .dll taken from genuine source ISO.
Then, through trial and error, I managed to get it working. Here are my findings:


The error 0x8007007F is fairly generic, and from the logs I shared, the failure occurs before the first reboot ("failed in the SAFE_OS phase during PREPARE_FIRST_BOOT").
Specifically, the error happens during the Sysprep specialize step ("DISM sysprep provider failed to run sysprep specialize 0x8007007F").

I extracted the setup logs using SetupDiag tool (from MS) and fortunately found the details, which are pretty much self-explanatory:

Code:

2025-10-23 10:37:04, Info SYSPRP SysprepSession::ExecuteAction: Offline sysprepModule requested reboot
2025-10-23 10:37:04, Error SYSPRP ActionPlatform::LaunchModule: Could not load DLL C:\$WINDOWS.~BT\NewOS\Windows\System32\oobe\winsetup.dll; dwRet = 0x7f[gle=0x0000007f]
2025-10-23 10:37:04, Error SYSPRP SysprepSession::ExecuteAction: Failed during sysprepModule operation; dwRet = 0x7f[gle=0x0000007f]
2025-10-23 10:37:04, Error SYSPRP SysprepSession::ExecuteInternal: Error in executing action for Microsoft-Windows-Setup-Component; dwRet = 0x7f[gle=0x0000007f]
2025-10-23 10:37:04, Error SYSPRP SysprepSession::Execute: Error in executing actions from C:\$WINDOWS.~BT\NewOS\Windows\System32\Sysprep\ActionFiles\Specialize.xml; dwRet = 0x7f
2025-10-23 10:37:04, Info SYSPRP SysprepSession::Execute: Sysprep mode was not specified, deleting it from registry

The log indicates that Windows tries to load winsetup.dll from C:\$WINDOWS.~BT\NewOS\Windows\System32\oobe\, but fails with 0x7F (ERROR_PROC_NOT_FOUND).
During the DLL loading, the function Sysprep_Specialize_Offline_Pnp_Compat is invoked → this can be seen in the file \Windows\System32\Sysprep\ActionFiles\Specialize.xml.
The return code 0x7F means that:

- the DLL exists, but does not export the requested function OR it is corrupted OR it is not compatible with the parent process that calls it (in our case, the Setup executables).

@SunLion
Here’s why I asked you about the DLL versions.

In my case, the error was resolved by placing the same DLL from the ISO (Sources\winsetup.dll) into the install.wim at \Windows\System32\oobe\winsetup.dll.
The version mismatch was likely causing the error. However, when repeating the in-place upgrade, I encounter a couple of other errors that are blocking the setup:

Code:

SPCreateFile: Cannot copy C:\$WINDOWS.~BT\Sources\$OEM$\$$\Web\Wallpaper\Windows\img0.jpg to C:\$WINDOWS.~BT\NewOS\Windows\Web\Wallpaper\Windows\img0.jpg. hr = 0x80070005[gle=0x00000005]
SPCreateFile: Cannot copy C:\$WINDOWS.~BT\Sources\$OEM$\$$\Web\Screen\img100.jpg to C:\$WINDOWS.~BT\NewOS\Windows\Web\Screen\img100.jpg. hr = 0x80070005[gle=0x00000005]

The error means "ACCESS_DENIED" because the setup (running “as Administrator”) cannot overwrite those two files, which are owned by TrustedInstaller.

“Brutal” solution : run setup.exe as TrustedInstaller (for example with PowerRun).
Cleaner solution: remove the files \Windows\Web\Wallpaper\Windows\img0.jpg and \Windows\Web\Screen\img100.jpg from the install.wim

Done! With these changes, I was able to complete the in-place upgrade. There’s still a small detail, if we want to be 100% precise:
at the end of the upgrade and after the reboot, the modified \Windows\System32\oobe\winsetup.dll will remain. It might be a good idea to automate restoring the DLL to match the Windows patch level.
I can provide more details on this last step if it’s not clear.

 

I took the plunge and tested this on my laptop.

Code:

===========================================================
SRV2025DC_to_Workstation_1.1
Configured Options at 2025-10-22, 15:17:25.38
===========================================================
Running in NORMAL mode
Don't InstallAPPS
HideSearchBoxTaskbar
Show ThisPC + Bin + User + ControlPanel + Network Icons on Desktop
Do Not Apply PersonalTweaks
===========================================================

Everything works more or less. Not all drivers will apply on Server. My Device Manager for W11 LTSC is clean, but Server shows non-working devices using the same drivers.

Smart Standby (S0 Sleep) doesn't work or may not be supported. Laptop always stays on which is a deal breaker for me.
Also, I would prefer to undo some of the changes made to the wim which caused some things not to work such using WUMT
to search fro updates. I use Defender on Demand via a toggle and that failed since it was disabled. Starting the Windows Security GUI
ended up with a blank display. Installing Standard (Desktop experience) directly gives you the same desktop, but without any tweaks
being applied. From there WUMT and Defender functioned correctly. In my case I would have to sift through all the tweaks and select what I want, but no need for that since sleep is broken.

Out of curiosity what is the advantage of using Desktop experience from Data Center over Standard Desktop experience and isn't Desktop experience = Workstation ?

 

SunLion, I did not understand what you meant by "remove various codes'. I am guessing codes=tweaks?
I will not be installing Server on my laptop as mentioned earlier because sleep is broken for me.

Also, I meant the Desktop Experience SKUs between DataCenter and Standard. Seems like DataCenter is overkill for normal desktop usage.
I assume Desktop Experience is the same component for both DC and STD.

 

I don't believe the driver problem has anything to do with any of the tweaks. It seems to be related to the Server software, because installing directly without without using Server2Workstation2025.7z has the same issue. Server may not like some normal Windows client drivers, so it's hit and miss there. My drivers were all from Lenovo. Strange that it did not like the one for Ethernet.

 

I’ve done extensive VM testing on this. I created fresh Windows 10 and 11 ISOs, installed clean base images (both Consumer and LTSC), and performed multiple in-place upgrades in both directions — from base Windows 10 to SlimDown 10, then to SlimDown 11, and back again to SlimDown 10. I tested all upgrade options (“Keep files,” “Keep nothing,” etc.), and everything worked smoothly. Testing was done without files reduction section in the script.

From what I’ve seen, the issue might be caused by one of the following:
-Registry tweaks that block upgrades
-Corrupted system files on the host system
-Updates interfering during the upgrade process

For anyone experiencing this issue, I’d recommend:
1. Running sfc /scannow and DISM /Online /Cleanup-Image /RestoreHealth
2. Checking that no registry settings are blocking upgrades
3. Starting the upgrade from setup.exe in the root of the ISO, not the one in the Sources folder
4. Temporarily disabling the network during the upgrade

 

Yes, that's why I recommended it -- as it has been documented to remove known malware that can hide in partition table data, it's also fast, fairly easy to use, and everyone that has a copy of Windows already has the tool. That said, when you look at what's being done now with SSD exploits, it's impossible to second guess what comes next -- it's hard to fault anyone's precautions so long as they're not based on magical thinking as paranoid, as today's 'Paranoid User' will likely be seen tomorrow as practical and as an example to follow...

There's just too much easy money being extracted via malware, and hijacking people's data -- Microsoft (and its Partners™) perpetually get law changed internationally so they could join in, legally...

Even for those breaking the law; on a percentage basis -- almost no one goes to jail... For those arguably legally purloining your data, concatenating it with AI (at your expense) and selling it thousands of times a second; more money will be made selling your data, than you'll earn in your entire life... With enormous incentives like these -- do you really want any of your personal data on a Windows™ system? Is any level of precaution really paranoid in a world that incentivizes data theft and legal, government vetted data hijacking on an industrial scale?

Intellege Quid Agitur

 

I’m wondering the same thing myself, especially because I see that other people (.ie. @Shrinklier) are confirming have no issues performing an in-place upgrade from a vanilla Windows 10 installation (consumer or LTSC) to “SlimDown10.”
I can also do the upgrade without any problems if I use a genuine, unmodified Windows 10 IoT LTSC 2021 ISO — but with the slimmed-down version of Windows 10, I run into that strange WinSetup issue.
I’ll keep investigating the cause of this and will keep you updated