Announcing Windows 10 Insider Preview Build 10547 for PC Insider

blutos cousin said:

I'm not farmiliar woth the Rufus issue but 10547 has a couple of other issues hopfully the next build will smooth out.

I used isotousb with build 10547 and the iso 10547. No problems.

fjk61011 said:

I used isotousb with build 10547 and the iso 10547. No problems.

OK, I feel like people may rightfully wonder at this stage: "Surely if other formatting applications don't seem to have a problem, this has to be Rufus issue, right?", so let me explain a little bit about this.

First of all, I need to point out that, as many people have found out, 10547 introduced a major regression with safely ejecting USB drives - If you look into the insider build feedback for 10547, you will see that many people report that safe ejection of USB drives is broken in this build, as you always get the message "device is in use". This behaviour, which has nothing to do with Rufus, is the actual root of the problem.

More specifically (AFAIK), what happens when a user request safe ejection of an USB drive is that the OS requests an exclusive lock for the physical USB device. Because of its exclusive nature, if the lock is granted, it indicates that no other application is currently using or planning to use the drive, which means the drive can safely be ejected. On the other hand, if the lock cannot be granted, it means that there is an application somewhere that said "Hey, I need to use this drive, and I'm not done using it yet!". This is where the "safe" in safely ejecting an USB drive comes from. If safe ejection is granted, you are guaranteed that there won't be an application trying to read or write from your drive when you eject it.

Considering the reports from 10547 then, it looks pretty clear that Microsoft either managed to introduce or modify a Windows native application, that somehow forgot to notify the OS when it is done with the USB, or that they broke the exclusive locking mechanism for USB drives, so that requesting an exclusive lock now fails most of the time.

Which brings us back to why Rufus is affected by this. Because Rufus repartitions and reformats USB drives, the first thing it does is request an exclusive lock for the USB drive, exactly as the OS will do when asked to eject the media. This is done to ensure that, if there is any other application trying to use that drive, we're not going to remove the floor beneath its feet. I hope you'll agree with me here that obtaining exclusive access is the sensible thing to do before you even attempt to reformat a drive...
Also, I should point out that requesting exclusive access can be a very important safety measure if, say, there is a major bug in your formatting application which could make it select the C: drive by mistake. If you request exclusive access, because C: is pretty much always locked by the system, even a buggy application should not be able to start reformatting or repartitioning that system drive by mistake.

However, since Windows makes it optional, it is very much possible to reformat/repartition a drive without requesting an exclusive lock and I guess this is what isotousb must be doing (or rather not be doing) if it isn't affected by the 10547 USB issue. Now, I'm sure the isotousb developers have been doing a fairly good job with their application, but I would suggest they try obtaining an exclusive lock to a drive before formatting it. Or this may also have been intentional, as trying to lock drives means you will occasionally run into complaints from users who can't format a drive, because they are using one application or another that doesn't properly relinquish access to it...

CountMike said:

How come I had no problems with Rufus after I re-partitioned USB drive in Easus PM. ?

Is that consistent behaviour? Or is it a one off observation?
Also, are you debating that there is a major issue, confirmed by many reports on the insider feedback app, with regards to safely ejecting USB drives in 10547?

Until Microsoft fixes this major confirmed issue, which, again, has nothing to do with Rufus but is the confirmed source of its problems with 10547, there really isn't much point in trying to figure out a workaround for something that Microsoft will need to fix.

Maybe the Easus people managed to find a way to forcefully kick applications that lock a drive. If so, good for them. But I don't think that's something I want to do in Rufus...

first time I tried Rufus, even windows lost it and would not show USB drive and after re-partitioning 10547 worked just fine and I can still see USB and files on it.

And I can also find anecdotal evidence from people using a flaky drive that seems to produce weird behaviour. Have you tried running a bad blocks check on that drive?

For what is worth, Rufus gets downloaded about 2 million times each month right now. If what you describe above was a widespread issue (rather than the expected outcome of people getting various issues due to their specific software or hardware environment - for instance, you'd be surprised how a flaky USB 3.0 extension cable can be problematic for a fast application like Rufus, where slower applications wouldn't have an issue), there would be many reports similar to yours...

Also, as I pointed out before, if you experience an issue with Rufus, you should really use the github issue tracker (which features prominently on the Rufus About dialog) to report it. Oh, and reporting also works a lot better when you can provide the complete log from when the application failed (which Rufus makes easy to obtain through a very prominent 'Log' button), as it should contain very important data as to why the operation failed, and what really happened. As far as I am concerned, when people don't want to report issues to the application author, when it's exceedingly easy to do so, I find it hard not to conclude that this is because they probably don't really believe that the application had anything to do with it...

Kari said:

As far as I know this is not a solution for those of us having UEFI systems. If I have understand it correctly the ISOTOUSB only creates a BIOS boot device, which does not boot on UEFI systems.

I was dual booting but I'm nearly certain the usb stick booted in uefi mode.