With GPT partition scheme for UEFI computer and file system formatted in NTFS The problem is in the fact that the Windows Setup creates the first EFI partition on HD formatted in NTFS instead of FAT32. The Setup detects this formatting error and does not allow the continuation of the installation. If create partition on HD before start Installation, the setup work correctly. With GPT partition scheme for UEFI computer and file system formatted in FAT32 t The first EFI partition on HD is correctly formatted in FAT32 and the installation work correctly.
Actually you can disregard what I asked above. I have now reproduced the issue with en_windows_8.1_with_update_x64_dvd_4065090.iso. One thing is, you get a different error depending on whether you are using a FIXED or REMOVABLE USB flash driver. With REMOVABLE, you get the error you pointed out, and with FIXED you get "Windows installation error 0xc0000005". Now, I also have a good idea as to why the issue occurs (at least for REMOVABLE, I still need to confirm if the same is true for FIXED), and this has to do with me trying to make Rufus more compatible, by ensuring that the partition Rufus uses to load the NTFS EFI driver and then the Windows bootloader had its type set as an EFI System Partition. During my testing, I had used Basic Partition type (i.e. general data partition), but then I thought "Maybe there are some UEFI firmwares out there that will only list the loader partition as bootable if it's set as EFI System" so I changed the type. It turns out that, when the Windows installer sets a new GPT disk, it also creates a EFI System Partition. Until now I thought this wasn't an issue, but boy does Windows NOT like to see 2 EFI System Partitions on the same system during install. The solution for now: If you have a GPT partition editor, open it against your USB Flash Drive. You should then see something like this (gdisk on Linux): Code: Number Start (sector) End (sector) Size Code Name 1 2048 31275058 14.9 GiB 0700 Microsoft Basic Data 2 31275059 31275314 128.0 KiB EF00 UEFI:TOGO All you have to do then is change the type of the UEFI:TOGO partition (the NTFS loader), which has type EF00 (EFI System) to Basic Data, so that you end up with something like this: Code: Number Start (sector) End (sector) Size Code Name 1 2048 31275058 14.9 GiB 0700 Microsoft Basic Data 2 31275059 31275314 128.0 KiB 0700 UEFI:TOGO If you do that, as I was able to confirm on my UEFI system, you should be able to get Windows installed from an NTFS partition, in GPT/UEFI mode. Since this is a fairly important issue, especially as Rufus 2.0 advertised its ability to install Windows in UEFI/NTFS mode, I'll probably release a Rufus 2.1 soon(ish) to fix this.
I did my tests with en_windows_embedded_8.1_industry_pro_with_update_x64_dvd_6052086.iso This is an Update 3 release. And yes I'm trying to make a bootable Win8.1.3 install USB stick for UEFI computer on GPT disk and NTFS format for the stick, which is intended as REMOVABLE so this stick can be used to install Win8.1.3 on any EFI / GPT machine. And I really appreciate your solution [The solution for now: If you have a GPT partition editor, then open it against your USB Flash Drive. You should then see something like this (gdisk on Linux)] but my AIOs are targeted to a wide variety of audience that makes use of them so I'll wait for your fix, you know 2 or 3 clicks in Rufus interface and it's done!
OK. For what is worth, I have now confirmed that the same fix will also sort the issue with FIXED drives.
How? And from which file? What was the URL of the original download. Indeed. And everybody could create a corrupted file this way. Which won't matter much if the data is corrupted or problematic... Unless I can get access to an ISO that can replicate this issue (and you have not provided ANY data that allows me to do so), there's nothing I can conclude from the MS tool managing to seemingly complete the task. As I said, an application might be more forgiving to an issue than another. But if it were me, I'd rather find if the file I created has an issue sooner rather than later. Anyway, if you don't want to provide any of the information that would allow to try to replicate this issue (for the record, I would never ask to remotely access someone else's computer for troubleshooting), there's really nothing I can do here, and in the absence of verifiable proof that there is any kind of problem with Rufus, it's hard to take your criticism at face value.
You have went above and beyond for this one individual..I don't think there's anything else to prove, he uses custom ISO's/ESD's and reports your program is faulty. Meanwhile , thousands of users (me included), are successfully using USB installers created by Rufus..I speak for many when I say thanks for this awesome piece of software.
Well, one possibility I could venture is that this has indeed nothing to do with the image being used, but with the use of subpar USB controllers or USB extension cables, especially if you are using USB 3.0. The thing is Rufus is usually much faster than other tools. Especially, it is a lot faster than the MS utility. Now if you are using USB 3.0, this matters, because at USB 3.0 speeds, this means the controllers and cables will be churning a large amount of data. The end result is that the USB controller inside your computer will heat A LOT. If it it not properly cooled, this can be a problem if it wasn't also properly designed to withstand the heat, and it may freeze or reduce the transfer rate to try to cope. This is also an issue with the controllers inside some of the faster USB 3.0 Flash Drives out there, such as the Mushkin Ventura Ultra (I have one of those), so much so that it has code in its firmware that reduces the USB transfer speed when it detects that it's starting to overheat (you'll usually see the speed take a dive after a few minutes of fast transfers)... What this means for the question above is, if you have a USB transfer utility that's notoriously slow (like the Microsoft tool), then even if your hardware has heat issues, you may not notice anything amiss. But then, if an utility comes along that can consistently transfer USB data almost as fast as the hardware can stand it, hardware that has an issue with heat or fast transfers might not fare so well... Another separate issue I am aware of, which also usually manifests itself at USB 3.0 speeds, is the use of subpar extension cables. Because USB 3.0 is a lot faster than USB 2.0, it is also a lot more prone to interferences, especially if you use an extension cable. This is also something I've seen in happen. And there again, the maximum speed that an USB utility is able to transfer data will come into play, as hardware can usually recover from a few interferences if you aren't pumping that many packets, but it will have a lot more trouble if the transfer rate is maintained consistently high. Finally, to bring home the point that completely different tools can process (bad) input in completely different manner, I know that some of the Windows 7 ISOs that were poorly mastered by Microsoft will (righfully) be rejected with an error during the Rufus copy process, whereas DVD burning applications will simply ignore those errors and you won't notice that anything was amiss until later in the install process. i.e. Same input + different application ≠ same output. Now, I'm not saying the potential hardware issues described above are @pisthai's problem. But this is something I am aware of that could explain why he seems to be experiencing inconsistent transfer issues with Rufus, and not the MS tool, even more so if he's only ever tested on a single computer (which is why I asked him to test with a different computer). And there's not much I can do in Rufus if the hardware decides to cope with problematic data transfer by greatly reducing the USB speed (I've seen that happen too, in which case neither Rufus or the OS will detect an issue). I don't think I could justify reducing the maximum copy speed that can be achieved with Rufus, simply because some people are using subpar hardware... Of course, while the above is something that could explain the issue, I also want to consider the possibility that this may well turn out to be a problem with the app. However, to confirm and address an application issue I first: Need something that can be consistenty reproduced (as well as enough information with regards to the system to allow me or someone else to reproduce it). If this is an intermittent issue that seems to happen only on a single computer, it's difficult not to dismiss it as something linked to that computer's specific hardware or software, and therefore purely environmental. Which means that whoever reports the issue needs to have tried more than once, with the exact same input, and experienced the same issue. In case a specific image was used, I need to have access to that image, period. And for the record, since I see no official report of a Windows 10 TP 10041 ISO with an SHA1 of 91b84868507cdc1d474d54648a5d77f183fe4904, I still have no idea where the heck these various files came from, and it makes it difficult for me to want to go invest time in this whole ESD generation business, especially. I still haven't the faintest idea where I can get the exact same copy of the files @pisthai used for the ISO generation... In conclusion I would say the following: If, as previously claimed, @pisthai believes that there exists is a major problem with Rufus and Windows ISOs, that is bound to affect a large part of the million people who download the application each month, then he should be prepared to do whatever he can to help troubleshoot this issue, for all the people that are bound to end up in the same situation as his, by: Making sure he can consistently reproduce a similar problem, using the exact the same input, from different computers (Once installed, I guess his son's computer should come handy there...) Provide enough data to be able to either download or recreate the ISO he is having a problem with, with working URLs of where the data he used can be downloaded. The best in this case would be for him to upload his problematic ISO to one of the many file sharing services, so that I can download and test it. And I really don't care if it takes days to upload, or where it is uploaded, as long as I can get my hands on it. If on the other hand, he doesn't want to help with the above, then I'll have to consider that he doesn't really think that the issue he experiences is likely to affect anybody else...