Announcing Windows 10 Insider Preview Build 10547 for PC Insider

CountMike said:

Every time I tried Rufus , 2.3, 2.4 and 2.1, USB was proclaimed *In Use* and would not show in computer after that.

I sure would like to see a log then. The "in use" message should usually come before Rufus attempts to write anything to the drive, so I'm puzzled your drive would disappear altogether. Or maybe you were using one of these weird Lexar JumpDrive Secure devices (see below).

Also, please be mindful that there are a bunch of applications (e.g. Defraggler, Genie backup Pro, etc.) that take a lock to an USB drive and never relinquish it, which they shouldn't do. See the list here.
This means that the only applications that are going to be able to format such drives are the ones that don't request an exclusive lock. This is the precise reason I said the isotousb people might have deliberately chosen not to request an exclusive log, as there are quite a few applications that can be problematic if you do.

I also tried to make 10240, 10525 and 10532 with same results, so it can't be because of 10547 ISO.

Okay, then your issue has nothing to do with 10547, in which case you're kind of hijacking a thread that's specific to 10547 for something unrelated.

Considering that after re-partitioning all of them worked (this time I tried Rufus 2.4 only), all 4 versions of W10 worked but with re-partitioning only, so it must have been some interaction between windows 10 (10240 and 10547) and Rufus and the blame is not on either of them alone.

Aside from using applications that can lock the drive (using Windows 10547 is not the only way you can find your drive locked), there are also other factors, such as using USB drives with encryption, such as some Lexar Jump Drives. These drives prevent low level access without jumping through hoops, and I could certainly scenarios where the drive would disappear if you try to repartition it. Also, have you tried listing all drives from Rufus' advanced mode? Or have you tried to see what the USB Debug mode of Rufus said about the detection process (Alt-.)? There are just two things that I could have advised you to perform, to try to figure out your issue, if you had just reported it.

You want to put part of the blame on Rufus? Sure. But please don't be surprised if, without any access to your logs, hardware or software data, I shift back the blame on to your environment, especially when you seem to be the only one reporting such a problem in millions of downloads, and you didn't take any steps to report it. I know this may sound harsh, but if you don't give the developer of an application any chance to look into a problem you're having, you may want to refrain from pointing the finger at their app.

There definitely is a problem with USB Flash Drives in build 10547. it will not let me eject the FD from the systray. I had to go into This PC and eject it. It is just a plain flash drive-no rufus on it. In 10240 it works without issue and every other build as well up to 10547.

Wynona said:

I've used Lexar USB drives forever and a day without issue until I got to Windows 10 Build 10547

Regular (non "Secure") Lexar drives should be no issue with Rufus. And of course, any USB Flash Drive, not just Lexar, is expected to be affected by the flaw from 10547. So there's nothing out of the ordinary here. AFAIK, it's only if you use "JumpDrive Secure" drives that you will encounter problems with Rufus, regardless of your version, mostly because these drives seem to install their own driver for access, and of course, you won't be able to access low level facilities using the standard Windows APIs then.

CountMike said:

First, USB drive was locked only in this instance while using Rufus to make bootable Win10, it worked fine and still does with any "normal" files, even Linux.

By files, I think you mean ISO images, right? So your issue was only when creating a Windows 10 bootable USB using Rufus. Well, that's new information. But it still doesn't give me critical details that I could get from the Rufus log that could prove or disprove your point about Rufus being at fault. From what you explain, and without a log (that would take about a few minutes to recreate on your side) I have to deduce that your locking issue happened much further down the line, compared to the 10547 problem which happens right away. This kind of problem could, for instance, be explained if you run a security solution that has issues with applications that create autorun.inf files, as I've seen some of those in the past. Of course, without a log, this is just a guess, and there's not much that can done to get the final word.

Those were my findings and you can put a blame to anything you want.

Sorry, but as long as you don't want to produce a log from Rufus, from an issue that you say you can consistently reproduce, I will indeed blame you for deliberately withholding information that might explain where your specific issue lies. If you are adamant that Rufus is at fault, surely you should have no qualms providing a log that could be analysed to prove the point you are trying to make about Rufus being of lesser quality compared to these other apps that appear to be unaffected.

I'm not going to make it a career of explaining it and dig any deeper to blame anybody or anything.

But you very much tried to blame Rufus, and you should understand that, by continuing to refuse to provide the log data from your issue, you are not exactly putting the cards in your favour here.

Moreover, if you do believe that Rufus is at fault here, and that other people are going to be affected by the issue you faced, I fail to understand why you would not want to report your data. Wouldn't you want Rufus fixed, if needed, or at least the issue properly investigated, to help those people?

And another thing, where the heck are you coming off to tell me that I'm "hijacking" the thread ? Pretty presumptuous of you.

Oh, so you didn't come with a clear agenda of turning the conversation away from an issue you had been observing outside of 10547, as grounds to reject the explanation I had just provided on why build 10547 has a bug that will specifically affect Rufus? If so, I would invite you to please re-read your comment in #433.

I don't see much of any other way to interpret your post but as a means to discredit my explanation, on account that you had found a way to intersperse an application that does who-knows-what when it comes to forcefully kicking out applications that may lock a drive (EaseUs PM is closed source, so there's no telling how they handle locking issues) as well as encountered an issue that looks similar with other Windows builds.

If you had stopped at the first question, I would have been fine, but somehow you needed to follow up with a separate issue, that you never bothered to officially report in the first place, as some clear means of trying to discredit the application or the explanation. So don't be surprised to find that I take objection to someone using "besides, the application also doesn't work when doing X, Y and Z", when this is clearly a separate discussion, that should have been reported much sooner, if you wanted to use it as a valid point.

Since than, I made a live Linux with persistence on same USB memory (Transcend 32GB) using Lili and is quite readable from my computer using both 10240 and 10547.

Yeah, as I tried to highlight, any app that doesn't attempt to exclusively lock a drive will probably have no issue with build 10547. But an app that does, which I tried to demonstrate is the safer choice, will. As a matter of fact, I did test that, if I remove that call in Rufus, it seemed to improve things with 10547.

So, let us take a look at the LiLi code and search for FSCTL_LOCK_VOLUME (which is how you request an exclusive lock on the drive to ensure that nobody else is accessing it - if there's another direct or indirect call that does the same, which is always a possibility, I'm not aware of it). Thanks to google, it's very easy to find if they do, at least in their front end. Well, as expected they don't. Okay, but LiLi is a weird beast that repackages a bunch of Windows tools, such as the 7z, Syslinux and dd. Well, searching locally for the latest LZMA SDK (the most official sources for 7-zip - sadly, there's not much of a searchable repository online) yields nothing. Syslinux then? Nope. Okay, dd then (which comes from chrysocome.net - dd for windows). Aha, a match at last! (in WinIOCTL.pas) However, this is just a redefinition, and it's not being used anywhere in the actual code. Bad, LiLi, bad - you should really lock your drives before formatting them!

So I do have a lot of confidence here as well that LiLi doesn't attempt to exclusively lock a drive and that there's still no pertinent information you can bring for the 10547 issue, or at least, information that seems to contradict the fact that, as I explained, the issue with Rufus in this build is a pure Microsoft bug.

Which brings us back to the separate matter of trying to figure out why you had an issue with 10240 and other (non 10547) builds. But of course, this is impossible to investigate and troubleshoot if you refuse to produce a log and produce details with regards to your environment...