Windows To Go - ISO Image Extraction Failure #1637
Assignees
Milestone
Comments
|
Yes, I'm afraid I've seen that issue to some extent with some drives with the removable attribute (drives with the fixed attribute seem to fare better) ever since I tried to switch to creating the Windows partition (ESP, MSR, Data) in the Microsoft recommended fashion. The problem as far as I can see is that, for reasons that Microsoft will really have to explain the logic of__, when it sees a drive that looks to it like a Windows system disk on a removable media, it may decide to suddenly remove the drive letter of the data partition as applications are accessing it. So this is what you are seeing here: The image apply errors are due to Rufus no longer finding the target drive, which is further confirmed by: This is not something that I'm seeing consistently however, and, as I said, it doesn't seem to occur with FIXED media (which are better suited for Windows To Go anyway), but so far I haven't found a good workaround to tell Windows not to suddenly disconnect the drive. For instance, in case this was just another instance of Windows trying to hide an ESP from the user (since Windows forcibly prevents people from being able to access an ESP), I tried to create the ESP as a regular data partition, but this didn't seem to help. From what I can tell it seems to be a combination of Windows seeing a "small FAT partition/ESP + MSR + main data partition" in that order, on a drive with the removable attribute, that appears to trigger a potential drive removal from Windows. So, if you are experiencing this issue, you may want to try to revert to Rufus 3.11, as we are using a "MSR + main data partition + ESP" layout, that isn't the Microsoft recommended one (and that can be problematic hence why we tried to change it) that doesn't seem to produce that behaviour. Or you can try to use a drive with the fixed attribute, which are less common, but, again, more suitable to be used as a Windows To Go drive. Or you can try to contact Microsoft support and ask them what the heck is their problem with forcibly removing a removable drive in the middle of a file copy operation, when it contains an ESP and an MSR, because it's certainly not Rufus that is triggering that removal... |
10 tasks
|
I have tested some more. There's an unrelated issue due to ba40684 (I may need to find another way to work around the There are a few other issues I'm picking up though, so it may not be that simple... |
|
Thank you for the response, Pete. Please let me know if I can provide any additional details that can be of use. |
|
Okay, so by the looks of it, Windows has a BUG whereas, for removable drives, it will sometimes drop the last logical volume from the system, for no particular good reason. This means that if you have something like:
Then, depending on some Microsoft's internal lottery, Windows may only report:
And the thing is that, as we have seen, Windows might actually remove that last volume while you are already in the process of using it. You can actually see that with the Now, when we used to have MSR, Main Data and ESP in that order, this wasn't much of an issue, because we have other means than the volume GUID to access the ESP, and Windows tends to leave it alone anyway, since it is designed to hide it regardless. But of course, once you move the Main Data partition to the last slot, as we did for Rufus 3.12, having Windows remove it right under your feet it a lot more problematic... I guess the "solution" is to create another extra small partition after the Main Data, that Windows can then remove at its leisure, so that it leaves the Main Data partition alone, in a technique that I call "dangling keys in front of a toddler to distract it", but I sure wish Windows had achieved object permanence already, instead of expecting programmers to babysit it... |
|
Okay, after much trial and error, I think I may have found a way to work around this issue, which will be part of Rufus 3.13. If you are affected by this, can I please ask you to download Rufus 3.13 ALPHA and report? During my testing with this version, I did not see the previous errors when creating a Windows To Go drive on a removable media, but of course, I wouldn't mind some more testing to validate that the workaround works. |
|
That same problem happens to me but with linux (distro based on debian) as I would in that case |
|
Please don't truncate the log, as I am missing important information. For one thing, I have no idea if this was with 3.12 or 3.13 ALPHA. And you chose not to disclose the actual ISO you were using, which is annoying. I'm afraid I will need this data from you, as I can't do much without it. |
|
Oh, and for the record, error code What happens if you set the size of the persistent partition to 10 GB? |
|
For anybody still facing this issue, please try with Rufus 3.13 BETA and let me know if you are still seeing issues. |
|
Closing on account that this should be fixed in the 3.13 release |
|
I had this problem when trying to use ISO from a network drive, worked fine after I copied it to a local drive. Just noting it in case someone else has this issue. |
|
The network access issue is documented in the FAQ. Please bear in mind that an application that runs elevated does not have the same credentials to access or map network shares as your regular user, and if you have network drives, you will see the exact same access problems if you to run So, as advised by the checklist, please don't forget to read the FAQ, as you may find that your issue is already known and explained there. |
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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
First, thanks for providing and maintaining this tool. I am attempting to install Windows To Go on a 64 GB Sandisk Cruzer USB. The ISO I am using is downloaded from the Windows 10 site without using the media creation tool; clicking the checkbox in Rufus and pasting the SHA1 hash into the website provided in the Rufus FAQ confirms the validity of the ISO. Bad block check has come back negative.
After a successful but very long bad block check, progress halted around the 25% mark due to ISO Image Extraction Failure. This same error has occurred on two other USBs, plugged into two different drives on my laptop at around the same level of progress. Any help here (even if it's just to say "give up, not going to work") would be greatly appreciated!!!
Log
The text was updated successfully, but these errors were encountered: