@otvertka Please download this edited script—which includes an option to editing boot.wim 2. You will be asked whether or not you want to edit boot.wim 2. Choose NO and run the test. I need to verify whether it works properly this way or if I need to make further adjustments. I appreciate your help.
I’ve been running tests too, and that first idea didn't work here either. Editing the boot.wim is really tricky. Since I don't have another physical machine for testing, I’d like to ask you to give this another try: Edit the script `2xH2_Creator_16.6.cmd` and comment out line 2955, shown below: :: "%DISM11%" /English /Image:"%BootMount%" /Cleanup-Image /StartComponentCleanup /ResetBase That might be the issue. Let's see. It works without errors in VirtualBox, but I’d like to know how it performs on a real machine. Thanks for your help. I ran the test with the settings below:
Yes, I suspected that too; in fact, I commented on and tried everything I saw on ResetBase, and these are the error codes: But now I have another idea: Could it be a permission issue? I’ve always tried running the 2xH2_Creator_16.7_Start.cmd file with `powerrun`—maybe I should try the other one? ***But I had already tried this test for 25H2
I think your boot.wim is fine because, as I said, I created the install.wim simply by copying it without performing any other steps (I completely bypassed the “Configuring Boot.wim 2” section in the script), and when I created an ISO and tested it, it didn’t work. But when I put the same install.wim into the original 26100 1742 ISO and packaged it, the system boots into setup without any issues. I’m wondering if there might be a permission issue? (I won’t be using PowerRun.) I’m going to try that. New test: 2xH2_Creator_16.6.cmd—I'm running this file as an administrator and testing it with the following settings: Code: 2xH2_Creator_16.6 Configured Options at Sal 30.06.2026, 23:16:58,29 =========================================================== Running in DEBUG mode Selected 26100.1742.240909-0928.GE_RELEASE_SVC_REFRESH_CLIENTBUSINESS_VOL_X64FRE_PT-BR Don't Integrate Drivers Into Install.wim Don't Integrate Drivers Into Boot.wim index 2 Creating image 24H2 Enable Store Do not Remove ClickToDo - GetStarted - WindowsBackup Enable WindowsSearch Do not Remove Windows Defender Remove Edge completely Enable Modern Calculator Remove WinRE.wim Do Not Enable MediaPlayer Don't Install Openshell Don't Customize Boot.wim Do not add WPI in the image Do not include any M.A.S. packages in the image =========================================================== Result: Failed Issue Isolation Report: The Problem: The ISO created by the script always throws a missing media driver error during Windows Setup, regardless of whether the script is run via PowerRun (TrustedInstaller) or directly as an Administrator. The Proof: If I take the processed install.wim from the script's output and manually drop it into the Sources directory of a clean, untouched official ISO, the installation goes through flawlessly. Conclusion: This clearly demonstrates that all the registry tweaks, component removals, and updates inside install.wim are 100% correct and stable. The root cause is that the script is either deleting/corrupting critical setup files within the DVD\Sources directory during execution, or it is breaking something while handling the boot.wim integration.
That's possibly the case I don't use SD boot.wim as the one I modded works on any ver of win 11, I only use the SD install.wim on these builds.
Here’s what’s interesting: When I add the same updates as W10Ui to a separate folder, upgrade to 25H2, and package all the files (including Boot.wim), everything works. But when I package the files I obtained using this script, Boot.wim gives an error, so I started investigating why that is. Yes, you’re right—if I just use install.wim, there’s no problem, and everything works in all the scripts except for Ventoy.
Also, I want to add one important detail: When I checked the boot.wim inside the script folder, I saw that all RST (Intel Rapid Storage Technology) and critical storage drivers were already present. I even tried integrating them manually again, but the result didn't change. This strictly confirms that the drivers are physically inside the image, but Windows Setup is somehow blocked or restricted from accessing that directory/media during the installation phase
@SunLion I used the method in my post above, in reality its not too different to yours in the script, though I don't use or alter the boot.wim setting when I use your SD script.
@otvertka what hardware platform are you performing this on? Motherboard model and RSTe driver version you use.
That's flawed logic. In order to learn and progress one must gain an understanding of why things are done the way they are and how the result is achieved, after which one can independently perform the same modification and have confidence in the content of the image. A simple screenshot of the page would've been more than enough.
In my case, my script can’t corrupt the boot.wim file, since that file isn’t involved in my script’s operation. In my script, I work only with the install.wim file, and after I’ve finished configuring it in DISM++, I copy it to “my” DVD blank. Next, I copy the contents of the DVD folder to a bootable USB drive and use it to install the resulting OS onto my PC.
Regarding the drivers, I only ever integrate RST v19, v20 and v21 drivers into boot.wim, winre.wim and install.wim using w10ui. This has been universally solid for me across many platforms and usb tools - intel/amd, old/new platforms, vmd on/off, rufus/ventoy/rpo's script, doesn't matter, the usb always boots and always installs. From what I've read in your earlier replies about using w10ui I'm starting to think there's something related to mismatching files and how Ventoy boots an iso. Back when this problem was happening years ago, abbodi implemented the UpdtBootFiles feature in w10ui and I started updating the whole iso distro folder. Since then the booting issues were gone.
I appreciate your insights, but as I’ve repeatedly mentioned before, integrating the drivers is not the solution to this specific problem because they are already physically inside the images. However, your point about UpdtBootFiles and @abbodi1406 actually hits the exact nail on the head. You mentioned that updating the entire ISO distro folder fixed the booting/setup issues years ago. This directly aligns with my diagnosis: The 2xH2_Creator script is failing to correctly update, align, or preserve the files inside the DVD\Sources directory while modifying the boot structure. When the setup folder structure gets messed up by a script, Windows Setup loses its pathing to the integrated drivers during the initial phase, throwing the 'missing driver' error. The fact that the same install.wim works perfectly when placed inside an untouched official ISO folder layout proves that the drivers are fine, but this creator script's folder/distribution management is broken. My ultimate goal here is simply to help the author of this script and ensure that all files generated by this tool can be installed with total, unbroken integrity. Once the core script logic is fixed and flawless, we can easily swap out or use whatever custom boot.wim we want with complete peace of mind. But until that root folder management bug is solved, the underlying integrity remains questionable.
Regarding the install.wim, dozens of tests have already been performed, and there are no issues. As for the boot.wim, the issue is that reducing the contents of the "Sources" folder and removing "Winre.wim" requires adding the code `"CmdLine"="X:\sources\setup.exe"`. I believe this is what is causing the problem, but since our goal is to reduce the image size, I intend to keep it this way and look for another solution. I don't have a solution for this yet, but I will keep researching.
Thank you for the clarification and for confirming the root cause! It’s a huge relief to know that install.wim is completely solid and unaffected by this behavior. Your explanation about the Sources reduction and the "CmdLine"="X:\sources\setup.exe" injection makes perfect sense. It clearly explains why modern VMD/RST platforms lose pathing to the integrated drivers during that specific setup bypass phase. I completely understand your goal of keeping the ISO size minimal. While you are researching a permanent fix for this folder/command conflict, I will comfortably use the workaround we discussed (swapping the install.wim into an untouched official ISO) for modern hardware deployments. Thanks again for your hard work on this script and for looking into this bug. Looking forward to your future updates!