It’s been about a week now since I finished my Win10PE build using samotc’s guide, so I have a good handle now on the build process, how to implement optimizations in flatboot prior to USB boot (and what works in one and not the other), and what is possible to do post-boot and a sort of routine sequence within which to implement those changes. I have a good amount of ground to cover, so it’s probably best for me to try and organize my thoughts in a bullet point kind of format:
Building the Win10PE ISO via Win10XPE is relatively straightforward and easy. The program does most of the heavy lifting for you, and has quite a bit of customization possible. Unfortunately, it also has quite a steep learning curve for some of its more esoteric options (e.g. deploying registry “scripts” made out of .reg files, some of the pecmd.ini syntax, etc.), and even with a fair amount of tech savvy and knowing my way around Windows to the point that I could be characterized fairly as a “power user,” not having a background in programming or enterprise-level deployment left me unable to take advantage of some of the more advanced functionalities of the program. There is also quite a bit of help to be had over at TenForums in the program’s official support thread, but the more advanced users there have limited patience and time for very complicated deployment assistance. Still, from what I can parse of its more advanced functionality and options, Win10XPE should, in theory, allow for many of the changes made in flatboot (including pre-loading programs, drivers, and registry changes) to be done prior to ISO creation instead, skipping much of what we would have to edit and change in flatboot. Some advanced optimizations, especially via registry, could, of course, also cause installation failures or other issues at this stage of creation, but there is something to be developed there for those willing to work out the details.
One of the first issues I ran into was that my normal pre-deployment stripping methods via programs like WinReducer or NTLite were not quite compatible with at least this method of creating a WinPE build. This makes some sense, as WinPE is essentially nested within existing versions of Windows 10/11/other, and while Win10XPE, at least, seems to derive some of the system files it includes in a final Win10XPE-created ISO from the install.wim of the chosen Windows 10 build prior to building the “core” in Win10XPE, it also became clear that much of the base structure of WinPE (e.g. what is populated in its HKLM\SYSTEM\CurrentControlSet\Services keys) is not accessible via my normal methods. This is something I’m fairly sure could be controlled, again, in Win10XPE prior to final ISO creation for those with a better understanding of deployment than mine. Still, using a WinReducer-stripped Windows 10 Professional pulled out of an official Microsoft servers-provided copy of a Win10 21H2 ISO did seem to produce both some desirable results after being put through Win10XPE (slightly smaller WinSxS folder, smaller system32 and SysWoW64 folders, some other minor stuff), and it also seemed to work just fine in flatboot. Unfortunately, it took me some time (until after I had done A LOT of registry editing and other flatboot changes) to realize that the WinReducer-modified version of Win10PE I had produced had some sort of incompatibility with USB RAMDisk boot, and would only work properly in flatboot. I was unable to determine what caused the issue, but it would hang at the Windows screen in USB boot, so I had to go back and redo all my work with a ISO Win10XPE produced with just the base 21H2 ISO and not one edited by WinReducer/other, which worked fine, eventually, in both USB boot and flatboot.
samotc’s guide includes instructions for using the checkboxes in Win10XPE for “Network Drivers” and “Audio,” e.g., if you need network support or audio support, but I found that these options are for only very specific (and, in my case, unnecessary) drivers. That is to say, the “Audio” checkbox, for instance, seems to be for including HDAudioBus.sys and HDAudio.sys as well as associated files, which, to my knowledge, are only needed for on-board motherboard audio. Similarly, the “Network Drivers” checkbox and the tab afterward concerning network setup are related to the Win10XPE-included program “PENetwork,” which is a separate executable that auto-runs in WinPE at boot to manage wired and wireless network connections. If, like me, you are using a USB DAC and a JCAT FEMTO Ethernet card, you do not need any of these functionalities, and simply need to make sure Win10XPE includes the needed drivers in your build, which should be able to be accomplished in the same screen via the driver integration option. If you are using a onboard ethernet solution or similar, you can just use the “Include Host OS Network drivers” option to have Win10XPE automatically include your network hardware’s drivers in your WinPE ISO, which is what I did for the JCAT Femto NET card. This method should allow for you to delete PENetwork in flatboot if using network, e.g., and save some space by not including unnecessary onboard audio functionality. In fact, I do not recall, out of all of the ISO’s I created while testing in the last few weeks, any of the options prior to “Build Core” being started being necessary for my purposes, other than a few of the default options. This includes things like the VC++ Runtime option, which is unnecessary, at least for my use case.
Which brings me a bit to refreshing any readers to what I need to be functional in my particular use case: 1) a working network connection via my JCAT Femto NET ethernet card 2) an ability to use my USB DAC through my JCAT Femto USB V2 card 3) a working internet browser 4) an ability to play TIDAL in exclusive mode via the TIDAL app 5) MinorityClean/MajiorityClean running in NT-AUTHORITY\SYSTEM mode 6) RewriteData 7) TimerResolution 8) ProcessHacker or similar software. This is basically the entirety of what I need to have running in a Win10PE build.
The network connection was taken care of, again, by using the “include Host OS drivers” option in Win10XPE. The JCAT NET card installed correctly and worked at boot, and I was able to kill and delete the PENetwork in flatboot. Unfortunately, it seems that there is not a way, as far as I can see, to easily remove this software within Win10XPE, so you will need to do something about it in flatboot if you are not using it. It will work for a network connection pretty reliably if your network hardware’s drivers are not installed for some reason, however.
I know samotc intimates in his guide that his DAC’s drivers had to be loaded after booting into flatboot, complete with changes to the registry via “Remote Registry” in WinPE Strelec after using RegistryChangesView. In my case, my USB DAC does not have any of its own drivers, and instead uses “usbaudio2.sys”, which is a Microsoft-provided and signed native USB Audio 2.0 driver that was introduced sometime in the last 5 to 6 years. Unfortunately, Win10XPE does not include this driver/service automatically, and it did take me a bit to understand the proper way to engineer its inclusion. For those who may have a similar DAC needing Microsoft’s native driver, I was able to simply copy the folder for usbaudio2.sys (it MUST be the whole folder, and not just the files or .INF file!) in the FileRepository area of system32 of my host OS into the Win10XPE drivers folder and then direct Win10XPE to integrate the drivers. This resulted in my USB DAC working properly after some trouble in ascertaining this method.
Win10XPE includes two options for WinPE’s shell: Explorer and “WinXShell.” I notice samotc went with explorer, but I have gone wth WinXShell. WinXShell appears to have a lighter overall footprint than Explorer, both in terms of its process footprint after WinPE boots and the disk space its associated files use. Also, as I will detail a bit later, it ends up needing less overall processes to function, given that it eliminates the inclusion of dwm.exe and instead only truly needs one instance of “WinXShell.exe”, as opposed to one or more explorer.exe process instances as well as dwm.exe for Explorer.
Some of the “Applications” functionality in Win10XPE I found to be unreliable - for instance, Google Chrome would be included in the Win10PE ISO it created only about 15% of the time, no matter which options were selected. This wasn’t much of a problem for me, however, as I could just move either an installation file for Chrome/similar from another drive in flatboot to Win10PE, or even copy the program’s folders and files and skip the installation process entirely. More on internet browsers later, as I eventually changed from Chrome.
The TIDAL app, which, as you will recall, is something I require for my use case, for the most part would not install on its own after being downloaded in flatboot, which necessitated that I copy its already installed program folders/files from another drive (located in (user)\appdata\local\TIDAL). Unfortunately, this also began a bit of a headache as, while the TIDAL app would boot in WinPE and sign on correctly, only “High” quality (lossy and not in exclusive mode) would allow for any music playback, and even then only some of the time. I overcame this by comparing what drivers and other files were loaded in the “modules” tab of Process Explorer in a normal Windows 10 install vs. what was loading in WinPE for the process instances for “TIDAL.exe” and “TIDALPlayer.exe” -- this resulted in my narrowing down, after some time, the following four missing driver files in WinPE’s SysWoW64 folder as being the culprit: mfplat.dll, mfreadwrite.dll, RTWorkQ.dll, and AUDIOKSE.dll. After copying these from my host OS into Win10PE’s flatboot’s SysWoW64 folder, TIDAL player locked onto my DAC and played back music in any quality and in exclusive mode for Hifi/Master quality.
As has been discussed in the thread previously, Microsoft created a built-in “kill switch” of sorts for WinPE, ostensibly to combat piracy, where WinPE will reboot after 72 hours of continuous use. Fortunately, some poking around Google led to the revelation that there is a relatively simple workaround that, so far, seems to work in my system and has prevented a 72-hour reboot. The information I’ve found online directs you to use a program by SysInternals (which also makes other useful programs like autoruns and Process Explorer) called “PSSuspend,” a command-line utility, to suspend “winlogon.exe,” but I’ve found that suspending the process instance of “winlogon.exe” in any program that has this functionality -- including Process Hacker or Process Explorer -- will work. Crucially, you must SUSPEND winlogon.exe and not kill/terminate its process instance. Still, this is quite interesting, as in other “normal” versions of Win10, winlogon.exe being suspended or terminated was not possible without breaking Windows, which is related to other processes in WinPE also allowing for their processes to be modified, killed, suspended, or terminated in ways that they were not able to in “normal” Win10. More on this later.
As I have intimated elsewhere, I have a long history of stripping and editing Windows 10 (and previously Windows 7) through various methods to create an optimized Audio OS. As a result, I have a sort of routine list of optimizations I employ and others I’ve discarded, which include a long list of registry edits and tweaks, disabling unused and unnecessary devices in Device Manager, deleting unncessary/unused system files and folders, network adapter setting optimizations, affinity and priority changes, and changing boot settings via bcdedit/similar. So, with WinPE, I have attempted to replicate what I can, where appropriate. This has led to some interesting and sometimes frustrating issues.
Before I begin talking about some of these optimizations, I will repeat a point I made in a reply to another user with an issue: samotc’s guide mentions that you can use something called “WinPE Strelec.” WinPE Strelec is a heavily (and I mean heavily!) modified and customized WinPE recovery ISO which contains many programs related to system recovery and other functions. He included it in the guide because it contains a lot of programs that he recommends using in the process of creating a Win10/11PE ISO, working with it via a VHD flatboot, and making changes to that flatboot (WinNTSetup, DISM++, Bootice, etc.). If you choose to use WinPE Strelec, it’s a bit unclear from his guide, but I would recommend burning the ISO with Rufus to a USB pendrive/media and booting from it, then mounting the VHD from another drive and working with it within WinPE Strelec. Or, you could do what I (and apparently also samotc) did and simply download the needed programs from the internet in your host OS instead. samotc mentions that he uses a program, however, called “Remote Registry” in WinPE Strelec to make registry edits to Win10/11PE’s flatboot VHD hives, whether via .reg files in his RegistryChangesView method or otherwise. In my case, I found this too cumbersome, and simply would use another Registry editing program in my host OS (where my VHD’s were all located) such as Registry Workshop (but you could even just use normal Regedit) to load the hives from the mounted VHD in system32\config, make edits, and then unload the hive. It is, of course, up to you -- one advantage to doing it samotc’s way via Strelec’s “Remote Registry” is that the .reg files that would be generated with RegistryChangesView would not have to be edited to include whatever name you choose for the hives you load in another program -- Remote Registry, as far as I can tell, just treats the loaded offline hives as if they are its own, so an offline hive will just show up as, as just an example, HKLM\SYSTEM\CurrentControlSet\Services, as opposed to HKLM\(name you gave the loaded hive)\ControlSet001\Services. I did not use .reg files very often in my own registry edits to my flatboot(s), but when I did, I had to replace “SYSTEM” or “SOFTWARE,” for instance with the name I gave my loaded hives in notepad++ or similar to implement the changes needed.
The first issue I ran into was that, normally, devices disabled or uninstalled in Device Manager would have correlates in registry settings. In WinPE, however, its odd registry behavior in terms of some things being static and others not, even in flatboot, resulted in these settings not being available in the offline registry hives, and unfortunately all of the devices in Device Manager (or NirSoft’s similar program DevManView, which I also use) need to be re-disabled upon a reboot, whether in flatboot or USB boot. This is a pain, but after awhile I did become pretty good at remembering what to disable without having to consult what I had written down.
Boot settings via Bootice or BCDEdit are another oddity with WinPE that I am still, to be honest, unable to ascertain if I have applied correctly, at least in USB boot. In flatboot, I would use Bootice to edit the settings for both the BCD file for the “Boot from VHD” option in my current boot menu, as well as the ones in the VHD’s boot\bcd file, and lastly the BCD file in the efi folder of the VHD. The kind of settings I’m referring to are normal “audiophile” optimizations for boot settings, such as disabledynamictick or nX AlwaysOff, etc. After applying these, I was able to confirm with flatboot that they seemed to work because of settings related to boot animation/graphics seeming to be applied (it would show the Windows logo and loading icon for a shorter duration than it had previously), but in both flatboot and USB boot, attempting to check current boot settings with either bcdedit or Bootice while WinPE results in an error message, so it’s not verifiable, as far as I can tell. With USB boot, I have resorted to editing all BCD files I can find, which is to say the ones in the ISO’s root directory, as well as the ones within the boot.wim, with all the same settings. I think this is working, but again, can’t find a way to verify! If anyone has any insights here, that would actually be very helpful.
Okay I am done writing for the day, I think. Wore myself out! Thank you for reading if you managed to make it through. I will return with another post that mostly details the process of disabling services both in the flatboot registry and post-boot, and at least then attempts to give a guide for which services can be disabled/stopped, broadly, in a WinPE build that both needs network and does not. I will also talk about whittling down processes in general -- I have found you can get WinPE down to as little as 16 processes! Stay tuned.
