I have a 2-in-1 convertible tablet thing that has really weird/quirky hardware. Specifically, the onboard eMMC does not work with the drivers built into Windows 11, but it does work with ones included with Windows 10. (and due to weird/quirky hardware there's no way to boot from any media except onboard eMMC or USB, so I'm stuck with this stupid eMMC controller). Could anyone help me understand how to properly downgrade the drivers in the Windows 11 wim images, please? The driver files are: dumpsd.sys, sdbus.sys, sdstor.sys, disk.sys, EhStorClass.sys, partmgr.sys. If I boot a Windows 11 image (any kind of image -- setup PE, recovery, what have you) I can't see the internal storage, and if I install Windows 10 and then upgrade to Windows 11 I get an "inaccessible_boot_device" BSOD. If I boot a Windows 10 iso, deploy a Windows 11 install.wim with DISM, and then manually replace those .sys files afterwards, the computer runs fine. But updates and sfc don't work properly because that's not how you're supposed to change drivers. Is there a way to properly extract these drivers and their .inf files from Windows 10, and inject them into a Windows 11 image? I'm pretty familiar with tools like MSMG Toolkit and NTLite, but these expect me to give them .inf files and I'm not sure how to get those. To be clear, I need to integrate these generic, stock, Windows 10 storage drivers (maybe not all of those sys files, but definitely some of them) but I don't want to lose the ability to service the resulting install. I have no idea how to do that. Thank you!
If the system is up and running: Grab this, go into package creator, press E to export all (3rd party) drivers, then create the driver pack.
I’ll try this right away and report back with my results, thanks! I forgot to mention, though: because these drivers are stock drivers, the “dism /online /export-driver” command doesn’t catch these drivers — Windows considers them not third-party. So if your tool does that, I worry it won’t work…
You might be out of luck, it uses DISM. Have tried pull the built-in drivers from a stock image before, but could never get it to work.
Yeah, it didn't grab them I just found relevant .inf files in c:\windows\system32\driverstore\filerepository on a Windows 10 install, and I'm waiting for MSMG Toolkit to finish saving WIMs that I integrated them into. I'm wondering if it might be as simple as that... (I feel like it shouldn't be that simple, but maybe?)
Didn't really go too far down that avenue after seeing it was having signing issues with transplanted stock drivers. Although I wonder if there's another way. Tried using Double Driver and got similar results.
Definitely the second worst thing about this s**tty computer is the slow, 32GB eMMC. Maybe I can find a way to purge the image of unused drivers and such since the hardware is so specific. I also need to figure out how to kill the storage system requirement from the installer, because as it stands setup.exe won't deploy to this system...
@cybrian Yeah. This is how forums should work, with people who use his brain, and makes good use of suggestions, instead of waiting blindly to be spooned. Apropos of that, I tried to provide some infos using some shortcuts, to spare time and avoid walls of text. So, to be more precise, MS bundled drivers may be signed or not, (I mean the .sys files) that's easy to check with a left click on the file say (I just checked) disk.sys is signed, dedup.sys is not. Other than that the signature of the file is not enough, the whole driver folder is tied with a catalog file, to prevent modifications to the inf file and the driver package as whole, not just the .sys. OEM drivers have a blahblah.inf and a blahblah.cat, blahblah.inf has a row "catalog = blahbah.cat" Ms drivers lacks that per driver catalog and (I think) are tied to systemwide catalog files, and that is the main problem. That said, if you replace a .sys file with another one which is signed, it likely works, IF the OS is newer than the .sys (but not that newer, maybe the same file from win 8 wouldn't be considered valid). Perhaps I'm not a guru of the matter, I consider my knowledge above the average, but still far from being exhaustive. Back to your storage, the best think you can do is to capture the image in a wim file, then reapply it using wimlib-imagex.exe apply with the option --compact=lzx. (then you have to rerun bcdboot to have the system bootable). Dism can do the job as well but I consider wimlib better for a number of reasons. This way your 16GB install will be reduced to just 6 or so (and if you use a 32bit OS you can go down to less than 4.0GB,and almost surely slow storage+relatively powerful CPU + compression + solid state storage = faster system (maybe a way faster system), and 2/3 of freed space (which is the opposite of what happens on platter HDDs). There is a catch on that, the new compress method doesn't keep nor inherit the compressed status, so any variable file will become larger after you copy or edit it. To (partly) overcome the problem I first compress the FS using the good old NTFS compression, then I capture the image, then I reapply using the LZX compression. This way the static files will stay compressed with the high ratio LZX compression (usually by a 2.5 to 3x factor), but the variable files (log, tmp, new SW installed, cumulative updates and so on) will stay compressed anyway although with a lower ratio of the NTFS compression (the blue files). Then once or twice per year maybe worth to redo the capture/format/reapply to regain the wasted space.
Try using the tool I linked. Deploy to any size vhdx. Have a x8700 atom tablet myself that's touchy with w11. Took a bit of trial and error for it to settle down. The redundancy offered with vhdx boot & deploy smooths out the troubleshooting process since it's easy to make "save points" along the way. Make sure to have a w10/11 boot.wim that's integrated with your storage drivers before making the jump (needs to be renamed bootmedia.sav). You can try with a USB first.
The discussion is about very basic drivers like disk.sys, which has nothing to do with usual drivers from WU. W/o it the system can't boot at all, so is not something that you can add later. The OS MUST have it from the beginning. The file can be updated, obviously, but that's matter of cumulative updates, not normal driver updates.
The kernel has to see the physical disk, to be able to do anything with vhd[x]s Just look at the devmgr from the native vhd installation, you see all the drivers you would see from an old school installation, plus the vhd "controller" driver (vhhdmp.sys) which is called "VHD loopback controller" in Win10, or "HBA hard disk card" in W7 (not sure about the exact translation in English).