pbatard
commented
4 years ago I installed Windows 10 1909 using a media created by Rufus very recently (using the official MS ISOs), and nobody else appears to reporting this error, so the first thing I need to point out is that this is not a general issue that Rufus introduced with Windows 1909 ISOs, because, by now, there probably has been thousands and thousands of people who installed 1909 using Rufus without any issue, including people using the official Spanish image (you are using the official 1909 Spanish ISO, right? If so, it might be worth checking its SHA-1 as explained here).
Therefore, there must be an environmental component to your issue, even more so as the \windows\system32\boot\winload.[xxx] files you mention do not need to be explicitly copied by Rufus, but come from install.wim. You can validate this by opening the install.wim from your USB with 7-zip, then opening sources\install.wim and picking one of the version index (the 1, 2, etc you'll see in 7-zip after opening the .wim) and then navigating to windows\system32\boot\.
If the files are there, then the Windows installer should be able to access them, and if it can't, this is unlikely to be a problem caused by Rufus, because all Rufus does, really is copy the whole content from the ISO onto the NTFS partition, and, apart from installing the UEFI:NTFS bootloader to a second small partiton (but this cannot have any incidence on the files being seen by Windows, because once Windows boots the installer, it can access the full content of the NTFS partition as well — Plus, this only applies to UEFI and you indicate that you see a similar issue in BIOS mode, where the second partition and extra bootloaders are not used, which pretty much confirms that this logically is exceedingly unlikely to be caused by Rufus).
Now, since you seem to have trouble with one of the early efi loaders, I know that some weird UEFI firmwares try to bypass regular UEFI entries (\efi\boot\bootx64.efi) when setting up boot entries for Windows, and instead try to create boot entries that point directly to the Windows bootloader (such as EFI\Microsoft\Boot\bootmgfw.efi). So I am wondering if maybe you have a UEFI system that bypasses the regular bootloaders and tries to look for a specific one... that may no longer exists.
Of course, the fact that you are observing the same thing in BIOS/CSM mode would tend to discredit that theory, but once again, I can only point out to the fact that myself and a large number of users have managed to perform Windows 1909 installations without any trouble, using drives generated by Rufus, and therefore that there is an environmental component to your issue that needs to be identified, because it certainly is not Rufus on its own that is the cause of your issue.
Another thing that I'm thinking could be the source of your issue is if you have some early anti-malware protection enabled in your UEFI settings, such as something that prevents boot records fro being modified (which the Windows installer might need to do), coz this could also explain why you are seeing this issue whereas everybody else seems to be fine.
I guess that, at the very least, so I can go through a installation of Windows 1909 Spanish (coz there have been instances where Microsoft screwed up the ISO for a specific language, though if they did that for Spanish, I'd have more than one report by now), I will need to know:
- The SHA-1 of the ISO you used
- The version you picked ("Pro", "Home", etc.), if asked, during the install process.
Still, I would encourage you to look for specific environmental settings/"BIOS" options to play with as well as look for manufacturer documentation or support forum for your motherboard, as testing will most likely show that it does work for other people creating their image in the same manner you did, and therefore that there really won't be much that can be done in Rufus to hep you out.
blackcrack
lock[bot]
Checklist
<FULL LOG>below.Rufus version: x.y.z- I have NOT removed any part of it.Additionally (if applicable):
(✓)button to compute the MD5, SHA1 and SHA256 checksums, which are therefore present in the log I copied. I confirmed, by performing an internet search, that these values match the ones from the official image.Issue description
Rufus creates bootable Windows 10 1909 Single Language x64 installer with no errors for a GPT+UEFI laptop. When booting installer, it shows a error screen. Missing file (\windows\system32\boot\winload.efi) with error code 0xc0000225. Laptop is on UEFI mode and secure boot off. (See first log)
Same situation when creating a MBR+(BIOS or UEFI+CSM), same error code, missing file is \windows\system32\boot\winload.exe. Same laptop switched to legacy mode and secure boot off. (See second log)
Asked on reddit, rufus developer (Akeo) responded. More details on link below: https://www.reddit.com/r/windows/comments/f860zt/windows_10_installer_unable_to_boot/
Log (UEFI)
Log (BIOS)