pbatard
commented
3 years ago I tried to boot with that USB on other computers and there was no problem.
As much as I'd like to be able to help, I'm afraid that, in the absence of anybody else reporting a similar issue, the only people who are likely to be able to resolve the issue are Microsoft (who wrote the efi\boot\bootx64.efi that appears to be freezing) or Samsung (who should have some insight as to what in their UEFI firmware might be causing issues with Windows bootloaders).
By the time UEFI:NTFS prints Launching 'efi\boot\bootx64.efi', it has handed over, fully, to the Microsoft bootloader, and, because this is closed source software, nobody else but Microsoft has any insight as to what it is doing and why it may freeze.
And I know you might be tempted to point to Rufus using a custom UEFI chain loader and also to the Microsoft bootloader running off an NTFS partition rather than a FAT32 one, but the thing is, when you are dealing with UEFI, there's absolutely nothing fancy about this. The whole point of UEFI is to abstract the file system and launch process so that it should NEVER matter to the bootloader being run whether it was chain loaded or if it has to access resources from this or that type of file system. And the thing is, the UEFI NTFS driver used by Rufus should be UEFI compliant enough so that a UEFI application, such as the Windows UEFI bootloader, shouldn't care whether the initial file system it loads resources from is FAT32, NTFS or whatever else you can think of, for which there exist a UEFI file system driver (because if it does, then it means that either the bootloader or the hardware is not really UEFI compliant, as if it is, it should really treat all file systems in the same manner). And the same goes for the way in which UEFI:NTFS launches the Microsoft bootloader, which (once the driver has been set up) is to simply call the universal generic UEFI APIs LoadImage() and StartImage() (and if there was a failure when invoking those, we would report an error).
So, even as UEFI:NTFS was invoked to run the Microsoft Windows bootloader, once the hand over process is complete, and your screenshot shows that it was completed successfully, then any problem that occurs is the responsibility of either Microsoft or Samsung, and, considering that the same USB drive works on another computer, I would point the finger at Samsung probably having introduced some incompatibilities in their UEFI implementation which leads to the problem you are seeing.
I am therefore afraid that I have not choice but to close this issue, since it's a problem that is external to Rufus, and, especially, I do not see anything that I could do any differently in the UEFI:NTFS bootloader (whose source is actually very short, because it basically just tells the underlying UEFI firmware "Load this" or "Find that", using very standardized UEFI API calls) to avoid your issue. I would instead suggest that you log an issue with Samsung support, who might have a better idea of how their hardware, and especially their UEFI firmware, differs from other PC hardware.
github-actions[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
Hi, I wrote the latest Windows 10 image with Rufus. When I try to boot on Samsung NP350V5C it freezes at "Launching 'efi\boot\bootx64.efi'...". I tried to boot with that USB on other computers and there was no problem.
I have another USB that has OpenCore bootloader in it. I tried to boot Windows USB with that. At first there was no problem but then this problem occured.
You can find hashes of iso file in log. I don't know how to find hash from windows' official website so i can't compare hashes.
Log