@otvertka out of curiosity, when booting with ventoy, have you tried the wimboot option, instead of normal boot?
Hi, @SunLion Thank you for the suggestion! You are actually spot on: this issue only happens with Ventoy. When I flash the ISO using Rufus or other standard tools, it works completely fine and doesn't throw this error. That is exactly why I trusted your install.wim in the first place; I knew the core OS image was solid because it passed those tests. I also tried integrating the drivers into boot.wim Index 2 via the script as you mentioned, but unfortunately, that didn't change the behavior under Ventoy. Since you confirmed yesterday that the install.wim is completely clean, I am currently using a practical workaround: I took your finalized install.wim and packed it into a known stable ISO base. It installs and boots perfectly this way! This proves your install.wim is structurally perfect, and the Ventoy conflict is likely related to how the script compiles the boot environment or the final ISO structure. I'm always ready to help with further testing whenever you want to tweak the script to fix this Ventoy compatibility issue. Let me know! + I have great news! I just tested everything by flashing the complete ISO (including your boot.wim) using Rufus, and it worked flawlessly! There is absolutely no issue with your files or the script's output. Even the boot.wim is working perfectly without any errors. The 'missing media driver' issue is strictly isolated to Ventoy's emulation. Since it installs perfectly with Rufus, I have 100% confidence in your work now. I will happily use this build and wait for your future updates whenever you decide to look into the Ventoy compatibility side. Hi, @shhnedo Thank you for the suggestion! Actually, I have already tried integrating the drivers into boot.wim Index 2 using the script, but unfortunately, the behavior didn't change and the same error persisted. Also, this doesn't just happen with Ventoy; I encountered the same issue when burning the ISO directly to a standard USB drive as well. Since you mentioned yesterday that the install.wim is completely clean and passed many tests, I decided to try a different workaround: I took your finalized install.wim and packed it into a known working, stable ISO base. When I do this, it installs and boots perfectly! This confirms that your install.wim is indeed structurally healthy, and the issue lies entirely within how the script builds the boot environment or the final ISO structure. I'm always ready to help with further testing whenever you make updates to the script. Let me know if you want me to try a new build!"
You cannot go wrong with Rufus, Ive been using it for several years, beauty of it you don't need to rebuild the structure, simply mod or update a wim, simply drag & drop it in your build & Rufus will boot it.
But I didn't say there was a problem with the Rufus app—it works just fine. The problem is only with Ventoy.
A question. Since I don't use Ventoy, I don't know how it would behave in this scenario. As far as I know, ISO images are simply placed onto the USB drive. But if the contents of the ISO image were extracted into a folder on the USB drive instead, wouldn't that alter Ventoy's behavior? I also thought of something else—kind of a crazy idea, but it might work. The script adds a registry key to point the setup process to the "sources" folder, meaning only the "sources" folder contains the setup.exe file. The idea is: how about copying the setup.exe file from the "sources" folder to the root folder (the DVD root)? That way, the setup.exe file would remain in the "sources" folder but would also be present in the root. I believe Ventoy uses the setup.exe file located in the root folder, not the one in "sources". You could test it and see what happens... Best regards
@SunLion I was diving deep into the script and the compiled ISO structure, and I noticed two very specific things that might actually be the exact reason why Ventoy fails while Rufus works! I wanted to run them by you: 1. Case-Sensitivity (Sources vs sources): I noticed that in some parts of the script, the folder is written as Sources (capital S), and in others, it's sources (lowercase s). While Windows doesn't care about case-sensitivity, Ventoy's backend is based on Linux/Grub2, which is strictly case-sensitive. Could this mix-up be causing Ventoy to lose the directory path? 2. The autorun.inf Modifications: I compared your compiled autorun.inf with the original Windows one, and there is a huge difference: Your autorun.inf: Code: [AutoRun.Amd64] open=setup.exe icon=setup.exe,0 [AutoRun] open=sources\SetupError.exe x64 icon=sources\SetupError.exe,0 Original Windows autorun.inf: Code: [AutoRun.Amd64] open=sources\setup.exe icon=sources\setup.exe,0 [AutoRun] open=sources\setup.exe icon=sources\setup.exe,0 Since your script changes the [AutoRun] block to execute SetupError.exe x64 instead of the actual setup, if Ventoy reads the fallback [AutoRun] block during its emulation process, it will intentionally trigger a setup error or break the path routine! Also, the Amd64 block points directly to the root (open=setup.exe), which explains your earlier theory! What do you think? Could these autorun.inf modifications and the case-sensitivity be the culprit behind the Ventoy 'missing media driver' glitch?"
No, autorun.inf is used only when mounting on a live system (and still won't block setup), if booting from USB/ISO it is completely ignored. @SunLion Since Win 11 is 64 bit only you can remove the normal [AutoRun].
Sorry for the delay in replying, but I was out helping some friends and just got back. Actually, there's no code in the script to modify the autorun. I hadn't even noticed the difference you found. But when it comes to Microsoft, anything is possible. And it doesn't hurt to try and see what happens. Anyway, I'm investigating Ventoy further. I'm reading about "VentoyAutoRun.bat" and "Windows Command Line". I'll post any updates here. Best regards
I checked my install log, *.iso on Ventoy failed since June 2025. so it's NOT a new issue. hence, I moved to Rufus to install. no any issue. and no Ventoy since then.
That is absolutely fascinating. If there is no code in the script to modify autorun.inf, then Microsoft's own deployment or ISO master tools must be modifying it automatically behind the scenes. As you said, with Microsoft, anything is truly possible! It's great to hear that you are looking into VentoyAutoRun.bat and the official Ventoy command-line documentation. That seems like the perfect place to find a permanent solution for this routing issue. Take your time with the research. I'll be right here waiting for your updates and ready to test any new builds on real hardware whenever you are ready.
You are absolutely right, Rufus works flawlessly and it’s a great fallback. However, from a usability standpoint, Ventoy is just on another level. For instance, I use a 250GB USB flash drive filled with about 10 different ISO images that I need to keep with me all the time. With Ventoy, I can store and boot them all from a single drive. If I switch completely to Rufus, it occupies the entire 250GB drive just for one single ISO, which feels like a huge waste of space and convenience. That's why I really hope we can find a solution for this Ventoy compatibility; it’s just too useful to give up!