Rufus write-protected my USB drives!

[ghost]

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 ....

Rufus version: 1.4.6.440
Syslinux versions: 4.07, 5.10
Windows version: Windows 7 SP1 64-bit
Locale ID: 0x0409
Found USB device '2.0 Flash Disk USB Device' (058F:6387)
Found USB device 'Multiple Card  Reader USB Device' (058F:6366)
Device eliminated because it appears to contain no media
1 device found
Sector Size: 512 bytes
Cylinders: 2000, TracksPerCylinder: 255, SectorsPerTrack: 63
Partition type: MBR, NB Partitions: 1
Disk ID: 0x03663D5F
Drive has a Rufus Master Boot Record
Partition 1:
  Type: NTFS (0x07)
  Size: 15.3 GB (16455303168 bytes)
  Start Sector: 2048, Boot: Yes, Recognized: Yes
Scanning image...
Disc image is an UDF image
ISO label: 'Win7AIO-SP1-x64-Mar2014'
  Size: 5513576448 bytes
  Has a >64 chars filename: No
  Has Symlinks: No
  Has a >4GB file: Yes
  ReactOS: No
  Uses EFI: Yes
  Uses Bootmgr: Yes
  Uses WinPE: No
  Uses isolinux: No
Using ISO: 22in1-Win7AIO-SP1-x64-Mar2014.iso

Format operation started
Requesting disk access...
Caution: Opened drive \\.\PHYSICALDRIVE4 for write access
Will use 'N:' as volume mountpoint
I/O boundary checks disabled
Analyzing existing boot records...
Drive has a Rufus Master Boot Record
Drive has an unknown partition boot record
Deleting partitions...
Could not delete drive layout: [0x00000013] The media is write protected.
Could not reset partitions
Re-mounted volume as 'N:' after error

Found USB device '2.0 Flash Disk USB Device' (058F:6387)
Found USB device 'Multiple Card  Reader USB Device' (058F:6366)
Device eliminated because it appears to contain no media
1 device found
Sector Size: 512 bytes
Cylinders: 2000, TracksPerCylinder: 255, SectorsPerTrack: 63
Partition type: MBR, NB Partitions: 1
Disk ID: 0x03663D5F
Drive has a Rufus Master Boot Record
Partition 1:
  Type: NTFS (0x07)
  Size: 15.3 GB (16455303168 bytes)
  Start Sector: 2048, Boot: Yes, Recognized: Yes

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.)

[karan316]

All I am seeing from your report above points to a pure hardware failure

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.

[lurch]

https://github.com/pbatard/rufus/wiki/FAQ#Help_Rufus_damaged_my_flash_drive

[pbatard]

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?

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:

1. I, its developer, who creates drive after drive, with ISOs of all kind, would see these failures too. But I have not even seen it happen once! And in case you also believe that I am just sitting on a pile of dead drives and lying, please realize that there are quite a few power users who use Rufus even more than I do, and who, curiously aren't creating issues in this very public issue tracker to complain that they have to keep purchasing new drives.
2. When you know how Rufus (and other similar applications) actually write any data to a drive, and yes that applies even to the "critical data" that one uses to format or repartition a drive, and know about Windows' abstraction layer, as well as, there again contrary to a common misconception, that Rufus is not actually building and sending USB commands on the USB bus in the application itself, the idea that Rufus (and other similar applications) could have a bug that results in hardware destruction is ridiculous. But please don't take my word for it: There's plenty of resources you can use to educate yourself, and if you look at the source code of Rufus, you'll see that it really writes to a USB drive the same way as it drives to a VHD or any type of drive for that matter, so, unless Windows has a major bug, it would be very difficult for it to send the set of commands that allegedly destroy a USB drive...

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).

For me both the times the problem occurred when Rufus failed to burn the ISO.

Which is indicative of a hardware issue.

1. Hardware has an issue
2. Rufus reports the problem
3. User notices that the hardware has an issue.

That's a much more logical explanation than:

1. Hardware is absolutely fine and even as we know that flash based media is super prone to fail on you at any time, especially if it's a cheap one, is not at all about to fail.
2. Rufus writes to said media and, even as there are tons of elements that do get in the way of doing so (the Windows Hardware Abstraction Layer being just one of them) somehow manages to send a mysterious special command, that flash drive manufacturer have somehow not protected or made next to impossible to enact, that tells a drive to self destruct.

Can you try to replicate the issue on your pen drive?

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).

[nxdiamond]

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.

[nxdiamond]

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.

[lurch]

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.

[karan316]

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.

Thanks for the explanation! This was more convincing than any of those "Rufus didn't do it" jargon written elsewhere. So is there any way you could determine which pendrive is safe to write huge amounts of data?

[pbatard]

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.

[pbatard]

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.