Rufus write-protected my USB drives! #313
Comments
Then, considering that no application is able to write to your drive, it looks like a hardware failure. The flash memory contained on USB pendrives is not everlasting, and, yes, flash drives can fail in a manner where you can read existing data but not write it. Or, most likely, you might have gotten "fake" drives, which report more capacity than they really have, and will fail in the same manner as soon as you exceed the real amount of flash they have (something like 512 MB or 1 GB). Were the 2 drives you tried from the same manufacturer? In millions of downloads of Rufus, this is really the only report I have ever gotten of a drive failing with write protected, and, while many people seem to think otherwise, Rufus does not do anything fancy to flash drives: formatting a flash drive is not a risky operation at all, and furthermore, your issue occurred while Rufus was copying files, which it does in a manner that is no different than if you had been using Windows explorer to copy them yourself. I'm pretty confident that that both your drives would have failed the same way if you had stopped Rufus right after it was done with the NTFS formatting, and then copied the files yourself using 7-zip or something else to extract the content from the ISO. So really, if the 16 GB you used were from the same manufacturer, my best guess is that both your drives are fake. Was it the first time you copied more than 512 MB or 1 GB of data to any of them (fake drive are designed to look OK when formatting or as long as you don't copy too much data - it's only when you attempt to write more actual data than they can hold that they will reveal themselves as fakes)? This being said, I'm also trying to analyse other possibilities, just in case: In Windows 7, you can easily create a VHD of any size by launching "Computer Management" in Administrative Tools (from the Control Panel) and then left click on "Disk Management" under Storage on the left handside (so that it refreshes the list of disks), select any disk on the right handside, and then right click on "Disk Management" on the left handside, where you will be able to select "Create VHD". From there you can tell Windows to create a 16 GB to be used as a VHD, which Rufus 1.4.7 will detect and let use use as a flash drive. Can you please try that and let me know how it goes? EDIT: Rufus 1.4.7 ALPHA can be downloaded from here. |
|
yes both are from the same manufacturer and same model and i have had used them (sometimes used full capacity of them) many times before and had no problem with them. as for iso file, i made it from combination of these torrents and note that it is not cracked and you need to enter your own license for activation. as for lat part, i tried to make the VHD, but OK button is disabled and it needs a .vhd file. where can i get it? |
|
This issue have happened for me too but not with Rufus. I did manage to get my USB-stick to work again. Try to search for "usb format tool" and you will find a lot of small nice program to test with. I have about 15+ different program so try that. What do you have to lose? Your USB-sticks are already useless if you can't write to them... |
|
i have tried a lot of ways already and all failed so far. |
|
I'm not sure which program it was. It was for some years ago. I have a list of program. Try to see if you can find them and maybe one of them can fix your problem? |
You don't need to provide one. The dialog is simply asking you when you want to create it (it needs a target file where it can store the virtual data). So if you enter something like If you were able to store more than 1 or 2 GB data on your devices, then it looks like they aren't fake. But the fact that they are the same model from the same manufacturer could still hint at a hardware underlying issue. Another thing I'd like to know, since it seems that your drives failed right when the process was starting to copy a very large amount of data (the 4.6 GB I had reports that, because Rufus is fast, when a large amount of data is sent over a subpar USB 3.0 extension cable, it may bring forward the low quality of the connection (USB 3.0 is A LOT less tolerant to interferences than USB 2.0), which can result in device disconnection and other symptoms. I would not expect the device to become read-only though. I assume you tried plugging your devices on a different port or a different computer altogether, and found they were still read-only, right? For what is worth, I have now tested the ISO against a 16GB Flash Drive, using version 1.4.6, and found no issues: |
|
i made VHD but no additional drive is added to my computer! what is the issue? also if it is important, in event viewer i got "the file system structure on the disk is corrupt and unusable" also i must say that in "diskpart"," DET DIS" command give me read-only=yes while "DET VOL" command give me read-only=no and which seteting did you used for making bootable usb with my iso? |
Make sure you use Rufus 1.4.7. As indicated above, VHD support is being introduced with version 1.4.7. Version 1.4.6 will not list VHDs. You can get 1.4.7 ALPHA here. If you still can't see it in 1.4.7, please make sure that Disk Manager lists it, and send the log. EDIT: Once the drive is formatted, you may have to check the "List USB Hard Drives" checkbox in the advanced options for the VHD to be listed (I'll fix that for the 1.4.7 release). See here.
Default, which is what you indicated you used. |
|
OK, i made a 10GB VHD and this is my log. (at first VHD was not listed in my computer and so i thought i did something wrong) i will be very thankful if you can help me correct my corrupt USBs. |
|
Well, your test indicates that both Rufus and your system seem to be working as expected, and that your problem is most likely a hardware one. Again, all Rufus was doing when your drives became read-only was copying files in the exact same manner as what would have happened if you were using Windows Explorer. At this stage, the formatting and repartitioning had long been completed, and I have to stress out that Rufus really doesn't do anything special when copying files (or even when partitioning or formatting a drive, that are as benign an operation for a flash drive as copying a file). So your drives turning to read-only seems to indicate an issue within the flash drives themselves, as you should be able to simply repartition and reformat the drive in Disk Manager otherwise. Also, googling for 058F:6387, which is the VID:PID of your drive, the very first result returned is a mention about some of these very same drives being fake, which I can't help to find highly suspicious... Now, considering your earlier report, please be mindful that you may not be able to tell if a drive is a fake by simply copying data on it, as Windows explorer will usually happily let you copy 16GB of data on a 16GB fake drive, without warning that something might be amiss. It's only until you read the data back and compare it that you will find something is wrong. Of course, the whole point of a fake drive is to make it look like everything is OK for as long as possible. So my current guess then is that you actually have been issued fake drives, and that the issue you experience will only be triggered when writing a file that is larger than the actual amount of flash your fake drive contains: When writing a larger file, the drive probably wraps the data around, before the OS or firmware has a chance to read/cache, update and write back the critical data it needs to maintain on the flash (such as allocation tables, etc.), which could very well explain the issue. As far as I'm concerned, when 2 drives, with a VID:PID that is known to have been issued for fake drives, appear to fail at the point where we are copying a single large file that is likely to far exceed the actual amount of flash contained if the drive is fake and therefore overlap, I'd say that there is a lot of circumstantial evidence pointing to the drives indeed being fake. Fake drives are unfortunately fairly widespread when purchasing media from unscrupulous Chinese manufacturer. I actually got stung myself a couple of years ago. Can you indicate where you obtained these drives? |
|
thanks for clarifying things. based on what you said, i assumed problem is from my usb drive's side and its brand and so tried and made another bootable 16GB usb drive which processed till 100% without any error. sorry for doubting your nice software i have had copied to and from both now-readonly usb drives without any errors many times before, so i doubt that first two usb drives are fake, though i am not sure. that now-readonly drives are APTECH brand while the one which succeeded is HP brand. as for where i obtained them, i got them from a normal (non-internet) shop near my home. |
|
question: how can i delete VHD? |
Not at all. I'd be suspicious of a software issue too if the same operation on 2 separate flash drives produced the same error, and these kind of issues are always worth investigating... The guy from the link I pointed above about the fake drives mentions that he used AlcorMP_080829 to successfully recover his drive, after correcting its size to the non-fake 4 GB. That tool seems to be available from this page. Unfortunately, it's in Russian, but maybe you'll be able to use it too to recover your drives?
Normally, the VHD drive will be gone as soon as you reboot. Or you can just right click on the "Disk #" part in Disk Manager (the part where you should also see the size and "Online"), and select "Detach VHD". Then to recover the space, just use Windows Explorer to delete the |
|
when i right-click on "disk management", there is only "create VHD" and "attach VHD". |
|
You need to click on the part that has the Disk number, NOT "Disk management". See the following screenshot:
|
|
thanks for the answer |
|
In a virtual machine that uses VHDs, such as Microsoft Virtual PC, absolutely. VHD is the default Virtual Disk format for Virtual PC, so Virtual PC will treat them as if they were real drives, and of course, if you used Rufus, they will boot with whatever bootable data you chose to put on them. Now, if you want to use them as physical drives (eg. you created a VHD and now you would like to copy it to an USB flash drive of the same capacity), then you will first have to duplicate the content using a tool like |
|
thanks again for the answer. |
|
Closing this issue. |
Make it two, last night my USB drive became write protected after I used Rufus to write a Windows 10 image to it. |
|
for what it's worth, this software messes up with USB drives. Exactly the same issue happened to me as what was stated originally by JH0EP commented on Apr 15, 2014. This time version 2.16 wreak havoc two of my perfectly working USB drives and wasted enormous amount of my time trying to fix the unfixable caused by this tool. |
|
I'm afraid that a report of 2 drives failing is not enough to conclude that the software is at fault, especially when Rufus is currently being downloaded about 3 million times each month, and the amount of reports about Rufus "seemingly" damaging drives is about what you'd expect to get from coincidental failures or people having simply bought a batch of cheap fake drives. You have to apply logic for a little bit of logic here, and realize that, if Rufus was indeed damaging drives, there would be an awful lot of people complaining about this out of the millions who use Rufus. The fact that this is not the case, in itself, is ample evidence that Rufus is no more harmful to USB drives than Windows Explorer. Furthermore, if Rufus was doing something dodgy, it would be exceedingly easy for anyone with the proper knowledge to demonstrate that this is the case. Especially, since Rufus has gotten quite popular, I doubt that, if Rufus was really the "destroyer of drives" that some people who experienced coincidental failures would like to paint it as, hardware manufacturers, who of course have a vested interest in not multiplying costly RMAs, would have had very little trouble, in the 5 or so years that this software has existed, to, 1. identify what set of "special destructive USB commands" (since that's what people who don't know much about USB flash drive seem to believe there exists) Rufus happens to send to flash drive that causes them to fail, and 2. Get in touch with its developer about this issue. Yet, none of that has happened, which, to say the least, isn't providing much credit to the theory that Rufus is damaging drives. Sadly, because most people aren't developers or have knowledge of how USB Mass Storage devices actually work in Windows (formatting is no more special than writing a file, and there is no set of "special commands" that one can send to a drive using any of the Windows APIs Rufus uses, to make it self destruct), I assume these words will continue fall on death ears... |
|
Hi @pbatard 👋 I don't think it is an isolated incident. My pen drive is also write protected. I only use my pen drive for writing Linux images. Last time I came home for vacation (4months back) I did a bad mistake of using my dad's laptop which had Rufus installed (by me of course), I was trying to troubleshoot the USB once again after my last try today (last time it lasted 3 hours googling and trying to fixing), just now confirmed the end point was Rufus. I am not here to complain about your software but maybe you could do a deep analysis of it somehow? PS: I don't think the majority of the people know about Github in the first place (since this is a windows tool) let alone where to report an issue about Rufus. And how many people will create a new account in Github to report an issue + talk about how scary it might be for a non-geek person to try and find a way around github. |
But if these aren't, how comes that despite having tested Rufus on every single computer and every single flash drive I could get my hands on, I have never ever been able to replicate such an issue. And neither seem to have any of the experienced power users of forums such as reboot.pro, or, as I mentioned, the manufacturers of the drives Rufus is supposed to write protect. In other words, to go with your hypothesis, we would also have to go with the hypothesis that: I and other developers and developers who are testing USB flash drives on a daily basis have been extraordinarily lucky in never ever experiencing the issue, despite the fact that, by all account if that issue is real, we would be the most affected by it.
Not really. What you did is confirm, that either one of Rufus or your flash drive has an issue, and, considering that it's only the internal flash drive controller that can decide to switch a drive to read-only and that (and I have to stress that out, because people who have no knowledge of how USB flash drive work really don't seem to understand that point) it is simply NOT possible for an external software application that only issues USB Mass Storage commands to tell the USB Flash Drive's controller to switch the drive to read-only. Instead, it's the internal logic of the controller that does that on its own, and the only factor it uses to do that is when it detects that some flash memory cells are defective (in most cases that happens when the controller itself is trying to write data to a cell, and the controller itself detects that the operation fails. Please bear in mind that there's no external entity involved in this operation besides the internal flash drive controller). But, hey, I hear you coming up with: "But surely Rufus is sending USB commands to the flash drive. What if there's a bug and Rufus happens to send a wrong command, such as one that might tell the controller to switch to read-only?" Unfortunately for you (and for the many people who are unaware of what USB software development entails on Windows, and think that it's therefore easy to screw up), that's not at all what Rufus does. Rufus does NOT directly send USB commands to anything. Especially we're not building any of the USB messages that are received by the flash driver controller. So, even if the application has a bug, it's never going to translate to "Oops, I wrote bad data into an USB field and inadvertently sent an USB message that tells the controller to switch to read-only, instead of simply writing data". Instead, what happens is that we ask Windows to perform some operations, such as "read or write sector n of device XYZ", "tell me the type of device ABC, so that I can find out if it's USB, and remove it from the list of devices I present to the user if not", and that's really it. As a matter of fact, the way Rufus is designed, it doesn't matter one bit if a disk device is USB, SATA, SCSI, NVMe, Virtual (VHD, VMWare), because there isn't a single section in the code where we construct and send actual bus commands, such as USB ones. In fact, a lot of the enumeration code of Rufus is to eliminate things like internal drives, because otherwise, Rufus would happily let you do the exact same thing to your internal SATA drives as you can do to USB drives. And, here's the kicker: I wouldn't have to change a single line of code in Rufus to make it partition and format an internal SATA drive as opposed to an USB drive, because Rufus doesn't need to care about the protocol being used when writing the drive. As a matter of fact, Rufus can already be used with external SATA drives (provided that the BIOS sees them as removable and that you use a well-hidden cheat mode), and I didn't have to do anything special in the code to achieve this, besides ensuring that less drives get eliminated during enumeration when the cheat mode is in effect. All this to say that all we are using in Rufus are the generic Windows API commands that let you read/write a sector or a file, and that, as per Windows design, are completely bus-agnostic. Or, to put it in terms that you may also have heard, we use the Hardware Abstraction Layer of Windows, and therefore do not have the possibility of sending straight USB commands. Alright, so that "comeback" point 1/3 covered, so let me get to "comeback" point 2: There again, I'm afraid that, if you know what you are talking about, you will have to dismiss the idea. The first thing I'm gonna point out is that, if this was at all possible, then surely there would be a Windows bug here, because what one expects from a Hardware Abstraction Layer API is that it will filter bad data, and prevent potentially destructive commands from being sent on the bus. In other words, if Windows was allowing anything like that, Microsoft would have heard about it from hardware manufacturers who, again, have in their interest not to have an OS that can ever send self destruct commands to hardware by mistake. And with this we come nicely to "comeback" 3: Two parts to this (NB: I'm simplifying things quite a bit here, which doesn't make the explanation any less valid, so if you want to dismiss the whole reasoning because it's not "technically accurate", you'd better be prepared to show where exactly my explanation would be disproved in the the more technically accurate picture):
So, in summary, and as I have tried to establish:
How's that for a deep analysis? Of course, you're welcome to ramp up your expertise on Windows APIs, Mass Storage command and USB, as well as spend some time with the Rufus source, to tell me why you (and others), still don't think what I went great length to explain above is unsatisfactory and why, surely, because you happened to experience a couple of drive failures while using Rufus, whereas millions of other Rufus users don't seem to ever have run into such such issues (and flash drive manufacturers also seem to be strangely quiet about the "destroyer of flash drives" that Rufus allegedly is), it must mean that Rufus is the culprit rather than your hardware...
You do realize that you're trying hard to justify why, if the problem is so widespread, the hundreds or thousands of people who have to be affected by it, out of the 3 millions that download Rufus every month, would choose not to report it. First of all, means of contacting me by e-mail are clearly available both on the Rufus homepage and in the About dialog. And (but you'll have to trust me on this), the amount of "Rufus destroyed my flash drive" e-mail reports I get is about the same as I see from other means. Also, people do use stackoverflow, reddit, and other forums such as mydigitallife, which I monitor, and likewise, you'll be hard pressed to see the tens or hundreds of reports one would expect to see there if Rufus had such a flaw as the one you describe. Your justification as to why so few people would report such an issue, if it was a real one, clearly does not add up, which, I'm afraid, can only mean one thing: the hardware issues people experience while using Rufus are coincidental. Oh, and for the record, there does happen to exist buggy firmwares out there, that seem to make some brand/models of USB flash drive fail more frequently than others. For instance, as per the List of incompatible hardware from the FAQ, some PNY drives have a dodgy firmware (which the manufacturer acknowledged), and I suspect that, if you have a couple such drives, and use them with Rufus, you will find that they consistently fail, even though this has nothing to do with Rufus (the issue should happen if you write a lot of data, regardless of the application being used). Finally, for anyone still tempted to try to push this "Rufus can destroy flash drive" story again, I'll say that any argument you are trying to make will have a lot more weight if you are able to report something like: Again, if the "problem" was as widespread as you say, and I as I pointed out before, there's no way flash drive manufacturers would choose to ignore it, and you should be able to get strong evidence about Rufus being the cause of the issue from the manufacturers themselves or power users with some USB expertise (e.g. people who know how to run an USB bus trace). Yet, despite the isolated but usually very voiceful complaints I have seen here and there about Rufus damaging flash drives, and despite Rufus having been quite popular for years, I'm still waiting for such reports... |
|
I have lost 3 USB drives to this same issue from different vendors. This is across 2 different laptops, both running windows 10. This is a screenshot of what I was doing. To date, i have not been able to recover any of them.
|
Full make and model please, and capacity. Did you purchase them from the same vendor? When were they purchased? I'd really like people who want to complain about Rufus consistently "destroying" drives to be consistent and produce bad blocks reports, especially when there are plenty of cheap drives out there, who either use poor quality flash memory or straight up lie about their capacity ("fake" drive) resulting in failure as soon as an application (any application, including File Explorer) writes more data to the drive than its actual capacity. Surely, if you start to see drives being damaged, you should have all the reasons in the world to check the next one you're gonna use for bad blocks, to get some indication about the actual health of your drive before you use it.
What do you see in Windows Disk Manager? Have you tried plugging them on a Linux machine? What does Finally is that 4GB drive from your screenshot a 4th USB drive? Coz if it's not, then clearly it's being recognized... I have now explained at length why its is simply not possible for Rufus, even if it has a major bug, to damage flash drives. You may choose to believe otherwise, because you happened to end up with drives that appeared to fail while you were using Rufus, but I'm afraid that you will have to point the finger elsewhere. It is simply not possible for an application that only exclusively uses But please feel to dismiss this fact as something that "of course the developer of a problematic application is going to lie about" and also feel free to invite your hardware manufacturers to investigate the true causes of your drive failures, when you RMA your drives. As I explained, if the problem is really as widespread and consistent as the few people who seem to have experienced it make it to be, hardware manufacturers, who do have a very vested interest in singling out applications that may "destroy" their drives, should have no problem backing up these claims. |
|
PS: It would also be of great interest to have the manufacturers of your drives to explain the specific conditions under which a flash drive will switch to read-only, because this is certainly not something that can be controlled remotely by an application, and, instead, is triggered by the internal firmware running on the flash drive controllers. Therefore, the manufacturer of a flash drive should be able to get very precise technical details on why it would switch to read-only. |
|
Hi Pete,
I can setup a webex to show what happens on my computer when I try and use the tool.
I am not a developer, other folks in my office seem to use it fine. I have not RMA’d any of the UBS stick as most are from vendors at trade shows.
John
|
|
I wasn't asking for help, just reporting. Also I don't want the dev to feel bad because of this situation. Again, some memory chips probably just work weird. |
@mrk310310 Isn't this to ask for help? |
|
I found the only way to deal with a "bad" usb stick was with the diskpart utility in Windows. In my case, a GPT had been created from a FreeNAS ISO that was unrecognized and unbootable in either a Windows or Linux machine. Disk manager saw it, but couldn't do anything useful with it. |
|
I just had two drives destroyed, one after the other. One a 16GB SanDisk Cruzer Glide, the other a 16GB Sony thumbdrive. Both of them failed saying that explorer.exe had a lock on the disk. I closed Explorer, and then the thumbdrive got marked as write protected. Two failures in a row is not a coincidence. I now have to go buy TWO 16GB drives for coworkers. |
Where and when did you purchase them? Can you RMA them? Last time I checked, SanDisk had a pretty comprehensive RMA policy. Also, please try to repartition/reformat your drives in Linux. I know of some images (e.g. Chromium) that, because of a pure Windows bug, will make it look like the drive cannot be repartitioned or reformatted in Windows after the image has been written, whereas Linux or MacOS have no trouble doing so.
Usually not. However it also doesn't not mean that the application you were using at the time was the cause of the issue. For instance, some FreeBSD images will instantly make Windows 7 or earlier BSOD, regardless of the application being used to write the image (another Windows bug - You can literally create a USB flash drive that make any Windows 7, Vista or XP machine crash as soon as it is plugged). But of course, when you experience a BSOD while you were using a specific application to write data, it's easy to think that it's the application that caused the system crash, even if it had nothing to do with it. If you can RMA the drives, I would strongly encourage you to do so. And if, despite all I have explained above, at length, on how when you are familiar with the manner Windows lets application write data to a drive, and how USB Mass Storage operates, then the only way a Windows application that only uses the generic abstracted I/O API to write to a drive could ever destroy a drive is if there also existed a major Windows bug, you still refuse to consider that your issues could have to do with something else than Rufus, then I will encourage you to let SanDisk or Sony support know that you were using Rufus at the time, and ask their specialists whether they believe that this software (of which they should be able to also consult the source) could be what actually caused your drives to fail. If these specialists think that there is a flaw in the explanations I have provided in this thread, with regards to how it is just impossible for Rufus (or other generic image applications like Etcher), to destroy drives in the manner that people who have experienced failure(s) allege, then they should have little trouble demonstrating, with indisputable proof that it is indeed possible for an application that only issues And yes, I understand that, because you have seen a drive failure twice in a row while using Rufus, it is tempting to believe that the developer would have a strong interest spewing bullshit, while refusing to acknowledge a real issue. But I can assure you that, if there was a real issue here, and if what I've been saying about abstraction and the handling of USB flash drive in Rufus making it impossible to destroy a drive is wrong, then there should be more than enough people users of Rufus with technical expertise, to disprove the claims I put forward and explain, with technical details, how the Windows Hardware Abstraction Layer, or the way Rufus accesses drives (which is through the HAL), can actually fail to protect USB Flash Drives. So, while I do not ask you to blindly take my word for it, I will however ask you to consider that the absence of any such reports has to be corroborative that no such a major issue actually exists. And before someone starts to rant about how it shouldn't be for others to "prove" that the application is defective, please remember that I have already explained, at length, how due to the APIs being used and the manner in which Rufus is accessing the drive (which it does in the exact same manner as it would a SATA HDD — As a matter of fact, you can tell Rufus to list and access SATA drives through a hidden cheat mode, provided you have also set these drives Removable in your BIOS, since all that cheat mode does is tell Rufus not unlist these drives), it is just as impossible for me to go with "But isn't it possible that there is some place in the code that may send the 'wrong' set of data to the drive? Why do you seem to refuse to consider that as a valid hypothesis?" as it would be to go with "But isn't still possible that the earth might be flat? Why do you seem to refuse to consider that as a valid hypothesis?". It just doesn't work that way. And this is even more difficult to accept as a valid hypothesis when:
Therefore, I can only exhaustively indicate that, while I am not denying that a small number of people appear to have experienced drive failures, that happened to occur while they were using Rufus, simply stating a "belief" that Rufus must be responsible for the failures is still not going to cut it, unless one also happens to have RMA'd their drive(s) and gotten some technical backing from the drive manufacturer (or some other specialist), to try to prove the technical aspect of the claim (and disprove my counter-claim, which, as some people don't seem to understand, I have long backed up with technical details). |
|
We also encountered the FreeBSD Windows-bug on Etcher balena-io/etcher#1839 |
No surprise there. I also replicated if with win32diskimager at the time, as well as Linux' I wish I knew what Microsoft actually fixed in Windows 8 to finally make that issue disappear. As far as I can tell, it seems to have something to do with improperly parsing GPT records... |
https://forums.freebsd.org/threads/62230/ has more details: I guess Windows is assuming that if there's a valid GPT at the start of the disk, there must also be a valid GPT at the end of the disk; and it then falls over when it tries to parse a non-existent GPT from the end of the disk (which of course contains entirely random data). |
|
Aha. That makes a lot of sense indeed (though not the part about parsing random data = crash). Because people have requested it in the past, I've been wondering about having Rufus fix the GPT backup record as part of the image writing for larger drives... But that's a discussion for another thread. |
|
@pbatard hey buddy. I had to come here to post this after going through multiple threads and your own here (which is closed now) in regards to usb drives and sd cards being rendered write protected after using Rufus. This is what I have found. IT IS NOT ACTUALLY RUFUS's fault not sure if the users above had the same experience (more on that below) but my sd card got write protected after I tried creating a USB using your tool. Tried multiple things to solve this (deleting partitions, recreating, using different tools, different formats, removing diskpart readonly attribute even) but it didn't work. I even tried to use the sd card on another machine and it failed. Next time I tried to be a bit more careful and realized my corporate policies on the laptop was forcing Bitlocker to be Turned ON and encrypt the drive. And if I specifically select Don't encrypt it. The drive was supposed to stay in a read only state. In other words write protected. What's interesting is this is written in such a small font under the option which says "Don't encrypt this drive" that you can actually miss it considering it's just not going to encrypt the drive and everything else would be hunky dory. Anyway. What's interesting is even in this state. Somehow Rufus actually is able to delete the partition (which kindda make sense since Bitlocker might only be working on the FileSystem level and not on the Boot sector or partition level) and this leads the drive to be in write protected state. At this point nothing that would do on this current machine would work. And on top of that the usb/sd card will not work on any other device. The solution to this is though is to put the USB/SD Card on another machine which is not governed by BitLocker. Run diskpart on the disk and clear the the readonly attribute by running the command "attributes disk clear readonly". Once you do that, you can use any formatting tool to format the sdcard/drive on same machine and then reuse it however you want. Hope this may help somebody somewhere. If this post is redundant or useless. Feel free to remove it :) |
|
@n30nwav, I appreciate the report, which is quite interesting indeed. I'll see if I can add a note about checking for Bitlocker in the FAQ, and try reformatting the card on a machine where Bitlocker is not active, coz this may help other folks who run into the same situation. |
Even I am facing the exact same problem. The diskpart solution didn't work because the readonly state is already set to NO. The current read only state is YES. However when I use the pendrive on Linux it works just fine. And this is the second time happening with two different pen drives. Don't know what's going on. |
Do you have BitLocker enabled on your machine, or some other security policy? Obviously, you are not experiencing a hardware failure, if your drive works just fine on Linux, and as @n30nwav pointed above, it appears that, on some platforms that have BitLocker enabled, the default BitLocker policy may enforce a drive to be seen by the system as read-only as soon as you repartition or reformat a drive that is not set to use BitLocker (which would be the default for Rufus). At this stage, I'm still waiting to hear for more reports to validate this, so that I can potentially try to detect the precise setting that decides this policy and see if I can try to warn users about it in Rufus. |
Now, even on Ubuntu it says the USB is read-only and cannot format it. I've tried all possible ways on the internet to fix it but to no avail. I also tried to make it non bootable (since it showed the pendrive was bootable) using Rufus which didn't work either because of the read only state. |
|
Also if the BitLocker policy is enabled, how do I get around it? I've created bootable pen drives from the same laptop previously and didn't face any issues. Yesterday I tried to create a Live USB of Manjaro and Rufus suddenly showed that the process had FAILED. I am facing this read-only state problem since then. |
I'm afraid I don't have that information. I'm just reporting what was mentioned above. But really, if your drive has been seeing what appears to be an intermittent failure, and then failed altogether, then it all points out to your flash memory being defective, which is the most common issue USB Flash Drives face, i.e. a pure hardware failure that wasn't induced by any software operation. A lot of people seem to be of the idea that: "If I was using Rufus when writing the drive, and the drive failed, then it must mean that Rufus has a bug", and yet, if the exact same thing happens (as it also commonly does) when using Windows utilities only, they automatically think "hardware failure" and let Microsoft off the hook, on account that, surely an entity like Microsoft would never ever introduce major bugs in Windows that can lead to complete destruction of the data you are explicitly trying to protect. But I'm afraid that is not how it goes. Hardware failures are common, especially for Flash Drives, because USB Flash Drives aren't built for as much long term reliability as other media, and you can't just point the finger at one specific application on account that you've seen a couple of pen drives fail while you were using it. All I am seeing from your report above points to a pure hardware failure and not anything that Rufus (or BitLocker for that matter) seems to have much of anything to do with. So your best course of action at this stage is to RMA your flash drive if it's still under warranty, and purchase a new one, as it's very unlikely you'll be able to salvage it. |
Well, if it was a couple of cases it could've been hardware failure. But don't you think so many people having the exact same problem of being write-protected right after they used Rufus has long odds of just being a coincidence? I myself faced this issue with two pen drives in one week. There's quite a possibility that Rufus did "something" that caused Windows to make the pen drives write-protected. Can you try to replicate the issue on your pen drive? For me both the times the problem occurred when Rufus failed to burn the ISO. The last one was when I tried to burn the ISO directly from an external hard drive instead of copying it to the machine which caused the error. |
The proportion of people experiencing hardware failures while using Rufus is pretty much what I expect from coincidental failures with an application that is downloaded more than 1 million times a month. If Rufus was the "destroyer of drives" that some people who happen to experience coincidental failures think it is:
Here's a message that I think is especially relevant in this day and age: There comes a time where one has to listen to experts, who do know what the heck they are talking about, and are actually trying to present an impartial, fact-supported view on a matter, regardless of whether you believe that they may have a vested interest of lying to you, rather than try to fling around the bullshit that some anecdotal poorly understood "evidence" has as much credence, if not more, than proper statistical data (and in this case the statistical data can be verified from this issue tracker, or reddit or superuser reports, that certainly do not hint in the slightest that drive failures occur in higher proportion when using Rufus than the rate you'd expect from using hardware, and especially relatively cheap flash memory, that is not designed for long shelf life).
Which is indicative of a hardware issue.
That's a much more logical explanation than:
What do you think I'm doing during Rufus development? Write code without ever testing and hope that it works? And yes, I am testing in various conditions, including picking ISOs from external drives, be them USB based or not (though, if you do know how OS and USB access really work, you'll understand that the idea that having a USB drive fail because you happen to be using the USB to read from a different device at the same time is simply ludicrous). |
|
I've had several USB 3 flash drives fail because they overheat when large amounts of data are written quickly. Some fail by converting to read-only mode. Some fail by completely disconnecting the internal flash memory chips from the internal controller, so the controller tells Windows that the device has no media. Rufus and Etcher get blamed because they write large amounts of data quickly. But the real fault is defective design of the flash memories. The same thing happens under Windows. Select a large file (for example download an ISO of Windows 10) and use Windows File Explorer to just copy the file to the USB flash drive. The USB flash drive will fail. I'm famous for blaming Microsoft when something is Microsoft's fault, but this one isn't. I have two reliable USB 3 flash drives. One has a case made of metal instead of plastic. The other has a plastic case but write operations are slower than for other drives, so I wonder if the maker knew they had to avoid overheating. |
|
I also had a few USB 2 flash drives fail by converting to read-only mode. Those were older, slower, smaller drives. I don't think the controllers overheated, but the internal flash chips maybe were rejects from other companies. |
Yeah, the flash-drive and SD-card market is so competitive (with constantly reducing prices, and constantly increasing capacities), that people are always looking for "bargains" on sites like ebay; so it's all too easy for people to buy fake / defective / low-quality drives, and then blame Rufus or Etcher when they inevitably fail. |
Thanks for the explanation! This was more convincing than any of those "Rufus didn't do it" jargon written elsewhere. |
It's sad that we live in an age where people need to be "convinced" about facts, and will dispute any technical information being given to them on account that, if they don't understand it (or don't want to research it), then it means that the information must be flawed or false. |
|
I'm going to lock this thread, because I am getting seriously tired of the bullshit of having to justify, with facts that nobody cares to look into, that, no, your basic assumption that "because it deals with USB drives it must be possible for a buggy Rufus to send 'magic' USB commands that destroy or write protect a drive" is not actually something that can happen. Feel free to continue this discussion elsewhere. |
and others
hello
for first time, i have tried to make an bootable usb drive from an +5GB .iso file.
i have used default settings of everything and chose my iso file and usb drive, then i pressed start button.
green bar slowly progressed to ~15% and the i got "write protected" message!
after that i tried and did repeat the process but now, always i am getting this error at the very beginning!
i can't post full log of when this problem happened, because i have had not saved log when this happened, but this is full log of now which give me error at the beginning ....
from after that, i can perfectly fine copy the few file that rufus copied to usb drive, from usb to hdd but i can not copy anything to usb, neither i can delete anything from usb or format it!
now even "delete" is absent in right-click menu!
i am getting this damn "write-protected" error from all the programs that i have tried so far! in this picture i was trying to copy a picture file to usb V
(http://ddlw.org/img/303xvz5s.jpg)
after that i thought maybe this usb drive, accidentally in the same time that i used rufus, failed due to hardware problems, so i tried another 16GB usb drive and exactly same thing happened!
so two 16GB usb drives of mine got faulty this way!
how may i correct this? (i am really frustrated.)
The text was updated successfully, but these errors were encountered: