Rufus: Rufus write-protected my USB drives!

Created on 15 Apr 2014  ·  109Comments  ·  Source: pbatard/rufus

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
303xvz5s
(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.)

picture ghost

Most helpful comment

I don't think it is an isolated incident.

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.

just now confirmed the end point was Rufus.

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:
_"But what if Rufus screws up the data it sends to the Hardware Abstraction Layer? Couldn't that somehow result in Windows sending bad USB commands to the flash drive?"_

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.
Also, and this is the most important point, you have to realize that these APIs are very limited. For instance, here is the __ONLY__ API call that is ever used in Rufus to write to an USB flash drive (either directly or indirectly, but the indirect calls always translate to WriteFile() being issued in the end).
If you know a little bit about programming, you'll have to explain to me how it's possible to screw up parameters so bad that Windows will end up sending a "bad" USB command on the USB bus. If you use the wrong handle, you're not gonna be accessing the flash drive at all (unless Windows is super buggy) so we can eliminate that. And we never use Overlapped mode (which wouldn't screw us up in the first place anyway), so that leaves passing either a wrong buffer (but if you address is corrupt, you'll get a segmentation fault in the Windows application, not on the target device) or a buffer with bad data... knowing that there's nothing in the Mass Storage protocol that will make the USB bus choke on specific data content (because it's of course designed to be data agnostic, meaning that, as far as the Mass Storage USB protocol is concerned, __any__ data you have in your buffer is just fine and there's no such thing as data that is "more valid" than other). In other words, you could write whatever random stuff you want in your buffer, it's never going to end up producing anything on the USB bus but a Mass Storage message that says "Here's some data for you, that you should write at address N". Especially, it's NEVER going to result in a non Mass Storage USB command (such as "vendor-internal: switch to read-only") being issued on the USB bus. Even if Rufus is buggy, all you'll ever get on the USB bus are regular "read sector N" or "write sector N" messages, that are the only messages Windows can produce in the way the application works, and that's it.

And with this we come nicely to "comeback" 3:
_"But what if you actually send garbage data for the USB controller to write, or tell it to write the data to some 'special sectors'? Surely if you do that, you may end up screwing up the drive!"_

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

  1. The idea that there exists "special sectors" on an USB flash drive, __that can be accessed through standard USB commands (such as the "write sector N" we've seen above)__ is wrong. That's not to say that there might not exist special sectors that are being used to store the controller firmware, but, unless that controller is buggy, it should never let you access these sectors through the regular "write/read sector N" commands. Especially, the sector at address 0 should be the very first sector that the controller designates as accessible for storing user data (NB: this includes the MBR or any sector that belongs to a partition table, which, as far as the controller, Windows and Rufus are concerned __ARE__ pure user data), and, unless it has a major bug, it should return an error whenever it receives a standard command that asks it to read a sector that is lower than 0 or higher than the total capacity the controller has reserved for user data.
    All this to say, even if you were to have a buggy application that somehow manages to get Windows to send a "write sector -1 with this data" command on the USB bus, the Flash drive controller will always validate that the sector it is being asked to write to belongs to the user data range, __before__ it does anything, and will return an error if it doesn't (that is, unless your firmware is very buggy, but even then, I can tell you that Windows should have validated the sector range before the controller gets to do the same, so even if your firmware is buggy, it shouldn't actually matter). In other words, no matter how hard you try, you can not use Windows's WriteFile() (which, again, after device enumeration, is the only call that Rufus ever uses that translates into sending USB bus commands) to overwrite something like the memory area that is used by the firmware (the only exception I can see for this is if you are using a "fake" drive, but if you do, then you can't expect any application, including Windows, not to mess that drive up as soon as you write more data than to it than its actual "non-fake" capacity), let alone toggle a firmware-internal flag such as "read-only" mode.
  2. But what about partition table sectors? Surely the sectors that hold the partition table must be "special" and writing buggy data into them might be the reason why a drive could turn read-only?
    Unfortunately, that whole reasoning falls flat when you know that Windows (or any other OS for that matter) does not see the partition table sectors (or MBR, or VBR/PBR or whatever other set or sector you were told were "special" because if you overwrite them you could lose your data — but please don't conflate losing data with rendering a drive inoperable, since you can always reuse a drive after you lose the data it contained) as any different than any other sectors from your drive. If you can take a completely blank drive and repartition it/reformat it in Windows, or even a drive that has been secure-erased, then clearly, there's nothing that "special" about some sectors compared to other, and, even if you write garbage data on these, the worst thing you'll have to do is repartition/reformat the drive. Especially, you will NEVER end up in a situation where you actually can't recover the drive, no matter what amount of sectors were overwritten with garbage data. Therefore, it is not possible to screw up a drive simply by writing the "wrong" data to any of the sectors that Windows can access.

So, in summary, and as I have tried to establish:

  1. Contary to what you may believe, The Rufus code does not construct and send USB commands on the bus, so, even if there's a major bug, it just cannot inadvertently construct and send a "self destruct" command to a device. Instead it uses the Windows Hardware Abstraction Layer, that makes ALL disk devices (USB, SCSI, etc.) be accessed in the same __abstracted__ manner, i.e. without any direct possibility of control over the USB bus.
  2. Even if Rufus somehow sent garbage/buggy data to the Windows Hardware Abstraction Layer (which pretty much means to WriteFile() since that's all it ever uses to write to a device), the only way it would be able to screw up a USB flash drive is if it were to write to the non-accessible firmware-internal flash drive memory, by attempting to write to a sector that is outside of the regular range for the device. Unfortunately, the only way that could ever happen is if both Windows and the flash drive controller are buggy, because both these entities are supposed to validate the range being accessed, and reject the request if the range is invalid. That's simply not realistic (but if you believe it is, then by all means you should complain to your hardware manufacturer first, because you have just acknowledged that they have done a very crappy job).
  3. And finally, with the knowledge that, even if it was buggy, the only thing Rufus can only ever realistically access are the actual user data sectors reported by the device, and that none of these sectors (partition table, etc.) are any special, and that any competent OS will always be able to rewrite them, no matter the garbage data they contain, we have pretty much demonstrated that it is simply not logically possible for an application like Rufus to render a USB flash drive read-only or make it fail, __UNLESS THAT FLASH DRIVE ALREADY HAD A HARDWARE ISSUE IN THE FIRST PLACE__ (in which case, writing a large amount of data, which is what Rufus typically does, will produce the same issue, regardless of the application being used).

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

PS: I don't think the majority of the people know about Github in the first place

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:
"Hey, I bought a couple of drives from a reputable vendor (e.g. SanDisk, Adata, etc.), but when I used them with Rufus, these drives switched to read-only. So I RMA'd the drives to the vendor, describing what I did, to ask them if they could replicate the issue. They have now come back to me and confirmed that Rufus is the source of the problem because [insert explanation from people who actually have some expertise on the matter here]...".

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

picture pbatard on 13 Aug 2017
👍4

All 109 comments

then i pressed start button. green bar slowly progressed to ~15% and the i got "write protected" message!

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:
The first thing I'm trying to do right now is get my hands on the Win7AIO-SP1-x64-Mar2014.iso to confirm that it works as expected with a trusted 16 GB drive.
The other thing that I'd like to ask you to do, and that won't require you to attempt to use another actual flash drive, is to create a 16 GB VHD (Virtual Hard Drive) in Windows, and use Rufus 1.4.7 ALPHA (the first version to support VHDs), to see what happens if you try to copy your ISO there. As it is a virtual hard drive, even if you get the write protected issue, it won't matter.

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.

pbatard picture pbatard on 16 Apr 2014

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.
http://194.71.107.80/torrent/9172512/Windows_7_SP1_AIO_x64_en-US_USB3_IE11_Baseline_v2
http://194.71.107.80/torrent/9787662/Windows_7_AIO_22in1_SP1_x64_en-US_IE11_USB3_Mar2014

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?

ghost picture ghost on 16 Apr 2014

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

Sopor picture Sopor on 16 Apr 2014

i have tried a lot of ways already and all failed so far.
which program solved your issue?

ghost picture ghost on 16 Apr 2014

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?
A Bootable USB
Bootable_USB_Drive_Creator_Tool
grub4dos
imageUSB
PeBuilder
PeToUSB
Ridgecrop USB FAT32 Format
Universal Netboot Installer
Universal-USB-Installer
USB Image Tool
USB Oblivion
UsbDeView
USBFormat
USBView
Win32 DiskImager
XBoot

Sopor picture Sopor on 16 Apr 2014

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?

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 C:\16GB.vhd for the path and then set the size to 16GB, Windows will create the drive for you, mount it, and Rufus 1.4.7 will then be able to use it.

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 sources\install.wim) is, are your drives USB 3.0 by any chance, and are you using an extension cable to connect them.

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:

Rufus version: 1.4.6.440
Syslinux versions: 4.07, 5.10
Windows version: Windows 8.1 64-bit
Locale ID: 0x0409
Found USB device 'SanDisk Extreme USB Device' (0781:5580)
Using autorun.inf label for drive G: 'CDROM'
1 device found
Sector Size: 512 bytes
Cylinders: 1946, TracksPerCylinder: 255, SectorsPerTrack: 63
Partition type: MBR, NB Partitions: 1
Disk ID: 0x00059F74
Drive has a Windows 7 Master Boot Record
Partition 1:
  Type: FAT32 LBA (0x0c)
  Size: 14.9 GB (16012894208 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 \\.\PHYSICALDRIVE3 for write access
Will use 'G:' as volume mountpoint
I/O boundary checks disabled
Analyzing existing boot records...
Drive has a Windows 7 Master Boot Record
Drive has a FAT32 FreeDOS partition boot record
Deleting partitions...
Closing existing volume...
Clearing MBR/PBR/GPT structures...
Erasing 128 sectors
Partitioning (MBR)...
Waiting for logical drive to reappear...
Formatting (NTFS)...
Using cluster size: 4096 bytes
Creating file system: Task 1/12 completed
Creating file system: Task 2/12 completed
Creating file system: Task 3/12 completed
Creating file system: Task 4/12 completed
Creating file system: Task 5/12 completed
Creating file system: Task 6/12 completed
Creating file system: Task 7/12 completed
Creating file system: Task 8/12 completed
Creating file system: Task 9/12 completed
Creating file system: Task 10/12 completed
Creating file system: Task 11/12 completed
Creating file system: Task 12/12 completed
Format completed.
Writing master boot record...
Drive has a Zeroed Master Boot Record
Set bootable USB partition as 0x80
Using Rufus MBR
Found volume GUID \\?\Volume{af5a83dd-89da-11e3-824c-0018f3d01f52}\
Caution: Opened drive \\?\Volume{af5a83dd-89da-11e3-824c-0018f3d01f52} for write access
Writing partition boot record...
Using Standard NTFS partition boot record
Confirmed new volume has an NTFS boot sector
Successfully remounted Volume{af5a83dd-89da-11e3-824c-0018f3d01f52}\ on G:\
Copying ISO files...
Extracting files...
Disc image is an UDF image
Extracting: G:\Info\MDL Forums.url (0.1 KB)
Extracting: G:\Info\creator.txt (0.2 KB)
Extracting: G:\Info\murphy78 - TPB.url (0.2 KB)
Extracting: G:\Net451\Automated-Install-Script.cmd (1.3 KB)
Extracting: G:\Net451\NDP45-KB2898869-x64.exe (26.0 MB)
Extracting: G:\Net451\NDP45-KB2901126-x64.exe (8.2 MB)
Extracting: G:\Net451\NDP451-KB2858728-x86-x64-AllOS-ENU.exe (66.8 MB)
Extracting: G:\Scripts\MicrosoftUpdate-OptIn.vbs (0.2 KB)
Extracting: G:\autorun.inf (0.1 KB)
Extracting: G:\boot\bcd (256.0 KB)
Extracting: G:\boot\boot.sdi (3.0 MB)
Extracting: G:\boot\bootfix.bin (1.0 KB)
Extracting: G:\boot\bootsect.exe (110.0 KB)
Extracting: G:\boot\en-us\bootsect.exe.mui (15.5 KB)
Extracting: G:\boot\etfsboot.com (4.0 KB)
Extracting: G:\boot\fonts\chs_boot.ttf (3.5 MB)
Extracting: G:\boot\fonts\cht_boot.ttf (3.7 MB)
Extracting: G:\boot\fonts\jpn_boot.ttf (1.9 MB)
Extracting: G:\boot\fonts\kor_boot.ttf (2.3 MB)
Extracting: G:\boot\fonts\wgl4_boot.ttf (46.3 KB)
Extracting: G:\boot\memtest.efi (596.9 KB)
Extracting: G:\boot\memtest.exe (474.4 KB)
Extracting: G:\bootmgr (374.8 KB)
Extracting: G:\bootmgr.efi (653.9 KB)
Extracting: G:\efi\boot\bcd (256.0 KB)
Extracting: G:\efi\boot\bootx64.efi (656.9 KB)
Extracting: G:\efi\boot\cdboot.efi (430.5 KB)
Extracting: G:\efi\boot\cdboot_noprompt.efi (430.5 KB)
Extracting: G:\efi\boot\efisys.bin (1.4 MB)
Extracting: G:\efi\boot\efisys_noprompt.bin (1.4 MB)
Extracting: G:\efi\boot\fonts\chs_boot.ttf (3.5 MB)
Extracting: G:\efi\boot\fonts\cht_boot.ttf (3.7 MB)
Extracting: G:\efi\boot\fonts\jpn_boot.ttf (1.9 MB)
Extracting: G:\efi\boot\fonts\kor_boot.ttf (2.3 MB)
Extracting: G:\efi\boot\fonts\wgl4_boot.ttf (46.3 KB)
Extracting: G:\efi\microsoft\boot\bcd (256.0 KB)
Extracting: G:\efi\microsoft\boot\cdboot.efi (430.5 KB)
Extracting: G:\efi\microsoft\boot\cdboot_noprompt.efi (430.5 KB)
Extracting: G:\efi\microsoft\boot\efisys.bin (1.4 MB)
Extracting: G:\efi\microsoft\boot\efisys_noprompt.bin (1.4 MB)
Extracting: G:\efi\microsoft\boot\fonts\chs_boot.ttf (3.5 MB)
Extracting: G:\efi\microsoft\boot\fonts\cht_boot.ttf (3.7 MB)
Extracting: G:\efi\microsoft\boot\fonts\jpn_boot.ttf (1.9 MB)
Extracting: G:\efi\microsoft\boot\fonts\kor_boot.ttf (2.3 MB)
Extracting: G:\efi\microsoft\boot\fonts\wgl4_boot.ttf (46.3 KB)
Extracting: G:\setup.exe (104.3 KB)
Extracting: G:\sources\EI.CFG (0.0 KB)
Extracting: G:\sources\actionqueue.dll (208.5 KB)
Extracting: G:\sources\admtv3check.dll (63.5 KB)
Extracting: G:\sources\alert.gif (1.0 KB)
Extracting: G:\sources\apds.dll (2.0 MB)
Extracting: G:\sources\apircl.dll (267.5 KB)
Extracting: G:\sources\appcompat.xsl (11.4 KB)
Extracting: G:\sources\appcompat_bidi.xsl (12.2 KB)
Extracting: G:\sources\appcompat_detailed.xsl (13.4 KB)
Extracting: G:\sources\appcompat_detailed_bidi.xsl (13.4 KB)
Extracting: G:\sources\appcompat_detailed_bidi_txt.xsl (13.1 KB)
Extracting: G:\sources\appcompat_detailed_txt.xsl (13.0 KB)
Extracting: G:\sources\apss.dll (237.5 KB)
Extracting: G:\sources\arunimg.dll (959.0 KB)
Extracting: G:\sources\arunres.dll (4.0 KB)
Extracting: G:\sources\autorun.dll (152.0 KB)
Extracting: G:\sources\background_cli.bmp (2.3 MB)
Extracting: G:\sources\boot.wim (211.5 MB)
Extracting: G:\sources\cbscore.dll (953.5 KB)
Extracting: G:\sources\cbsmsg.dll (28.0 KB)
Extracting: G:\sources\cdplib.mof (1.9 KB)
Extracting: G:\sources\cdplibuninstall.mof (0.6 KB)
Extracting: G:\sources\cmiadapter.dll (123.0 KB)
Extracting: G:\sources\cmisetup.dll (326.5 KB)
Extracting: G:\sources\cmitrust.dll (466.5 KB)
Extracting: G:\sources\cmiv2.dll (3.6 MB)
Extracting: G:\sources\cntrtextinstaller.dll (166.5 KB)
Extracting: G:\sources\compatprovider.dll (179.0 KB)
Extracting: G:\sources\compliance.ini (0.5 KB)
Extracting: G:\sources\compres.dll (10.0 KB)
Extracting: G:\sources\cryptosetup.dll (19.0 KB)
Extracting: G:\sources\cversion.ini (0.0 KB)
Extracting: G:\sources\diager.dll (38.0 KB)
Extracting: G:\sources\diagnostic.dll (155.0 KB)
Extracting: G:\sources\dism.exe (268.5 KB)
Extracting: G:\sources\dismcore.dll (283.0 KB)
Extracting: G:\sources\dismcoreps.dll (109.0 KB)
Extracting: G:\sources\dismhost.exe (94.5 KB)
Extracting: G:\sources\dismprov.dll (182.0 KB)
Extracting: G:\sources\dlmanifests\accessibilitycpl-dl.man (4.3 KB)
Extracting: G:\sources\dlmanifests\activedirectory-webservices-dl.man (0.7 KB)
Extracting: G:\sources\dlmanifests\activedirectory-wmireplicationprovider-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\adfs-federationservice-dl.man (2.3 KB)
Extracting: G:\sources\dlmanifests\adfs-federationserviceproxy-dl.man (2.3 KB)
Extracting: G:\sources\dlmanifests\adfs-webagentclaims-dl.man (2.0 KB)
Extracting: G:\sources\dlmanifests\adfs-webagenttoken-dl.man (2.3 KB)
Extracting: G:\sources\dlmanifests\adminui-dl.man (2.6 KB)
Extracting: G:\sources\dlmanifests\adsi-ldap-extensions-dl.man (3.6 KB)
Extracting: G:\sources\dlmanifests\adsi-ldap-provider-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\adsi-router-dl.man (1.9 KB)
Extracting: G:\sources\dlmanifests\adsi-winnt-provider-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\application_experience-infrastructure-dl.man (2.2 KB)
Extracting: G:\sources\dlmanifests\authui-dl.man (2.1 KB)
Extracting: G:\sources\dlmanifests\bitsextensions-server\bitsmig.dll (78.5 KB)
Extracting: G:\sources\dlmanifests\bitsextensions-server-console-dl.man (2.3 KB)
Extracting: G:\sources\dlmanifests\bitsextensions-server-dl.man (2.2 KB)
Extracting: G:\sources\dlmanifests\bluetooth-config-dl.man (1.4 KB)
Extracting: G:\sources\dlmanifests\browserservice-dl.man (3.1 KB)
Extracting: G:\sources\dlmanifests\capi2_certs-dl.man (3.4 KB)
Extracting: G:\sources\dlmanifests\commandprompt-dl.man (2.8 KB)
Extracting: G:\sources\dlmanifests\coreos-dl.man (2.0 KB)
Extracting: G:\sources\dlmanifests\credential-manager-dl.man (2.2 KB)
Extracting: G:\sources\dlmanifests\crypto_keys-dl.man (2.9 KB)
Extracting: G:\sources\dlmanifests\cryptoconfig-dl.man (1.4 KB)
Extracting: G:\sources\dlmanifests\dfsclient-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\dfsmgmt-dl.man (2.0 KB)
Extracting: G:\sources\dlmanifests\dfsn-serverservice-dl.man (4.2 KB)
Extracting: G:\sources\dlmanifests\dhcpclient-dl.man (1.5 KB)
Extracting: G:\sources\dlmanifests\dhcpservermigplugin-dl.man (4.1 KB)
Extracting: G:\sources\dlmanifests\directoryservices-adam-dl.man (2.5 KB)
Extracting: G:\sources\dlmanifests\directoryservices-domain-dl.man (2.3 KB)
Extracting: G:\sources\dlmanifests\directoryservices-ism-smtp-dl.man (2.2 KB)
Extracting: G:\sources\dlmanifests\dns-client-dl.man (3.7 KB)
Extracting: G:\sources\dlmanifests\dns-server-service-dl.man (2.3 KB)
Extracting: G:\sources\dlmanifests\dpapi_keys-dl.man (4.4 KB)
Extracting: G:\sources\dlmanifests\drm-dl.man (1.7 KB)
Extracting: G:\sources\dlmanifests\errorreportingcore-dl.man (1.9 KB)
Extracting: G:\sources\dlmanifests\errorreportingfaults-dl.man (1.1 KB)
Extracting: G:\sources\dlmanifests\etw-core-dl.man (1.3 KB)
Extracting: G:\sources\dlmanifests\eudcedit-dl.man (1.5 KB)
Extracting: G:\sources\dlmanifests\eventcollector-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\eventlog-dl.man (1.7 KB)
Extracting: G:\sources\dlmanifests\evntagnt-dl.man (1.9 KB)
Extracting: G:\sources\dlmanifests\explorer-dl.man (2.5 KB)
Extracting: G:\sources\dlmanifests\extensibleauthenticationprotocolhostservice-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\feclient-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\fonts-type1-dl.man (0.8 KB)
Extracting: G:\sources\dlmanifests\frs-core-dl.man (4.3 KB)
Extracting: G:\sources\dlmanifests\gpbase-dl.man (7.0 KB)
Extracting: G:\sources\dlmanifests\gpmc-dl.man (1.4 KB)
Extracting: G:\sources\dlmanifests\gpmgmt-dl.man (1.5 KB)
Extracting: G:\sources\dlmanifests\grouppolicy-admin-gpedit-dl.man (1.4 KB)
Extracting: G:\sources\dlmanifests\grouppolicy-admin-gpedit-snapin-dl.man (1.4 KB)
Extracting: G:\sources\dlmanifests\grouppolicy-cse-softwareinstallation-dl.man (1.9 KB)
Extracting: G:\sources\dlmanifests\grouppolicy-serveradmintools-gpmc-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\http-dl.man (1.2 KB)
Extracting: G:\sources\dlmanifests\iasmigplugin-dl.man (4.0 KB)
Extracting: G:\sources\dlmanifests\ieframe-dl.man (1.1 KB)
Extracting: G:\sources\dlmanifests\ime-simplified-chinese-migration-dl.man (1.4 KB)
Extracting: G:\sources\dlmanifests\ime-traditional-chinese-migration-dl.man (1.5 KB)
Extracting: G:\sources\dlmanifests\international-core-dl.man (3.4 KB)
Extracting: G:\sources\dlmanifests\international-timezones-dl.man (17.7 KB)
Extracting: G:\sources\dlmanifests\internet-naming-service-runtime-dl.man (5.4 KB)
Extracting: G:\sources\dlmanifests\ipsec-svc-dl.man (2.3 KB)
Extracting: G:\sources\dlmanifests\isns_service-dl.man (1.7 KB)
Extracting: G:\sources\dlmanifests\kerberos-key-distribution-center-dl.man (2.0 KB)
Extracting: G:\sources\dlmanifests\ldap-client-dl.man (1.4 KB)
Extracting: G:\sources\dlmanifests\mediaserver-aspadmin-migration-dl.man (1.0 KB)
Extracting: G:\sources\dlmanifests\mediaserver-migration-dl.man (2.4 KB)
Extracting: G:\sources\dlmanifests\mediaserver-multicast-migration-dl.man (1.0 KB)
Extracting: G:\sources\dlmanifests\microsoft-activedirectory-webservices-dl\adwsmigrate.dll (83.5 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-adfs-dl\adfsmig.dll (88.0 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-bits-client-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-bluetooth-config\bthmigplugin.dll (84.0 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-certificateservices-ca-dl.man (1.8 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-certificateservices-camanagement-dl.man (1.4 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-certificateservices-mscep-dl.man (1.7 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-com-complus-setup-dl\commig.dll (58.0 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-com-dtc-setup-dl\msdtcstp.dll (65.5 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-dfsr-core-dl.man (2.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-dhcpservermigplugin-dl\dhcpsrvmigplugin.dll (132.5 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-directoryservices-adam-dl\adammigrate.dll (125.0 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-dot3svc-dl.man (2.2 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-fax-client-applications-dl.man (3.7 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-fax-client-proenterprise-dl.man (1.8 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-fax-common-dl.man (4.7 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-fax-server-dl.man (1.8 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-fax-service-dl.man (7.5 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-htmlhelp-dl.man (1.7 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iasserver-migplugin\iasmigplugin.dll (615.0 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iasserver-migplugin\iasmigreader.exe (480.0 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-icm-profiles-dl.man (2.2 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-ie-clientnetworkprotocolimplementation\wininetplugin.dll (93.0 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-ie-clientnetworkprotocolimplementation-dl.man (19.5 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-ie-esc-dl.man (1.9 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-ie-feeds-platform-dl.man (2.3 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-ie-internetexplorer-dl.man (12.5 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-asp-deployment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-aspnet-deployment-dl.man (1.5 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-basicauthentication-deployment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-cgi-deployment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-clientcertificatemappingauthentication-deployment-dl.man (1.7 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-corewebengine-deployment-dl.man (1.4 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-customlogging-deployment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-defaultdocument-deployment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-digestauthentication-deployment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-directorybrowsing-deployment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-dl\iismig.dll (325.5 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-ftpserver-deployment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-httpcompressiondynamic-deployment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-httpcompressionstatic-deployment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-httperrors-deployment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-httplogging-deployment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-httpredirect-deployment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-httptracing-deployment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-iiscertificatemappingauthentication-deployment-dl.man (1.7 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-ipsecurity-deployment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-isapiextensions-deployment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-isapifilter-deployment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-legacyscripts-deployment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-legacysnapin-deployment-dl.man (1.5 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-logginglibraries-deployment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-managementconsole-deployment-dl.man (1.5 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-managementscriptingtools-deployment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-managementservice-deployment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-metabase-dl.man (2.7 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-netfxextensibility-deployment-dl.man (1.5 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-odbclogging-deployment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-requestfiltering-deployment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-requestmonitor-deployment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-serversideincludes-deployment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-staticcontent-deployment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-urlauthorization-deployment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-windowsauthentication-deployment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-iis-wmicompatibility-deployment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-international-core-dl\nlscoremig.dll (98.0 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-internet-naming-service-runtime\winsplgn.dll (73.0 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-mail-dl.man (2.0 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-mediaplayer-drm-dl\drmmgrtn.dll (483.5 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-mediaplayer-migration-dl.man (4.3 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-msmq-messagingcoreservice\mqmigplugin.dll (134.5 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-ndis\ndismigplugin.dll (163.0 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-netfx35-dl.man (8.8 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-netfx35cdfcomp-dl.man (1.2 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-netfxcorecomp-dl.man (44.5 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-networkbridge\bridgemigplugin.dll (80.5 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-networkbridge-dl.man (1.8 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-networkloadbalancing-core\nlbmigplugin.dll (162.5 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-offlinefiles-dl\cscmigdl.dll (115.0 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-offlinefiles-dl.man (5.0 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-performancecounterinfrastructure-dl\cntrtextmig.dll (132.0 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-performancecounterinfrastructureconsumer-dl\plamig.dll (103.0 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-rasconnectionmanager\cmmigr.dll (62.5 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-rasserver-migplugin\rasmigplugin.dll (212.0 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-sharedaccess-dl.man (2.0 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-shmig-dl\shmig.dll (101.0 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-smbhashgeneration-dl.man (1.3 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-storagemigration\en-us\stormigplugin.dll.mui (2.0 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-storagemigration\stormigplugin.dll (226.0 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-storagemigration-dl.man (9.3 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-sxs\sxsmigplugin.dll (118.5 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-sxs-dl.man (1.2 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-tapisetup\tapimigplugin.dll (101.5 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-tapisetup-dl.man (2.5 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-terminalservices-clientactivexcore-dl.man (1.3 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-terminalservices-licenseserver\tlsmigplugin.dll (101.0 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-textservicesframework-migration-dl\imjpmig.dll (39.5 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-textservicesframework-migration-dl\imkrmig.dll (46.0 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-textservicesframework-migration-dl\imscmig.dll (36.0 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-textservicesframework-migration-dl\imtcmig.dll (23.5 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-textservicesframework-migration-dl\msctfmig.dll (194.5 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-textservicesframework-migration-dl\tabletextservicemig.dll (40.0 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-unimodem-config\modemmigplugin.dll (151.5 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-wab-dl.man (2.5 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-was-configurationapi-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-was-netfxenvironment-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-was-processmodel-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-wcfcorecomp-dl.man (5.3 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-winsock-core-infrastructure-upgrade\wsupgrade.dll (194.5 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-wlansvc-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft-windows-wmi-core\wmimigrationplugin.dll (435.0 KB)
Extracting: G:\sources\dlmanifests\microsoft.windows.com.base-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\microsoft.windows.com.complus.setup.dl.man (2.3 KB)
Extracting: G:\sources\dlmanifests\microsoft.windows.com.dtc.setup-dl.man (4.0 KB)
Extracting: G:\sources\dlmanifests\microsoftwindowssystemrestore-main-dl.man (1.8 KB)
Extracting: G:\sources\dlmanifests\migrationdisplaygroups-dl.man (8.0 KB)
Extracting: G:\sources\dlmanifests\mpr-dl.man (1.2 KB)
Extracting: G:\sources\dlmanifests\msmq-dcom-dl.man (1.7 KB)
Extracting: G:\sources\dlmanifests\msmq-domain-ic-dl.man (1.5 KB)
Extracting: G:\sources\dlmanifests\msmq-http-dl.man (2.2 KB)
Extracting: G:\sources\dlmanifests\msmq-messagingcoreservice-dl.man (6.6 KB)
Extracting: G:\sources\dlmanifests\msmq-multicast-dl.man (1.5 KB)
Extracting: G:\sources\dlmanifests\msmq-routing-dl.man (1.4 KB)
Extracting: G:\sources\dlmanifests\msmq-triggers-dl.man (1.7 KB)
Extracting: G:\sources\dlmanifests\muisettings-dl.man (1.9 KB)
Extracting: G:\sources\dlmanifests\mup-dl.man (1.5 KB)
Extracting: G:\sources\dlmanifests\ndis-dl.man (2.5 KB)
Extracting: G:\sources\dlmanifests\netfx3-dl.man (1.4 KB)
Extracting: G:\sources\dlmanifests\netlogon-dl.man (2.0 KB)
Extracting: G:\sources\dlmanifests\networkaccessprotection-agent-dl.man (2.2 KB)
Extracting: G:\sources\dlmanifests\networking-mpssvc-svc\icfupgd.dll (106.0 KB)
Extracting: G:\sources\dlmanifests\networking-mpssvc-svc-dl.man (3.8 KB)
Extracting: G:\sources\dlmanifests\networkloadbalancingfullserver-dl.man (2.8 KB)
Extracting: G:\sources\dlmanifests\nfs-admincore-dl.man (2.7 KB)
Extracting: G:\sources\dlmanifests\nfs-clientcore-dl.man (2.7 KB)
Extracting: G:\sources\dlmanifests\nfs-servercore-dl.man (2.7 KB)
Extracting: G:\sources\dlmanifests\ntfs-dl.man (2.6 KB)
Extracting: G:\sources\dlmanifests\ntoskrnl-dl.man (4.0 KB)
Extracting: G:\sources\dlmanifests\odbc32dll-dl.man (2.9 KB)
Extracting: G:\sources\dlmanifests\openportmapper-dl.man (1.8 KB)
Extracting: G:\sources\dlmanifests\openrpc-dl.man (2.0 KB)
Extracting: G:\sources\dlmanifests\partmgr-dl.man (1.0 KB)
Extracting: G:\sources\dlmanifests\peertopeeradmin-dl.man (1.2 KB)
Extracting: G:\sources\dlmanifests\peertopeerbase-dl.man (1.4 KB)
Extracting: G:\sources\dlmanifests\peertopeergraphing-dl.man (1.4 KB)
Extracting: G:\sources\dlmanifests\peertopeergrouping-dl.man (1.5 KB)
Extracting: G:\sources\dlmanifests\peertopeeridmanager-dl.man (1.2 KB)
Extracting: G:\sources\dlmanifests\peertopeerpnrp-dl.man (1.7 KB)
Extracting: G:\sources\dlmanifests\performancecounterinfrastructure-dl.man (1.4 KB)
Extracting: G:\sources\dlmanifests\performancecounterinfrastructureconsumer-dl.man (1.7 KB)
Extracting: G:\sources\dlmanifests\printing-spooler-core-dl.man (2.5 KB)
Extracting: G:\sources\dlmanifests\printing-spooler-networkclient-dl.man (2.2 KB)
Extracting: G:\sources\dlmanifests\propsys-dl.man (1.9 KB)
Extracting: G:\sources\dlmanifests\pstore_data-dl.man (1.5 KB)
Extracting: G:\sources\dlmanifests\psync-dl.man (2.9 KB)
Extracting: G:\sources\dlmanifests\rasapi-dl.man (1.7 KB)
Extracting: G:\sources\dlmanifests\rascmak-dl.man (1.4 KB)
Extracting: G:\sources\dlmanifests\rasconnectionmanager-dl.man (2.3 KB)
Extracting: G:\sources\dlmanifests\rasmanservice-dl.man (0.9 KB)
Extracting: G:\sources\dlmanifests\rasservermigplugin-dl.man (15.0 KB)
Extracting: G:\sources\dlmanifests\rasserveroc-dl.man (1.3 KB)
Extracting: G:\sources\dlmanifests\remoteassistance-dl.man (2.0 KB)
Extracting: G:\sources\dlmanifests\rights-management-client-v1-api-dl.man (3.2 KB)
Extracting: G:\sources\dlmanifests\rights-management-services-server-dl.man (3.2 KB)
Extracting: G:\sources\dlmanifests\rpc-http-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\rpc-http_proxy-dl.man (1.4 KB)
Extracting: G:\sources\dlmanifests\rpc-local-dl.man (1.8 KB)
Extracting: G:\sources\dlmanifests\rpc-remote-dl.man (1.9 KB)
Extracting: G:\sources\dlmanifests\sanmmc-dl.man (1.7 KB)
Extracting: G:\sources\dlmanifests\schannel-dl.man (1.4 KB)
Extracting: G:\sources\dlmanifests\schedsvc-dl.man (1.9 KB)
Extracting: G:\sources\dlmanifests\security-digest-dl.man (0.8 KB)
Extracting: G:\sources\dlmanifests\security-kerberos-dl.man (0.8 KB)
Extracting: G:\sources\dlmanifests\security-ntlm-dl.man (1.4 KB)
Extracting: G:\sources\dlmanifests\security-ntlm-lmc.man (1.1 KB)
Extracting: G:\sources\dlmanifests\shell32-dl.man (6.0 KB)
Extracting: G:\sources\dlmanifests\shmig-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\shutdown-event-tracker-dl.man (1.3 KB)
Extracting: G:\sources\dlmanifests\simpletcp-dl.man (0.9 KB)
Extracting: G:\sources\dlmanifests\smartcardsubsystem-dl.man (3.6 KB)
Extracting: G:\sources\dlmanifests\smbserver-dl.man (13.8 KB)
Extracting: G:\sources\dlmanifests\smss-dl.man (2.0 KB)
Extracting: G:\sources\dlmanifests\smtpsvc-admin-dl.man (1.1 KB)
Extracting: G:\sources\dlmanifests\smtpsvc-service-dl.man (1.2 KB)
Extracting: G:\sources\dlmanifests\snis-dl.man (2.7 KB)
Extracting: G:\sources\dlmanifests\snmp-dl.man (2.4 KB)
Extracting: G:\sources\dlmanifests\speechcommon-dl.man (2.4 KB)
Extracting: G:\sources\dlmanifests\srm-dl.man (4.7 KB)
Extracting: G:\sources\dlmanifests\sua-dl.man (4.9 KB)
Extracting: G:\sources\dlmanifests\tabletpc-tabbtn-dl.man (1.7 KB)
Extracting: G:\sources\dlmanifests\tabletpcinputpanel-dl.man (1.7 KB)
Extracting: G:\sources\dlmanifests\tabletpcjournal-dl.man (8.5 KB)
Extracting: G:\sources\dlmanifests\tabletpcplatforminput-core-dl.man (8.9 KB)
Extracting: G:\sources\dlmanifests\tcpip-dl.man (11.7 KB)
Extracting: G:\sources\dlmanifests\telnet-client-dl.man (2.1 KB)
Extracting: G:\sources\dlmanifests\telnet-server-dl.man (5.1 KB)
Extracting: G:\sources\dlmanifests\terminalservices-appserver-dl.man (1.5 KB)
Extracting: G:\sources\dlmanifests\terminalservices-appserver-licensing-dl.man (1.3 KB)
Extracting: G:\sources\dlmanifests\terminalservices-drivers-dl.man (1.2 KB)
Extracting: G:\sources\dlmanifests\terminalservices-licenseserver-dl.man (2.1 KB)
Extracting: G:\sources\dlmanifests\terminalservices-localsessionmanager-dl.man (1.4 KB)
Extracting: G:\sources\dlmanifests\terminalservices-rdp-winstationextensions-dl.man (20.4 KB)
Extracting: G:\sources\dlmanifests\terminalservices-remoteconnectionmanager-dl.man (1.4 KB)
Extracting: G:\sources\dlmanifests\terminalservices-sessiondirectory-client-dl.man (2.2 KB)
Extracting: G:\sources\dlmanifests\terminalservices-sessiondirectory-server-dl.man (2.4 KB)
Extracting: G:\sources\dlmanifests\terminalservices-terminalservicesclient-dl.man (1.9 KB)
Extracting: G:\sources\dlmanifests\textservicesframework-migration-dl.man (2.2 KB)
Extracting: G:\sources\dlmanifests\themeui-dl.man (1.2 KB)
Extracting: G:\sources\dlmanifests\time-service-dl.man (4.3 KB)
Extracting: G:\sources\dlmanifests\unimodem-config-dl.man (1.4 KB)
Extracting: G:\sources\dlmanifests\upnpcontrolpoint-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\upnpdevicehost-dl.man (2.3 KB)
Extracting: G:\sources\dlmanifests\upnpssdp-dl.man (2.1 KB)
Extracting: G:\sources\dlmanifests\video-tvvideocontrol-dl.man (2.0 KB)
Extracting: G:\sources\dlmanifests\virtualdiskservice-dl.man (1.7 KB)
Extracting: G:\sources\dlmanifests\vss-dl.man (1.5 KB)
Extracting: G:\sources\dlmanifests\vsssystemprovider-dl.man (1.0 KB)
Extracting: G:\sources\dlmanifests\wcf-http-activation-dl.man (2.0 KB)
Extracting: G:\sources\dlmanifests\wcf-http-activation-postapply-dl.man (1.4 KB)
Extracting: G:\sources\dlmanifests\wcf-nonhttp-activation-dl.man (1.4 KB)
Extracting: G:\sources\dlmanifests\wds-dl.man (19.7 KB)
Extracting: G:\sources\dlmanifests\web-services-for-management-core-dl.man (1.9 KB)
Extracting: G:\sources\dlmanifests\webdavredir-dl.man (2.5 KB)
Extracting: G:\sources\dlmanifests\webdavredir-mrxdav-dl.man (3.7 KB)
Extracting: G:\sources\dlmanifests\webenroll-dl.man (1.6 KB)
Extracting: G:\sources\dlmanifests\win32k-settings-dl.man (11.8 KB)
Extracting: G:\sources\dlmanifests\windowssearchengine-dl.man (5.6 KB)
Extracting: G:\sources\dlmanifests\winhttp60-dl.man (2.8 KB)
Extracting: G:\sources\dlmanifests\winlogon-dl.man (2.3 KB)
Extracting: G:\sources\dlmanifests\wirelessnetworking-dl.man (1.3 KB)
Extracting: G:\sources\dlmanifests\wmi-core-dl.man (2.3 KB)
Extracting: G:\sources\dlmanifests\wmi-snmp-provider-dl.man (1.4 KB)
Extracting: G:\sources\dlmanifests\workstationservice-dl.man (1.8 KB)
Extracting: G:\sources\dlmanifests\wsinfra-upgrade-dl.man (1.7 KB)
Extracting: G:\sources\dlmanifests\wsrm-service-dl.man (25.8 KB)
Extracting: G:\sources\dpx.dll (390.5 KB)
Extracting: G:\sources\drupdate.dll (199.0 KB)
Extracting: G:\sources\drvmain.sdb (103.4 KB)
Extracting: G:\sources\drvmgrtn.dll (140.0 KB)
Extracting: G:\sources\drvstore.dll (413.0 KB)
Extracting: G:\sources\du.dll (89.0 KB)
Extracting: G:\sources\embeddedutil.dll (56.5 KB)
Extracting: G:\sources\en-us\actionqueue.dll.mui (3.0 KB)
Extracting: G:\sources\en-us\apds.dll.mui (48.0 KB)
Extracting: G:\sources\en-us\apircl.dll.mui (4.5 KB)
Extracting: G:\sources\en-us\apss.dll.mui (3.0 KB)
Extracting: G:\sources\en-us\arunres.dll.mui (4.0 KB)
Extracting: G:\sources\en-us\cbsmsg.dll.mui (12.0 KB)
Extracting: G:\sources\en-us\cmisetup.dll.mui (4.0 KB)
Extracting: G:\sources\en-us\compatprovider.dll.mui (12.5 KB)
Extracting: G:\sources\en-us\compres.dll.mui (10.0 KB)
Extracting: G:\sources\en-us\dism.exe.mui (28.0 KB)
Extracting: G:\sources\en-us\dismcore.dll.mui (6.0 KB)
Extracting: G:\sources\en-us\dismhost.exe.mui (2.5 KB)
Extracting: G:\sources\en-us\dismprov.dll.mui (2.0 KB)
Extracting: G:\sources\en-us\du_help_what_info_sent_to_ms.rtf (42.7 KB)
Extracting: G:\sources\en-us\du_help_why_get_updates.rtf (45.5 KB)
Extracting: G:\sources\en-us\embeddedutil.dll.mui (2.0 KB)
Extracting: G:\sources\en-us\erofflps.txt (6.9 KB)
Extracting: G:\sources\en-us\folderprovider.dll.mui (2.0 KB)
Extracting: G:\sources\en-us\help_what_is_activation.rtf (41.5 KB)
Extracting: G:\sources\en-us\input.dll.mui (23.5 KB)
Extracting: G:\sources\en-us\logprovider.dll.mui (5.5 KB)
Extracting: G:\sources\en-us\mofd.dll.mui (7.5 KB)
Extracting: G:\sources\en-us\msxml6r.dll.mui (77.5 KB)
Extracting: G:\sources\en-us\nlsbres.dll.mui (67.0 KB)
Extracting: G:\sources\en-us\oobe_help_opt_in_details.rtf (50.5 KB)
Extracting: G:\sources\en-us\pnpibs.dll.mui (4.5 KB)
Extracting: G:\sources\en-us\privacy.rtf (133.2 KB)
Extracting: G:\sources\en-us\readme.rtf (135.5 KB)
Extracting: G:\sources\en-us\rollback.exe.mui (4.0 KB)
Extracting: G:\sources\en-us\setup.exe.mui (11.5 KB)
Extracting: G:\sources\en-us\setup_help_upgrade_or_custom.rtf (46.2 KB)
Extracting: G:\sources\en-us\smiengine.dll.mui (11.5 KB)
Extracting: G:\sources\en-us\sperr32.exe.mui (3.0 KB)
Extracting: G:\sources\en-us\spwizres.dll.mui (7.0 KB)
Extracting: G:\sources\en-us\upgdriver.dll.mui (6.5 KB)
Extracting: G:\sources\en-us\upgloader.dll.mui (22.0 KB)
Extracting: G:\sources\en-us\upgreport.dll.mui (2.5 KB)
Extracting: G:\sources\en-us\upgres.dll.mui (9.0 KB)
Extracting: G:\sources\en-us\uxlibres.dll.mui (2.5 KB)
Extracting: G:\sources\en-us\vofflps.rtf (63.8 KB)
Extracting: G:\sources\en-us\w32uires.dll.mui (254.5 KB)
Extracting: G:\sources\en-us\wbemcore.dll.mui (3.0 KB)
Extracting: G:\sources\en-us\wdsclient.dll.mui (7.0 KB)
Extracting: G:\sources\en-us\wdsimage.dll.mui (5.5 KB)
Extracting: G:\sources\en-us\winsetup.dll.mui (50.5 KB)
Extracting: G:\sources\en-us\wmiutils.dll.mui (17.0 KB)
Extracting: G:\sources\envmig.xml (10.6 KB)
Extracting: G:\sources\esscli.dll (430.0 KB)
Extracting: G:\sources\etwproviders\actionqueueetw.dll (4.0 KB)
Extracting: G:\sources\etwproviders\auditetw.dll (4.0 KB)
Extracting: G:\sources\etwproviders\cmisetupetw.dll (3.5 KB)
Extracting: G:\sources\etwproviders\en-us\actionqueueetw.dll.mui (3.0 KB)
Extracting: G:\sources\etwproviders\en-us\auditetw.dll.mui (3.0 KB)
Extracting: G:\sources\etwproviders\en-us\cmisetupetw.dll.mui (4.0 KB)
Extracting: G:\sources\etwproviders\en-us\oobeldretw.dll.mui (3.0 KB)
Extracting: G:\sources\etwproviders\en-us\setupcletw.dll.mui (4.5 KB)
Extracting: G:\sources\etwproviders\en-us\setupetw.dll.mui (3.5 KB)
Extracting: G:\sources\etwproviders\en-us\setupugcetw.dll.mui (3.0 KB)
Extracting: G:\sources\etwproviders\en-us\sysprepetw.dll.mui (3.0 KB)
Extracting: G:\sources\etwproviders\en-us\windeployetw.dll.mui (3.0 KB)
Extracting: G:\sources\etwproviders\en-us\winsetupetw.dll.mui (50.5 KB)
Extracting: G:\sources\etwproviders\etwproviderinstall.vbs (6.7 KB)
Extracting: G:\sources\etwproviders\oobeldretw.dll (4.0 KB)
Extracting: G:\sources\etwproviders\setupcletw.dll (5.5 KB)
Extracting: G:\sources\etwproviders\setupetw.dll (5.0 KB)
Extracting: G:\sources\etwproviders\setupugcetw.dll (4.0 KB)
Extracting: G:\sources\etwproviders\sysprepetw.dll (4.0 KB)
Extracting: G:\sources\etwproviders\windeployetw.dll (3.5 KB)
Extracting: G:\sources\etwproviders\winsetupetw.dll (6.5 KB)
Extracting: G:\sources\fastprox.dll (888.0 KB)
Extracting: G:\sources\folderprovider.dll (52.5 KB)
Extracting: G:\sources\fveupg.dll (44.0 KB)
Extracting: G:\sources\globalinstallorder.xml (1.9 MB)
Extracting: G:\sources\helpcins.dll (139.0 KB)
Extracting: G:\sources\hwcompat.dll (193.0 KB)
Extracting: G:\sources\hwcompat.txt (513.0 KB)
Extracting: G:\sources\hwexclude.txt (1.7 KB)
Extracting: G:\sources\hypervcomplcheck.dll (34.0 KB)
Extracting: G:\sources\idwbinfo.txt (0.1 KB)
Extracting: G:\sources\iiscomp.dll (18.5 KB)
Extracting: G:\sources\inf\setup.cfg (1.3 KB)
Extracting: G:\sources\input.dll (241.0 KB)
Extracting: G:\sources\install.wim (4.6 GB)
Extracting: G:\sources\lang.ini (0.1 KB)
Extracting: G:\sources\license\_default\_default\enterprise\license.rtf (99.2 KB)
Extracting: G:\sources\license\_default\_default\enterprisee\license.rtf (28.3 KB)
Extracting: G:\sources\license\_default\_default\enterprisen\license.rtf (29.7 KB)
Extracting: G:\sources\license\_default\_default\homebasic\license.rtf (109.5 KB)
Extracting: G:\sources\license\_default\_default\homebasice\license.rtf (28.3 KB)
Extracting: G:\sources\license\_default\_default\homebasicn\license.rtf (28.3 KB)
Extracting: G:\sources\license\_default\_default\homepremium\license.rtf (112.9 KB)
Extracting: G:\sources\license\_default\_default\homepremiume\license.rtf (28.3 KB)
Extracting: G:\sources\license\_default\_default\homepremiumn\license.rtf (105.8 KB)
Extracting: G:\sources\license\_default\_default\lipeula.rtf (7.5 KB)
Extracting: G:\sources\license\_default\_default\lpeula.rtf (0.7 KB)
Extracting: G:\sources\license\_default\_default\professional\license.rtf (119.2 KB)
Extracting: G:\sources\license\_default\_default\professionale\license.rtf (28.3 KB)
Extracting: G:\sources\license\_default\_default\professionaln\license.rtf (107.4 KB)
Extracting: G:\sources\license\_default\_default\starter\license.rtf (99.7 KB)
Extracting: G:\sources\license\_default\_default\startere\license.rtf (33.4 KB)
Extracting: G:\sources\license\_default\_default\startern\license.rtf (95.0 KB)
Extracting: G:\sources\license\_default\_default\ultimate\license.rtf (113.7 KB)
Extracting: G:\sources\license\_default\_default\ultimatee\license.rtf (28.3 KB)
Extracting: G:\sources\license\_default\_default\ultimaten\license.rtf (105.6 KB)
Extracting: G:\sources\license\_default\eval\enterprise\license.rtf (99.2 KB)
Extracting: G:\sources\license\_default\eval\enterprisee\license.rtf (28.3 KB)
Extracting: G:\sources\license\_default\eval\enterprisen\license.rtf (29.7 KB)
Extracting: G:\sources\license\_default\eval\homebasic\license.rtf (28.3 KB)
Extracting: G:\sources\license\_default\eval\homebasice\license.rtf (28.3 KB)
Extracting: G:\sources\license\_default\eval\homebasicn\license.rtf (28.3 KB)
Extracting: G:\sources\license\_default\eval\homepremium\license.rtf (28.3 KB)
Extracting: G:\sources\license\_default\eval\homepremiume\license.rtf (28.3 KB)
Extracting: G:\sources\license\_default\eval\homepremiumn\license.rtf (28.3 KB)
Extracting: G:\sources\license\_default\eval\professional\license.rtf (28.3 KB)
Extracting: G:\sources\license\_default\eval\professionale\license.rtf (28.3 KB)
Extracting: G:\sources\license\_default\eval\professionaln\license.rtf (28.3 KB)
Extracting: G:\sources\license\_default\eval\starter\license.rtf (28.3 KB)
Extracting: G:\sources\license\_default\eval\startere\license.rtf (28.3 KB)
Extracting: G:\sources\license\_default\eval\startern\license.rtf (28.3 KB)
Extracting: G:\sources\license\_default\eval\ultimate\license.rtf (28.3 KB)
Extracting: G:\sources\license\_default\eval\ultimatee\license.rtf (28.3 KB)
Extracting: G:\sources\license\_default\eval\ultimaten\license.rtf (28.3 KB)
Extracting: G:\sources\license\_default\oem\enterprise\license.rtf (0.6 KB)
Extracting: G:\sources\license\_default\oem\enterprisee\license.rtf (28.3 KB)
Extracting: G:\sources\license\_default\oem\enterprisen\license.rtf (0.6 KB)
Extracting: G:\sources\license\_default\oem\homebasic\license.rtf (101.1 KB)
Extracting: G:\sources\license\_default\oem\homebasice\license.rtf (28.3 KB)
Extracting: G:\sources\license\_default\oem\homebasicn\license.rtf (28.3 KB)
Extracting: G:\sources\license\_default\oem\homepremium\license.rtf (105.7 KB)
Extracting: G:\sources\license\_default\oem\homepremiume\license.rtf (36.8 KB)
Extracting: G:\sources\license\_default\oem\homepremiumn\license.rtf (95.5 KB)
Extracting: G:\sources\license\_default\oem\professional\license.rtf (40.5 KB)
Extracting: G:\sources\license\_default\oem\professionale\license.rtf (38.3 KB)
Extracting: G:\sources\license\_default\oem\professionaln\license.rtf (35.0 KB)
Extracting: G:\sources\license\_default\oem\starter\license.rtf (99.7 KB)
Extracting: G:\sources\license\_default\oem\startere\license.rtf (33.4 KB)
Extracting: G:\sources\license\_default\oem\startern\license.rtf (95.0 KB)
Extracting: G:\sources\license\_default\oem\ultimate\license.rtf (39.9 KB)
Extracting: G:\sources\license\_default\oem\ultimatee\license.rtf (37.7 KB)
Extracting: G:\sources\license\_default\oem\ultimaten\license.rtf (34.5 KB)
Extracting: G:\sources\license\en-us\_default\enterprise\license.rtf (99.2 KB)
Extracting: G:\sources\license\en-us\_default\enterprisee\license.rtf (28.3 KB)
Extracting: G:\sources\license\en-us\_default\enterprisen\license.rtf (29.7 KB)
Extracting: G:\sources\license\en-us\_default\homebasic\license.rtf (109.5 KB)
Extracting: G:\sources\license\en-us\_default\homebasice\license.rtf (28.3 KB)
Extracting: G:\sources\license\en-us\_default\homebasicn\license.rtf (28.3 KB)
Extracting: G:\sources\license\en-us\_default\homepremium\license.rtf (112.9 KB)
Extracting: G:\sources\license\en-us\_default\homepremiume\license.rtf (28.3 KB)
Extracting: G:\sources\license\en-us\_default\homepremiumn\license.rtf (105.8 KB)
Extracting: G:\sources\license\en-us\_default\lipeula.rtf (7.5 KB)
Extracting: G:\sources\license\en-us\_default\lpeula.rtf (0.7 KB)
Extracting: G:\sources\license\en-us\_default\professional\license.rtf (119.2 KB)
Extracting: G:\sources\license\en-us\_default\professionale\license.rtf (28.3 KB)
Extracting: G:\sources\license\en-us\_default\professionaln\license.rtf (107.4 KB)
Extracting: G:\sources\license\en-us\_default\starter\license.rtf (99.7 KB)
Extracting: G:\sources\license\en-us\_default\startere\license.rtf (33.4 KB)
Extracting: G:\sources\license\en-us\_default\startern\license.rtf (95.0 KB)
Extracting: G:\sources\license\en-us\_default\ultimate\license.rtf (113.7 KB)
Extracting: G:\sources\license\en-us\_default\ultimatee\license.rtf (28.3 KB)
Extracting: G:\sources\license\en-us\_default\ultimaten\license.rtf (105.6 KB)
Extracting: G:\sources\license\en-us\eval\enterprise\license.rtf (99.2 KB)
Extracting: G:\sources\license\en-us\eval\enterprisee\license.rtf (28.3 KB)
Extracting: G:\sources\license\en-us\eval\enterprisen\license.rtf (29.7 KB)
Extracting: G:\sources\license\en-us\eval\homebasic\license.rtf (28.3 KB)
Extracting: G:\sources\license\en-us\eval\homebasice\license.rtf (28.3 KB)
Extracting: G:\sources\license\en-us\eval\homebasicn\license.rtf (28.3 KB)
Extracting: G:\sources\license\en-us\eval\homepremium\license.rtf (28.3 KB)
Extracting: G:\sources\license\en-us\eval\homepremiume\license.rtf (28.3 KB)
Extracting: G:\sources\license\en-us\eval\homepremiumn\license.rtf (28.3 KB)
Extracting: G:\sources\license\en-us\eval\professional\license.rtf (28.3 KB)
Extracting: G:\sources\license\en-us\eval\professionale\license.rtf (28.3 KB)
Extracting: G:\sources\license\en-us\eval\professionaln\license.rtf (28.3 KB)
Extracting: G:\sources\license\en-us\eval\starter\license.rtf (28.3 KB)
Extracting: G:\sources\license\en-us\eval\startere\license.rtf (28.3 KB)
Extracting: G:\sources\license\en-us\eval\startern\license.rtf (28.3 KB)
Extracting: G:\sources\license\en-us\eval\ultimate\license.rtf (28.3 KB)
Extracting: G:\sources\license\en-us\eval\ultimatee\license.rtf (28.3 KB)
Extracting: G:\sources\license\en-us\eval\ultimaten\license.rtf (28.3 KB)
Extracting: G:\sources\license\en-us\oem\enterprise\license.rtf (0.6 KB)
Extracting: G:\sources\license\en-us\oem\enterprisee\license.rtf (28.3 KB)
Extracting: G:\sources\license\en-us\oem\enterprisen\license.rtf (0.6 KB)
Extracting: G:\sources\license\en-us\oem\homebasic\license.rtf (101.1 KB)
Extracting: G:\sources\license\en-us\oem\homebasice\license.rtf (28.3 KB)
Extracting: G:\sources\license\en-us\oem\homebasicn\license.rtf (28.3 KB)
Extracting: G:\sources\license\en-us\oem\homepremium\license.rtf (105.7 KB)
Extracting: G:\sources\license\en-us\oem\homepremiume\license.rtf (36.8 KB)
Extracting: G:\sources\license\en-us\oem\homepremiumn\license.rtf (95.5 KB)
Extracting: G:\sources\license\en-us\oem\professional\license.rtf (40.5 KB)
Extracting: G:\sources\license\en-us\oem\professionale\license.rtf (38.3 KB)
Extracting: G:\sources\license\en-us\oem\professionaln\license.rtf (35.0 KB)
Extracting: G:\sources\license\en-us\oem\starter\license.rtf (99.7 KB)
Extracting: G:\sources\license\en-us\oem\startere\license.rtf (33.4 KB)
Extracting: G:\sources\license\en-us\oem\startern\license.rtf (95.0 KB)
Extracting: G:\sources\license\en-us\oem\ultimate\license.rtf (39.9 KB)
Extracting: G:\sources\license\en-us\oem\ultimatee\license.rtf (37.7 KB)
Extracting: G:\sources\license\en-us\oem\ultimaten\license.rtf (34.5 KB)
Extracting: G:\sources\locale.nls (410.0 KB)
Extracting: G:\sources\locdrv.dll (361.5 KB)
Extracting: G:\sources\logprovider.dll (104.5 KB)
Extracting: G:\sources\migisol.dll (121.0 KB)
Extracting: G:\sources\migtestplugin.dll (39.5 KB)
Extracting: G:\sources\mofd.dll (272.0 KB)
Extracting: G:\sources\mofinstall.dll (74.5 KB)
Extracting: G:\sources\msdelta.dll (441.0 KB)
Extracting: G:\sources\msftedit.dll (781.0 KB)
Extracting: G:\sources\mspatcha.dll (45.5 KB)
Extracting: G:\sources\msxml6.dll (1.7 MB)
Extracting: G:\sources\msxml6r.dll (2.0 KB)
Extracting: G:\sources\ndiscompl.dll (102.5 KB)
Extracting: G:\sources\nlsbres.dll (67.5 KB)
Extracting: G:\sources\ntdsupg.dll (23.5 KB)
Extracting: G:\sources\ntfrsupg.dll (42.5 KB)
Extracting: G:\sources\oemhelpins.dll (217.0 KB)
Extracting: G:\sources\offline.xml (35.9 KB)
Extracting: G:\sources\oscomps.xml (573.9 KB)
Extracting: G:\sources\osfilter.inf (20.5 KB)
Extracting: G:\sources\pidgenx.dll (1.4 MB)
Extracting: G:\sources\pkeyconfig.xrm-ms (995.0 KB)
Extracting: G:\sources\pnpibs.dll (80.0 KB)
Extracting: G:\sources\product.ini (3.9 KB)
Extracting: G:\sources\readme.rtf (135.5 KB)
Extracting: G:\sources\repdrvfs.dll (441.0 KB)
Extracting: G:\sources\replacementmanifests\activedirectory-webservices-replacement.man (1.7 KB)
Extracting: G:\sources\replacementmanifests\application-experience-program-compatibility-assistant-replacement.man (11.7 KB)
Extracting: G:\sources\replacementmanifests\audiommecore-other-migration-replacement.man (1.1 KB)
Extracting: G:\sources\replacementmanifests\authui-migration-replacement.man (6.2 KB)
Extracting: G:\sources\replacementmanifests\bthmig-replacement.man (0.8 KB)
Extracting: G:\sources\replacementmanifests\capi2_certs-repl.man (10.5 KB)
Extracting: G:\sources\replacementmanifests\dhcpclientdll-repl.man (4.0 KB)
Extracting: G:\sources\replacementmanifests\dhcpservermigplugin-rep.man (12.5 KB)
Extracting: G:\sources\replacementmanifests\ehome-reg-inf_repl.man (3.0 KB)
Extracting: G:\sources\replacementmanifests\eudcedit-replacement.man (2.0 KB)
Extracting: G:\sources\replacementmanifests\extensibleauthenticationprotocolhostservice-rep.man (2.9 KB)
Extracting: G:\sources\replacementmanifests\failovercluster-core-wow64-rm.man (0.9 KB)
Extracting: G:\sources\replacementmanifests\fonts-type1-replacement.man (1.4 KB)
Extracting: G:\sources\replacementmanifests\fundisc-replacement.man (1.4 KB)
Extracting: G:\sources\replacementmanifests\gameuxmig-replacement.man (0.9 KB)
Extracting: G:\sources\replacementmanifests\iis-ftpextensibility-rm.man (1.0 KB)
Extracting: G:\sources\replacementmanifests\iis-ftpsvc-rm.man (1.2 KB)
Extracting: G:\sources\replacementmanifests\iis-powershellprovider-rm.man (1.0 KB)
Extracting: G:\sources\replacementmanifests\iis-sharedlibraries-rm.man (1.5 KB)
Extracting: G:\sources\replacementmanifests\iis-webdav-rm.man (1.0 KB)
Extracting: G:\sources\replacementmanifests\international-core-replacement.man (10.3 KB)
Extracting: G:\sources\replacementmanifests\ipv4ipv6coexistencemigration-replacement.man (3.4 KB)
Extracting: G:\sources\replacementmanifests\microsoft-activedirectory-webservices\adwsmigrate.dll (83.5 KB)
Extracting: G:\sources\replacementmanifests\microsoft-hyper-v\vmswitchmigrationplugin.dll (396.0 KB)
Extracting: G:\sources\replacementmanifests\microsoft-hyper-v-client-migration-replacement.man (1.3 KB)
Extracting: G:\sources\replacementmanifests\microsoft-hyper-v-drivers-migration-replacement.man (1.0 KB)
Extracting: G:\sources\replacementmanifests\microsoft-hyper-v-migration-replacement.man (2.4 KB)
Extracting: G:\sources\replacementmanifests\microsoft-international-core\nlscoremig.dll (98.0 KB)
Extracting: G:\sources\replacementmanifests\microsoft-windows-audio-mmecore-other\audmigplugin.dll (74.5 KB)
Extracting: G:\sources\replacementmanifests\microsoft-windows-bth-user\bthmigplugin.dll (84.0 KB)
Extracting: G:\sources\replacementmanifests\microsoft-windows-fax-service-replacement.man (3.9 KB)
Extracting: G:\sources\replacementmanifests\microsoft-windows-gameuxmig\gameuxmig.dll (23.0 KB)
Extracting: G:\sources\replacementmanifests\microsoft-windows-ie-adminkitbranding-repl.man (6.4 KB)
Extracting: G:\sources\replacementmanifests\microsoft-windows-ie-internetexplorer-repl.man (32.3 KB)
Extracting: G:\sources\replacementmanifests\microsoft-windows-iis-rm\iismig.dll (325.5 KB)
Extracting: G:\sources\replacementmanifests\microsoft-windows-ndis\ndismigplugin.dll (163.0 KB)
Extracting: G:\sources\replacementmanifests\microsoft-windows-netfx35cdfcomp-replacement.man (0.9 KB)
Extracting: G:\sources\replacementmanifests\microsoft-windows-netfxcorecomp-repl.man (44.3 KB)
Extracting: G:\sources\replacementmanifests\microsoft-windows-offlinefiles-core\cscmig.dll (134.0 KB)
Extracting: G:\sources\replacementmanifests\microsoft-windows-offlinefiles-core\en-us\cscmig.dll.mui (2.5 KB)
Extracting: G:\sources\replacementmanifests\microsoft-windows-offlinefiles-replacement.man (2.5 KB)
Extracting: G:\sources\replacementmanifests\microsoft-windows-power-policy\powermigplugin.dll (108.5 KB)
Extracting: G:\sources\replacementmanifests\microsoft-windows-powershell-replacement.man (2.4 KB)
Extracting: G:\sources\replacementmanifests\microsoft-windows-securestartup-filterdriver-replacement.man (2.0 KB)
Extracting: G:\sources\replacementmanifests\microsoft-windows-shmig\shmig.dll (101.0 KB)
Extracting: G:\sources\replacementmanifests\microsoft-windows-terminalservices-appserver-licensing\tsmigplugin.dll (129.0 KB)
Extracting: G:\sources\replacementmanifests\microsoft-windows-terminalservices-licenseserver\tlsrepplugin.dll (101.0 KB)
Extracting: G:\sources\replacementmanifests\microsoft-windows-wcfcorecomp-replacement.man (0.8 KB)
Extracting: G:\sources\replacementmanifests\microsoft.windows.servermanager-non_msil-replacement.man (0.7 KB)
Extracting: G:\sources\replacementmanifests\mmsys-migration-replacement.man (1.3 KB)
Extracting: G:\sources\replacementmanifests\ndis-repl.man (3.0 KB)
Extracting: G:\sources\replacementmanifests\nfs-admincore-repl.man (1.2 KB)
Extracting: G:\sources\replacementmanifests\nfs-clientcore-repl.man (1.2 KB)
Extracting: G:\sources\replacementmanifests\nfs-servercore-repl.man (1.2 KB)
Extracting: G:\sources\replacementmanifests\powermanagement-powerpolicy-definitions-replacement.man (1.4 KB)
Extracting: G:\sources\replacementmanifests\powermanagement-powerpolicy-migration-replacement.man (0.6 KB)
Extracting: G:\sources\replacementmanifests\printing-localprinting-replacement.man (1.2 KB)
Extracting: G:\sources\replacementmanifests\printing-servercore-wow64-rm.man (0.9 KB)
Extracting: G:\sources\replacementmanifests\propsys-replacement.man (2.0 KB)
Extracting: G:\sources\replacementmanifests\provsvc-replacement.man (1.4 KB)
Extracting: G:\sources\replacementmanifests\rasapi-repl.man (5.5 KB)
Extracting: G:\sources\replacementmanifests\rasmanservice-repl.man (1.7 KB)
Extracting: G:\sources\replacementmanifests\rasppp-repl.man (2.7 KB)
Extracting: G:\sources\replacementmanifests\rights-management-client-v1-api-replacement.man (4.4 KB)
Extracting: G:\sources\replacementmanifests\servercore-ea-ime-wow64-rm.man (0.8 KB)
Extracting: G:\sources\replacementmanifests\servercore-wow64-rm.man (0.7 KB)
Extracting: G:\sources\replacementmanifests\shmig-replacement.man (1.1 KB)
Extracting: G:\sources\replacementmanifests\sounds-migration-replacement.man (2.3 KB)
Extracting: G:\sources\replacementmanifests\srm-datascrndriver-repl.man (2.6 KB)
Extracting: G:\sources\replacementmanifests\srm-quotadriver-repl.man (2.5 KB)
Extracting: G:\sources\replacementmanifests\srm-service-repl.man (4.0 KB)
Extracting: G:\sources\replacementmanifests\srm-service-reports-repl.man (2.8 KB)
Extracting: G:\sources\replacementmanifests\srm-ui-repl.man (2.4 KB)
Extracting: G:\sources\replacementmanifests\stickynotes-replacement.man (1.4 KB)
Extracting: G:\sources\replacementmanifests\suacore-wow64-rm.man (0.9 KB)
Extracting: G:\sources\replacementmanifests\sysdm-replacement.man (1.4 KB)
Extracting: G:\sources\replacementmanifests\sysmain-replacement.man (1.7 KB)
Extracting: G:\sources\replacementmanifests\tabletpc-uihub-replacement.man (10.9 KB)
Extracting: G:\sources\replacementmanifests\tabletpcplatforminput-core-replacement.man (15.3 KB)
Extracting: G:\sources\replacementmanifests\tabletpcstickynotes-replacement.man (1.9 KB)
Extracting: G:\sources\replacementmanifests\tcpip-replacement.man (15.9 KB)
Extracting: G:\sources\replacementmanifests\terminalservices-appserver-licensing-replacement.man (1.1 KB)
Extracting: G:\sources\replacementmanifests\terminalservices-licenseserver-replacement.man (1.5 KB)
Extracting: G:\sources\replacementmanifests\terminalservices-manager-snapin-replacement.man (1.1 KB)
Extracting: G:\sources\replacementmanifests\terminalservices-rapwebpart-replacement.man (1.1 KB)
Extracting: G:\sources\replacementmanifests\terminalservices-sbmgr-snapin-non_msil-replacement.man (0.8 KB)
Extracting: G:\sources\replacementmanifests\usb\usbmigplugin.dll (78.0 KB)
Extracting: G:\sources\replacementmanifests\usbmigplugin-replacement.man (0.6 KB)
Extracting: G:\sources\replacementmanifests\virtualdiskservice-repl.man (1.7 KB)
Extracting: G:\sources\replacementmanifests\vssservice-repl.man (4.0 KB)
Extracting: G:\sources\replacementmanifests\vsssystemprovider-replacement.man (2.9 KB)
Extracting: G:\sources\replacementmanifests\wcf-http-activation-replacement.man (0.8 KB)
Extracting: G:\sources\replacementmanifests\wcf-nonhttp-activation-replacement.man (0.8 KB)
Extracting: G:\sources\replacementmanifests\windows-markettheme-mctadmin-component-replacement.man (1.0 KB)
Extracting: G:\sources\replacementmanifests\windowssearchengine\wsearchmigplugin.dll (76.5 KB)
Extracting: G:\sources\replacementmanifests\windowssearchengine-replacement.man (5.8 KB)
Extracting: G:\sources\replacementmanifests\wmdmigration-replacement.man (4.0 KB)
Extracting: G:\sources\replacementmanifests\wmi-core-replacement.man (1.8 KB)
Extracting: G:\sources\replacementmanifests\wsrm-service-replacement.man (2.1 KB)
Extracting: G:\sources\rmsupg.dll (57.0 KB)
Extracting: G:\sources\rollback.exe (110.5 KB)
Extracting: G:\sources\schema.dat (88.0 KB)
Extracting: G:\sources\sdbapiu.dll (115.5 KB)
Extracting: G:\sources\segoeui.ttf (505.3 KB)
Extracting: G:\sources\servicing\0.0.0.1\xmllite.dll (195.0 KB)
Extracting: G:\sources\servicingstackmisc\apds.dll (2.1 MB)
Extracting: G:\sources\servicingstackmisc\apircl.dll (270.0 KB)
Extracting: G:\sources\servicingstackmisc\apss.dll (229.5 KB)
Extracting: G:\sources\setup.exe (260.0 KB)
Extracting: G:\sources\sfcn.dat (1.8 KB)
Extracting: G:\sources\sflcid.dat (1.6 KB)
Extracting: G:\sources\sflistlh.dat (3.1 MB)
Extracting: G:\sources\sflistw7.dat (2.0 MB)
Extracting: G:\sources\sflistxp.dat (1.4 MB)
Extracting: G:\sources\sfpat.inf (10.2 KB)
Extracting: G:\sources\sfpatlh.inf (9.4 KB)
Extracting: G:\sources\sfpatpg.inf (0.5 KB)
Extracting: G:\sources\sfpatw7.inf (3.3 KB)
Extracting: G:\sources\sfpatxp.inf (4.3 KB)
Extracting: G:\sources\smiengine.dll (911.5 KB)
Extracting: G:\sources\smipi.dll (102.0 KB)
Extracting: G:\sources\sperr32.exe (120.6 KB)
Extracting: G:\sources\spflvrnt.dll (24.5 KB)
Extracting: G:\sources\spprgrss.dll (56.5 KB)
Extracting: G:\sources\spwizeng.dll (435.5 KB)
Extracting: G:\sources\spwizimg.dll (8.0 MB)
Extracting: G:\sources\spwizres.dll (7.5 KB)
Extracting: G:\sources\sqmapi.dll (239.0 KB)
Extracting: G:\sources\ssshim.dll (119.0 KB)
Extracting: G:\sources\sysmain.sdb (121.8 KB)
Extracting: G:\sources\sysmain32.sdb (3.7 MB)
Extracting: G:\sources\uddicomp.dll (40.0 KB)
Extracting: G:\sources\unattend.dll (243.0 KB)
Extracting: G:\sources\unbcl.dll (979.0 KB)
Extracting: G:\sources\upgcmi2migxml.dll (232.0 KB)
Extracting: G:\sources\upgcompat.inf (18.6 KB)
Extracting: G:\sources\upgcore.dll (7.8 MB)
Extracting: G:\sources\upgcsiagent.dll (446.5 KB)
Extracting: G:\sources\upgdriver.dll (885.5 KB)
Extracting: G:\sources\upghost.exe (259.5 KB)
Extracting: G:\sources\upgloader.dll (257.5 KB)
Extracting: G:\sources\upgmxeagent.dll (145.0 KB)
Extracting: G:\sources\upgrade_bulk.xml (163.8 KB)
Extracting: G:\sources\upgradeagent.dll (3.6 MB)
Extracting: G:\sources\upgradeagent.xml (58.3 KB)
Extracting: G:\sources\upgreport.dll (549.0 KB)
Extracting: G:\sources\upgres.dll (36.0 KB)
Extracting: G:\sources\upgwow_bulk.xml (91.9 KB)
Extracting: G:\sources\uxlib.dll (151.0 KB)
Extracting: G:\sources\uxlibres.dll (2.5 KB)
Extracting: G:\sources\vofflps.rtf (63.8 KB)
Extracting: G:\sources\w32uiimg.dll (2.9 MB)
Extracting: G:\sources\w32uires.dll (254.5 KB)
Extracting: G:\sources\warning.gif (0.6 KB)
Extracting: G:\sources\wbemcomn.dll (517.0 KB)
Extracting: G:\sources\wbemcore.dll (1.2 MB)
Extracting: G:\sources\wbemprox.dll (42.5 KB)
Extracting: G:\sources\wcmtypes.xsd (1.0 KB)
Extracting: G:\sources\wcp.dll (2.6 MB)
Extracting: G:\sources\wdsclient.dll (609.5 KB)
Extracting: G:\sources\wdsclientapi.dll (143.5 KB)
Extracting: G:\sources\wdscore.dll (265.0 KB)
Extracting: G:\sources\wdscsl.dll (67.5 KB)
Extracting: G:\sources\wdsimage.dll (688.5 KB)
Extracting: G:\sources\wdstptc.dll (144.5 KB)
Extracting: G:\sources\wdsupgcompl.dll (10.5 KB)
Extracting: G:\sources\wdsutil.dll (57.0 KB)
Extracting: G:\sources\win32ui.dll (564.0 KB)
Extracting: G:\sources\winsetup.dll (2.1 MB)
Extracting: G:\sources\wmi_tracing.mof (1.6 KB)
Extracting: G:\sources\wmicmiplugin.dll (512.0 KB)
Extracting: G:\sources\wmiutils.dll (134.0 KB)
Extracting: G:\sources\xmllite.dll (195.0 KB)
Extracting: G:\support\logging\actionqueueetw.dll (4.0 KB)
Extracting: G:\support\logging\auditetw.dll (4.0 KB)
Extracting: G:\support\logging\cmisetupetw.dll (3.5 KB)
Extracting: G:\support\logging\en-us\actionqueueetw.dll.mui (3.0 KB)
Extracting: G:\support\logging\en-us\auditetw.dll.mui (3.0 KB)
Extracting: G:\support\logging\en-us\cmisetupetw.dll.mui (4.0 KB)
Extracting: G:\support\logging\en-us\oobeldretw.dll.mui (3.0 KB)
Extracting: G:\support\logging\en-us\setupcletw.dll.mui (4.5 KB)
Extracting: G:\support\logging\en-us\setupetw.dll.mui (3.5 KB)
Extracting: G:\support\logging\en-us\setupugcetw.dll.mui (3.0 KB)
Extracting: G:\support\logging\en-us\sysprepetw.dll.mui (3.0 KB)
Extracting: G:\support\logging\en-us\windeployetw.dll.mui (3.0 KB)
Extracting: G:\support\logging\en-us\winsetupetw.dll.mui (50.5 KB)
Extracting: G:\support\logging\etwproviderinstall.vbs (6.7 KB)
Extracting: G:\support\logging\microsoft-windows-actionqueue-instrumentation.man (5.7 KB)
Extracting: G:\support\logging\microsoft-windows-audit-instrumentation.man (6.6 KB)
Extracting: G:\support\logging\microsoft-windows-cmisetup-instrumentation.man (6.2 KB)
Extracting: G:\support\logging\microsoft-windows-oobeldr-instrumentation.man (7.6 KB)
Extracting: G:\support\logging\microsoft-windows-setup-events.man (10.2 KB)
Extracting: G:\support\logging\microsoft-windows-setup-instrumentation.man (8.1 KB)
Extracting: G:\support\logging\microsoft-windows-setupcl-instrumentation.man (10.6 KB)
Extracting: G:\support\logging\microsoft-windows-setupugc-instrumentation.man (6.6 KB)
Extracting: G:\support\logging\microsoft-windows-sysprep-instrumentation.man (6.0 KB)
Extracting: G:\support\logging\microsoft-windows-windeploy-instrumentation.man (6.6 KB)
Extracting: G:\support\logging\oobeldretw.dll (4.0 KB)
Extracting: G:\support\logging\setupcletw.dll (5.5 KB)
Extracting: G:\support\logging\setupetw.dll (5.0 KB)
Extracting: G:\support\logging\setupugcetw.dll (4.0 KB)
Extracting: G:\support\logging\sysprepetw.dll (4.0 KB)
Extracting: G:\support\logging\windeployetw.dll (3.5 KB)
Extracting: G:\support\logging\winsetupetw.dll (6.5 KB)
Extracting: G:\support\migwiz\cable\cableinst.exe (10.5 KB)
Extracting: G:\support\migwiz\cmi2migxml.dll (233.0 KB)
Extracting: G:\support\migwiz\csiagent.dll (629.0 KB)
Extracting: G:\support\migwiz\en-us\input.dll.mui (23.5 KB)
Extracting: G:\support\migwiz\en-us\migautoplay.exe.mui (2.0 KB)
Extracting: G:\support\migwiz\en-us\migres.dll.mui (7.0 KB)
Extracting: G:\support\migwiz\en-us\migsetup.exe.mui (3.5 KB)
Extracting: G:\support\migwiz\en-us\migwiz.exe.mui (2.0 KB)
Extracting: G:\support\migwiz\en-us\postmig.exe.mui (21.0 KB)
Extracting: G:\support\migwiz\en-us\svrmig.dll.mui (2.5 KB)
Extracting: G:\support\migwiz\en-us\wet.dll.mui (89.0 KB)
Extracting: G:\support\migwiz\imjpmig.dll (39.5 KB)
Extracting: G:\support\migwiz\imkrmig.dll (46.0 KB)
Extracting: G:\support\migwiz\imscmig.dll (36.0 KB)
Extracting: G:\support\migwiz\imtcmig.dll (23.5 KB)
Extracting: G:\support\migwiz\input.dll (240.5 KB)
Extracting: G:\support\migwiz\installsvrmig.cmd (1.5 KB)
Extracting: G:\support\migwiz\migapp.xml (543.0 KB)
Extracting: G:\support\migwiz\migautoplay.exe (89.4 KB)
Extracting: G:\support\migwiz\migcore.dll (7.7 MB)
Extracting: G:\support\migwiz\migfiles.dat (0.3 KB)
Extracting: G:\support\migwiz\mighost.exe (259.5 KB)
Extracting: G:\support\migwiz\migisol.dll (121.0 KB)
Extracting: G:\support\migwiz\migres.dll (7.0 KB)
Extracting: G:\support\migwiz\migsetup.exe (159.8 KB)
Extracting: G:\support\migwiz\migstore.dll (1.1 MB)
Extracting: G:\support\migwiz\migsys.dll (377.0 KB)
Extracting: G:\support\migwiz\migwiz.exe (532.0 KB)
Extracting: G:\support\migwiz\msctfmig.dll (194.5 KB)
Extracting: G:\support\migwiz\mxeagent.dll (300.0 KB)
Extracting: G:\support\migwiz\postmig.exe (768.0 KB)
Extracting: G:\support\migwiz\postmigres\data\hardwarevendors.xml (1.0 KB)
Extracting: G:\support\migwiz\postmigres\web\base_images\appinstalled.gif (1.0 KB)
Extracting: G:\support\migwiz\postmigres\web\base_images\clickdownexpanded.gif (1.1 KB)
Extracting: G:\support\migwiz\postmigres\web\base_images\clickdownnormal.gif (1.1 KB)
Extracting: G:\support\migwiz\postmigres\web\base_images\column.bmp (18.2 KB)
Extracting: G:\support\migwiz\postmigres\web\base_images\documents.gif (1.1 KB)
Extracting: G:\support\migwiz\postmigres\web\base_images\failure.gif (1.9 KB)
Extracting: G:\support\migwiz\postmigres\web\base_images\programs.gif (2.3 KB)
Extracting: G:\support\migwiz\postmigres\web\base_images\system.gif (1.9 KB)
Extracting: G:\support\migwiz\postmigres\web\base_images\users.gif (2.1 KB)
Extracting: G:\support\migwiz\postmigres\web\base_images\windowsmail.bmp (4.1 KB)
Extracting: G:\support\migwiz\postmigres\web\base_images\windowsmoviemaker.bmp (4.1 KB)
Extracting: G:\support\migwiz\postmigres\web\base_images\windowsoutlookexpress.bmp (4.1 KB)
Extracting: G:\support\migwiz\postmigres\web\base_images\windowsphotogallery.bmp (4.1 KB)
Extracting: G:\support\migwiz\postmigres\web\reportapi.js (18.9 KB)
Extracting: G:\support\migwiz\segoeui.ttf (402.9 KB)
Extracting: G:\support\migwiz\sfcn.dat (1.8 KB)
Extracting: G:\support\migwiz\sflcid.dat (1.6 KB)
Extracting: G:\support\migwiz\sflistlh.dat (3.1 MB)
Extracting: G:\support\migwiz\sflistw7.dat (2.0 MB)
Extracting: G:\support\migwiz\sflistxp.dat (1.4 MB)
Extracting: G:\support\migwiz\sfpat.inf (10.2 KB)
Extracting: G:\support\migwiz\sfpatlh.inf (9.4 KB)
Extracting: G:\support\migwiz\sfpatpg.inf (0.5 KB)
Extracting: G:\support\migwiz\sfpatw7.inf (3.3 KB)
Extracting: G:\support\migwiz\sfpatxp.inf (4.3 KB)
Extracting: G:\support\migwiz\svrmig.dll (667.5 KB)
Extracting: G:\support\migwiz\svrmigtest.dll (74.0 KB)
Extracting: G:\support\migwiz\tabletextservicemig.dll (40.0 KB)
Extracting: G:\support\migwiz\unbcl.dll (979.0 KB)
Extracting: G:\support\migwiz\wdscore.dll (265.0 KB)
Extracting: G:\support\migwiz\wet.dll (9.6 MB)
Extracting: G:\support\tools\gbunicnv.exe (37.0 KB)
Extracting: G:\upgrade\netfx\netfx.msi (5.6 MB)
Extracting: G:\upgrade\netfx\netfx.msp (18.3 MB)
Extracting: G:\upgrade\netfx\netfx1.cab (16.1 MB)
Extracting: G:\upgrade\netfx\netfxupdate.exe (72.0 KB)
Finalizing, please wait...
G:autorun.inf already exists - keeping it
NTFS Fixup (Checkdisk)...
Volume label is Win7AIO-SP1-x64-Mar2014.

Stage 1: Examining basic file system structure ...
  1280 file records processed.
File verification completed.
  0 large file records processed.
  0 bad file records processed.

Stage 2: Examining file name linkage ...
  1706 index entries processed.
Index verification completed.

Stage 3: Examining security descriptors ...
Security descriptor verification completed.
  213 data files processed.

Windows has scanned the file system and found no problems.
No further action is required.

  15637591 KB total disk space.
   5404200 KB in 897 files.
       252 KB in 215 indexes.
     25311 KB in use by the system.
     23136 KB occupied by the log file.
  10207828 KB available on disk.
      4096 bytes in each allocation unit.
   3909397 total allocation units on disk.
   2551957 allocation units available on disk.
NTFS Fixup completed.

Found USB device 'SanDisk Extreme USB Device' (0781:5580)
1 device found
Sector Size: 512 bytes
Cylinders: 1946, TracksPerCylinder: 255, SectorsPerTrack: 63
Partition type: MBR, NB Partitions: 1
Disk ID: 0x00D14AFA
Drive has a Rufus Master Boot Record
Partition 1:
  Type: NTFS (0x07)
  Size: 14.9 GB (16012894208 bytes)
  Start Sector: 2048, Boot: Yes, Recognized: Yes
pbatard picture pbatard on 16 Apr 2014

i made VHD but no additional drive is added to my computer! what is the issue?
my flash drive is usb2 and i have attached it directly to MoBo's usb port without any cable.
no other PC but i have tested on other usb ports and they are still read-only.

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?

ghost picture ghost on 16 Apr 2014

i made VHD but no additional drive is added to my computer! what is the issue?

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.

which seteting did you used for making bootable usb with my iso?

Default, which is what you indicated you used.

pbatard picture pbatard on 16 Apr 2014

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)

Rufus version: 1.4.7.453
Syslinux versions: 4.07, 5.10
Windows version: Windows 7 SP1 64-bit
Locale ID: 0x0409
Found VHD device 'Msft Virtual Disk SCSI Disk Device'
Found USB device 'Multiple Card  Reader USB Device' (058F:6366)
Device eliminated because it appears to contain no media
1 device found
No volume information for disk 0x85
Disk type: Fixed, Sector Size: 512 bytes
Cylinders: 1305, TracksPerCylinder: 255, SectorsPerTrack: 63
Partition type: MBR, NB Partitions: 0
Disk ID: 0x07A7E4C4
Drive has a Windows 7 Master Boot Record
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 \\.\PHYSICALDRIVE5 for write access
No drive letter was assigned...
Will use 'N:' as volume mountpoint
No logical drive found (unpartitioned?)
Drive does not appear to be partitioned
Analyzing existing boot records...
Drive has a Windows 7 Master Boot Record
Deleting partitions...
Clearing MBR/PBR/GPT structures...
Erasing 128 sectors
Partitioning (MBR)...
Waiting for logical drive to reappear...
Formatting (NTFS)...
Using cluster size: 4096 bytes
Quick format was selected
Closed Windows format prompt
Creating file system: Task 1/12 completed
Creating file system: Task 2/12 completed
Creating file system: Task 3/12 completed
Creating file system: Task 4/12 completed
Creating file system: Task 5/12 completed
Creating file system: Task 6/12 completed
Creating file system: Task 7/12 completed
Creating file system: Task 8/12 completed
Creating file system: Task 9/12 completed
Creating file system: Task 10/12 completed
Creating file system: Task 11/12 completed
Creating file system: Task 12/12 completed
Format completed.
Writing master boot record...
Drive has a Zeroed Master Boot Record
Set bootable USB partition as 0x80
Using Rufus MBR
Found volume GUID \\?\Volume{076c2007-c3e4-11e3-920b-50e5493378f4}\
\\?\Volume{076c2007-c3e4-11e3-920b-50e5493378f4}\ was already mounted as N:\
Caution: Opened drive \\?\Volume{076c2007-c3e4-11e3-920b-50e5493378f4} for write access
Writing partition boot record...
Using Standard NTFS partition boot record
Confirmed new volume has an NTFS boot sector
Successfully remounted Volume{076c2007-c3e4-11e3-920b-50e5493378f4}\ on N:\
Copying ISO files...
Extracting files...
Disc image is an UDF image
Extracting: N:\Info\MDL Forums.url (149 bytes)
Extracting: N:\Info\creator.txt (190 bytes)
Extracting: N:\Info\murphy78 - TPB.url (194 bytes)
Extracting: N:\Net451\Automated-Install-Script.cmd (1.3 KB)
Extracting: N:\Net451\NDP45-KB2898869-x64.exe (26 MB)
Extracting: N:\Net451\NDP45-KB2901126-x64.exe (8.2 MB)
Extracting: N:\Net451\NDP451-KB2858728-x86-x64-AllOS-ENU.exe (66.8 MB)
Extracting: N:\Scripts\MicrosoftUpdate-OptIn.vbs (254 bytes)
Extracting: N:\autorun.inf (122 bytes)
Extracting: N:\boot\bcd (256 KB)
Extracting: N:\boot\boot.sdi (3 MB)
Extracting: N:\boot\bootfix.bin (1 KB)
Extracting: N:\boot\bootsect.exe (110 KB)
Extracting: N:\boot\en-us\bootsect.exe.mui (15.5 KB)
Extracting: N:\boot\etfsboot.com (4 KB)
Extracting: N:\boot\fonts\chs_boot.ttf (3.5 MB)
Extracting: N:\boot\fonts\cht_boot.ttf (3.7 MB)
Extracting: N:\boot\fonts\jpn_boot.ttf (1.9 MB)
Extracting: N:\boot\fonts\kor_boot.ttf (2.3 MB)
Extracting: N:\boot\fonts\wgl4_boot.ttf (46.3 KB)
Extracting: N:\boot\memtest.efi (596.9 KB)
Extracting: N:\boot\memtest.exe (474.4 KB)
Extracting: N:\bootmgr (374.8 KB)
Extracting: N:\bootmgr.efi (653.9 KB)
Extracting: N:\efi\boot\bcd (256 KB)
Extracting: N:\efi\boot\bootx64.efi (656.9 KB)
Extracting: N:\efi\boot\cdboot.efi (430.5 KB)
Extracting: N:\efi\boot\cdboot_noprompt.efi (430.5 KB)
Extracting: N:\efi\boot\efisys.bin (1.4 MB)
Extracting: N:\efi\boot\efisys_noprompt.bin (1.4 MB)
Extracting: N:\efi\boot\fonts\chs_boot.ttf (3.5 MB)
Extracting: N:\efi\boot\fonts\cht_boot.ttf (3.7 MB)
Extracting: N:\efi\boot\fonts\jpn_boot.ttf (1.9 MB)
Extracting: N:\efi\boot\fonts\kor_boot.ttf (2.3 MB)
Extracting: N:\efi\boot\fonts\wgl4_boot.ttf (46.3 KB)
Extracting: N:\efi\microsoft\boot\bcd (256 KB)
Extracting: N:\efi\microsoft\boot\cdboot.efi (430.5 KB)
Extracting: N:\efi\microsoft\boot\cdboot_noprompt.efi (430.5 KB)
Extracting: N:\efi\microsoft\boot\efisys.bin (1.4 MB)
Extracting: N:\efi\microsoft\boot\efisys_noprompt.bin (1.4 MB)
Extracting: N:\efi\microsoft\boot\fonts\chs_boot.ttf (3.5 MB)
Extracting: N:\efi\microsoft\boot\fonts\cht_boot.ttf (3.7 MB)
Extracting: N:\efi\microsoft\boot\fonts\jpn_boot.ttf (1.9 MB)
Extracting: N:\efi\microsoft\boot\fonts\kor_boot.ttf (2.3 MB)
Extracting: N:\efi\microsoft\boot\fonts\wgl4_boot.ttf (46.3 KB)
Extracting: N:\setup.exe (104.3 KB)
Extracting: N:\sources\EI.CFG (14 bytes)
Extracting: N:\sources\actionqueue.dll (208.5 KB)
Extracting: N:\sources\admtv3check.dll (63.5 KB)
Extracting: N:\sources\alert.gif (1 KB)
Extracting: N:\sources\apds.dll (2 MB)
Extracting: N:\sources\apircl.dll (267.5 KB)
Extracting: N:\sources\appcompat.xsl (11.4 KB)
Extracting: N:\sources\appcompat_bidi.xsl (12.2 KB)
Extracting: N:\sources\appcompat_detailed.xsl (13.4 KB)
Extracting: N:\sources\appcompat_detailed_bidi.xsl (13.4 KB)
Extracting: N:\sources\appcompat_detailed_bidi_txt.xsl (13.1 KB)
Extracting: N:\sources\appcompat_detailed_txt.xsl (13 KB)
Extracting: N:\sources\apss.dll (237.5 KB)
Extracting: N:\sources\arunimg.dll (959 KB)
Extracting: N:\sources\arunres.dll (4 KB)
Extracting: N:\sources\autorun.dll (152 KB)
Extracting: N:\sources\background_cli.bmp (2.3 MB)
Extracting: N:\sources\boot.wim (211.5 MB)
Extracting: N:\sources\cbscore.dll (953.5 KB)
Extracting: N:\sources\cbsmsg.dll (28 KB)
Extracting: N:\sources\cdplib.mof (1.9 KB)
Extracting: N:\sources\cdplibuninstall.mof (571 bytes)
Extracting: N:\sources\cmiadapter.dll (123 KB)
Extracting: N:\sources\cmisetup.dll (326.5 KB)
Extracting: N:\sources\cmitrust.dll (466.5 KB)
Extracting: N:\sources\cmiv2.dll (3.6 MB)
Extracting: N:\sources\cntrtextinstaller.dll (166.5 KB)
Extracting: N:\sources\compatprovider.dll (179 KB)
Extracting: N:\sources\compliance.ini (476 bytes)
Extracting: N:\sources\compres.dll (10 KB)
Extracting: N:\sources\cryptosetup.dll (19 KB)
Extracting: N:\sources\cversion.ini (49 bytes)
Extracting: N:\sources\diager.dll (38 KB)
Extracting: N:\sources\diagnostic.dll (155 KB)
Extracting: N:\sources\dism.exe (268.5 KB)
Extracting: N:\sources\dismcore.dll (283 KB)
Extracting: N:\sources\dismcoreps.dll (109 KB)
Extracting: N:\sources\dismhost.exe (94.5 KB)
Extracting: N:\sources\dismprov.dll (182 KB)
Extracting: N:\sources\dlmanifests\accessibilitycpl-dl.man (4.3 KB)
Extracting: N:\sources\dlmanifests\activedirectory-webservices-dl.man (667 bytes)
Extracting: N:\sources\dlmanifests\activedirectory-wmireplicationprovider-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\adfs-federationservice-dl.man (2.3 KB)
Extracting: N:\sources\dlmanifests\adfs-federationserviceproxy-dl.man (2.3 KB)
Extracting: N:\sources\dlmanifests\adfs-webagentclaims-dl.man (2.0 KB)
Extracting: N:\sources\dlmanifests\adfs-webagenttoken-dl.man (2.3 KB)
Extracting: N:\sources\dlmanifests\adminui-dl.man (2.6 KB)
Extracting: N:\sources\dlmanifests\adsi-ldap-extensions-dl.man (3.6 KB)
Extracting: N:\sources\dlmanifests\adsi-ldap-provider-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\adsi-router-dl.man (1.9 KB)
Extracting: N:\sources\dlmanifests\adsi-winnt-provider-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\application_experience-infrastructure-dl.man (2.2 KB)
Extracting: N:\sources\dlmanifests\authui-dl.man (2.1 KB)
Extracting: N:\sources\dlmanifests\bitsextensions-server\bitsmig.dll (78.5 KB)
Extracting: N:\sources\dlmanifests\bitsextensions-server-console-dl.man (2.3 KB)
Extracting: N:\sources\dlmanifests\bitsextensions-server-dl.man (2.2 KB)
Extracting: N:\sources\dlmanifests\bluetooth-config-dl.man (1.4 KB)
Extracting: N:\sources\dlmanifests\browserservice-dl.man (3.1 KB)
Extracting: N:\sources\dlmanifests\capi2_certs-dl.man (3.4 KB)
Extracting: N:\sources\dlmanifests\commandprompt-dl.man (2.8 KB)
Extracting: N:\sources\dlmanifests\coreos-dl.man (2 KB)
Extracting: N:\sources\dlmanifests\credential-manager-dl.man (2.2 KB)
Extracting: N:\sources\dlmanifests\crypto_keys-dl.man (2.9 KB)
Extracting: N:\sources\dlmanifests\cryptoconfig-dl.man (1.4 KB)
Extracting: N:\sources\dlmanifests\dfsclient-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\dfsmgmt-dl.man (2 KB)
Extracting: N:\sources\dlmanifests\dfsn-serverservice-dl.man (4.2 KB)
Extracting: N:\sources\dlmanifests\dhcpclient-dl.man (1.5 KB)
Extracting: N:\sources\dlmanifests\dhcpservermigplugin-dl.man (4.1 KB)
Extracting: N:\sources\dlmanifests\directoryservices-adam-dl.man (2.5 KB)
Extracting: N:\sources\dlmanifests\directoryservices-domain-dl.man (2.3 KB)
Extracting: N:\sources\dlmanifests\directoryservices-ism-smtp-dl.man (2.2 KB)
Extracting: N:\sources\dlmanifests\dns-client-dl.man (3.7 KB)
Extracting: N:\sources\dlmanifests\dns-server-service-dl.man (2.3 KB)
Extracting: N:\sources\dlmanifests\dpapi_keys-dl.man (4.4 KB)
Extracting: N:\sources\dlmanifests\drm-dl.man (1.7 KB)
Extracting: N:\sources\dlmanifests\errorreportingcore-dl.man (1.9 KB)
Extracting: N:\sources\dlmanifests\errorreportingfaults-dl.man (1.1 KB)
Extracting: N:\sources\dlmanifests\etw-core-dl.man (1.3 KB)
Extracting: N:\sources\dlmanifests\eudcedit-dl.man (1.5 KB)
Extracting: N:\sources\dlmanifests\eventcollector-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\eventlog-dl.man (1.7 KB)
Extracting: N:\sources\dlmanifests\evntagnt-dl.man (1.9 KB)
Extracting: N:\sources\dlmanifests\explorer-dl.man (2.5 KB)
Extracting: N:\sources\dlmanifests\extensibleauthenticationprotocolhostservice-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\feclient-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\fonts-type1-dl.man (788 bytes)
Extracting: N:\sources\dlmanifests\frs-core-dl.man (4.3 KB)
Extracting: N:\sources\dlmanifests\gpbase-dl.man (7.0 KB)
Extracting: N:\sources\dlmanifests\gpmc-dl.man (1.4 KB)
Extracting: N:\sources\dlmanifests\gpmgmt-dl.man (1.5 KB)
Extracting: N:\sources\dlmanifests\grouppolicy-admin-gpedit-dl.man (1.4 KB)
Extracting: N:\sources\dlmanifests\grouppolicy-admin-gpedit-snapin-dl.man (1.4 KB)
Extracting: N:\sources\dlmanifests\grouppolicy-cse-softwareinstallation-dl.man (1.9 KB)
Extracting: N:\sources\dlmanifests\grouppolicy-serveradmintools-gpmc-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\http-dl.man (1.2 KB)
Extracting: N:\sources\dlmanifests\iasmigplugin-dl.man (4 KB)
Extracting: N:\sources\dlmanifests\ieframe-dl.man (1.1 KB)
Extracting: N:\sources\dlmanifests\ime-simplified-chinese-migration-dl.man (1.4 KB)
Extracting: N:\sources\dlmanifests\ime-traditional-chinese-migration-dl.man (1.5 KB)
Extracting: N:\sources\dlmanifests\international-core-dl.man (3.4 KB)
Extracting: N:\sources\dlmanifests\international-timezones-dl.man (17.7 KB)
Extracting: N:\sources\dlmanifests\internet-naming-service-runtime-dl.man (5.4 KB)
Extracting: N:\sources\dlmanifests\ipsec-svc-dl.man (2.3 KB)
Extracting: N:\sources\dlmanifests\isns_service-dl.man (1.7 KB)
Extracting: N:\sources\dlmanifests\kerberos-key-distribution-center-dl.man (2 KB)
Extracting: N:\sources\dlmanifests\ldap-client-dl.man (1.4 KB)
Extracting: N:\sources\dlmanifests\mediaserver-aspadmin-migration-dl.man (1 KB)
Extracting: N:\sources\dlmanifests\mediaserver-migration-dl.man (2.4 KB)
Extracting: N:\sources\dlmanifests\mediaserver-multicast-migration-dl.man (1015 bytes)
Extracting: N:\sources\dlmanifests\microsoft-activedirectory-webservices-dl\adwsmigrate.dll (83.5 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-adfs-dl\adfsmig.dll (88 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-bits-client-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-bluetooth-config\bthmigplugin.dll (84 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-certificateservices-ca-dl.man (1.8 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-certificateservices-camanagement-dl.man (1.4 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-certificateservices-mscep-dl.man (1.7 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-com-complus-setup-dl\commig.dll (58 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-com-dtc-setup-dl\msdtcstp.dll (65.5 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-dfsr-core-dl.man (2.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-dhcpservermigplugin-dl\dhcpsrvmigplugin.dll (132.5 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-directoryservices-adam-dl\adammigrate.dll (125 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-dot3svc-dl.man (2.2 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-fax-client-applications-dl.man (3.7 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-fax-client-proenterprise-dl.man (1.8 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-fax-common-dl.man (4.7 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-fax-server-dl.man (1.8 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-fax-service-dl.man (7.5 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-htmlhelp-dl.man (1.7 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iasserver-migplugin\iasmigplugin.dll (615 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iasserver-migplugin\iasmigreader.exe (480 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-icm-profiles-dl.man (2.2 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-ie-clientnetworkprotocolimplementation\wininetplugin.dll (93 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-ie-clientnetworkprotocolimplementation-dl.man (19.5 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-ie-esc-dl.man (1.9 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-ie-feeds-platform-dl.man (2.3 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-ie-internetexplorer-dl.man (12.5 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-asp-deployment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-aspnet-deployment-dl.man (1.5 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-basicauthentication-deployment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-cgi-deployment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-clientcertificatemappingauthentication-deployment-dl.man (1.7 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-corewebengine-deployment-dl.man (1.4 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-customlogging-deployment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-defaultdocument-deployment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-digestauthentication-deployment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-directorybrowsing-deployment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-dl\iismig.dll (325.5 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-ftpserver-deployment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-httpcompressiondynamic-deployment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-httpcompressionstatic-deployment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-httperrors-deployment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-httplogging-deployment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-httpredirect-deployment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-httptracing-deployment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-iiscertificatemappingauthentication-deployment-dl.man (1.7 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-ipsecurity-deployment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-isapiextensions-deployment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-isapifilter-deployment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-legacyscripts-deployment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-legacysnapin-deployment-dl.man (1.5 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-logginglibraries-deployment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-managementconsole-deployment-dl.man (1.5 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-managementscriptingtools-deployment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-managementservice-deployment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-metabase-dl.man (2.7 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-netfxextensibility-deployment-dl.man (1.5 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-odbclogging-deployment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-requestfiltering-deployment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-requestmonitor-deployment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-serversideincludes-deployment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-staticcontent-deployment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-urlauthorization-deployment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-windowsauthentication-deployment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-iis-wmicompatibility-deployment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-international-core-dl\nlscoremig.dll (98 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-internet-naming-service-runtime\winsplgn.dll (73 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-mail-dl.man (2.0 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-mediaplayer-drm-dl\drmmgrtn.dll (483.5 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-mediaplayer-migration-dl.man (4.3 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-msmq-messagingcoreservice\mqmigplugin.dll (134.5 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-ndis\ndismigplugin.dll (163 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-netfx35-dl.man (8.8 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-netfx35cdfcomp-dl.man (1.2 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-netfxcorecomp-dl.man (44.5 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-networkbridge\bridgemigplugin.dll (80.5 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-networkbridge-dl.man (1.8 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-networkloadbalancing-core\nlbmigplugin.dll (162.5 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-offlinefiles-dl\cscmigdl.dll (115 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-offlinefiles-dl.man (5.0 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-performancecounterinfrastructure-dl\cntrtextmig.dll (132 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-performancecounterinfrastructureconsumer-dl\plamig.dll (103 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-rasconnectionmanager\cmmigr.dll (62.5 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-rasserver-migplugin\rasmigplugin.dll (212 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-sharedaccess-dl.man (2.0 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-shmig-dl\shmig.dll (101 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-smbhashgeneration-dl.man (1.3 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-storagemigration\en-us\stormigplugin.dll.mui (2 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-storagemigration\stormigplugin.dll (226 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-storagemigration-dl.man (9.3 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-sxs\sxsmigplugin.dll (118.5 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-sxs-dl.man (1.2 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-tapisetup\tapimigplugin.dll (101.5 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-tapisetup-dl.man (2.5 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-terminalservices-clientactivexcore-dl.man (1.3 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-terminalservices-licenseserver\tlsmigplugin.dll (101 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-textservicesframework-migration-dl\imjpmig.dll (39.5 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-textservicesframework-migration-dl\imkrmig.dll (46 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-textservicesframework-migration-dl\imscmig.dll (36 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-textservicesframework-migration-dl\imtcmig.dll (23.5 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-textservicesframework-migration-dl\msctfmig.dll (194.5 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-textservicesframework-migration-dl\tabletextservicemig.dll (40 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-unimodem-config\modemmigplugin.dll (151.5 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-wab-dl.man (2.5 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-was-configurationapi-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-was-netfxenvironment-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-was-processmodel-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-wcfcorecomp-dl.man (5.3 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-winsock-core-infrastructure-upgrade\wsupgrade.dll (194.5 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-wlansvc-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft-windows-wmi-core\wmimigrationplugin.dll (435 KB)
Extracting: N:\sources\dlmanifests\microsoft.windows.com.base-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\microsoft.windows.com.complus.setup.dl.man (2.3 KB)
Extracting: N:\sources\dlmanifests\microsoft.windows.com.dtc.setup-dl.man (4 KB)
Extracting: N:\sources\dlmanifests\microsoftwindowssystemrestore-main-dl.man (1.8 KB)
Extracting: N:\sources\dlmanifests\migrationdisplaygroups-dl.man (8 KB)
Extracting: N:\sources\dlmanifests\mpr-dl.man (1.2 KB)
Extracting: N:\sources\dlmanifests\msmq-dcom-dl.man (1.7 KB)
Extracting: N:\sources\dlmanifests\msmq-domain-ic-dl.man (1.5 KB)
Extracting: N:\sources\dlmanifests\msmq-http-dl.man (2.2 KB)
Extracting: N:\sources\dlmanifests\msmq-messagingcoreservice-dl.man (6.6 KB)
Extracting: N:\sources\dlmanifests\msmq-multicast-dl.man (1.5 KB)
Extracting: N:\sources\dlmanifests\msmq-routing-dl.man (1.4 KB)
Extracting: N:\sources\dlmanifests\msmq-triggers-dl.man (1.7 KB)
Extracting: N:\sources\dlmanifests\muisettings-dl.man (1.9 KB)
Extracting: N:\sources\dlmanifests\mup-dl.man (1.5 KB)
Extracting: N:\sources\dlmanifests\ndis-dl.man (2.5 KB)
Extracting: N:\sources\dlmanifests\netfx3-dl.man (1.4 KB)
Extracting: N:\sources\dlmanifests\netlogon-dl.man (2 KB)
Extracting: N:\sources\dlmanifests\networkaccessprotection-agent-dl.man (2.2 KB)
Extracting: N:\sources\dlmanifests\networking-mpssvc-svc\icfupgd.dll (106 KB)
Extracting: N:\sources\dlmanifests\networking-mpssvc-svc-dl.man (3.8 KB)
Extracting: N:\sources\dlmanifests\networkloadbalancingfullserver-dl.man (2.8 KB)
Extracting: N:\sources\dlmanifests\nfs-admincore-dl.man (2.7 KB)
Extracting: N:\sources\dlmanifests\nfs-clientcore-dl.man (2.7 KB)
Extracting: N:\sources\dlmanifests\nfs-servercore-dl.man (2.7 KB)
Extracting: N:\sources\dlmanifests\ntfs-dl.man (2.6 KB)
Extracting: N:\sources\dlmanifests\ntoskrnl-dl.man (4.0 KB)
Extracting: N:\sources\dlmanifests\odbc32dll-dl.man (2.9 KB)
Extracting: N:\sources\dlmanifests\openportmapper-dl.man (1.8 KB)
Extracting: N:\sources\dlmanifests\openrpc-dl.man (2.0 KB)
Extracting: N:\sources\dlmanifests\partmgr-dl.man (1 KB)
Extracting: N:\sources\dlmanifests\peertopeeradmin-dl.man (1.2 KB)
Extracting: N:\sources\dlmanifests\peertopeerbase-dl.man (1.4 KB)
Extracting: N:\sources\dlmanifests\peertopeergraphing-dl.man (1.4 KB)
Extracting: N:\sources\dlmanifests\peertopeergrouping-dl.man (1.5 KB)
Extracting: N:\sources\dlmanifests\peertopeeridmanager-dl.man (1.2 KB)
Extracting: N:\sources\dlmanifests\peertopeerpnrp-dl.man (1.7 KB)
Extracting: N:\sources\dlmanifests\performancecounterinfrastructure-dl.man (1.4 KB)
Extracting: N:\sources\dlmanifests\performancecounterinfrastructureconsumer-dl.man (1.7 KB)
Extracting: N:\sources\dlmanifests\printing-spooler-core-dl.man (2.5 KB)
Extracting: N:\sources\dlmanifests\printing-spooler-networkclient-dl.man (2.2 KB)
Extracting: N:\sources\dlmanifests\propsys-dl.man (1.9 KB)
Extracting: N:\sources\dlmanifests\pstore_data-dl.man (1.5 KB)
Extracting: N:\sources\dlmanifests\psync-dl.man (2.9 KB)
Extracting: N:\sources\dlmanifests\rasapi-dl.man (1.7 KB)
Extracting: N:\sources\dlmanifests\rascmak-dl.man (1.4 KB)
Extracting: N:\sources\dlmanifests\rasconnectionmanager-dl.man (2.3 KB)
Extracting: N:\sources\dlmanifests\rasmanservice-dl.man (938 bytes)
Extracting: N:\sources\dlmanifests\rasservermigplugin-dl.man (15 KB)
Extracting: N:\sources\dlmanifests\rasserveroc-dl.man (1.3 KB)
Extracting: N:\sources\dlmanifests\remoteassistance-dl.man (2.0 KB)
Extracting: N:\sources\dlmanifests\rights-management-client-v1-api-dl.man (3.2 KB)
Extracting: N:\sources\dlmanifests\rights-management-services-server-dl.man (3.2 KB)
Extracting: N:\sources\dlmanifests\rpc-http-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\rpc-http_proxy-dl.man (1.4 KB)
Extracting: N:\sources\dlmanifests\rpc-local-dl.man (1.8 KB)
Extracting: N:\sources\dlmanifests\rpc-remote-dl.man (1.9 KB)
Extracting: N:\sources\dlmanifests\sanmmc-dl.man (1.7 KB)
Extracting: N:\sources\dlmanifests\schannel-dl.man (1.4 KB)
Extracting: N:\sources\dlmanifests\schedsvc-dl.man (1.9 KB)
Extracting: N:\sources\dlmanifests\security-digest-dl.man (803 bytes)
Extracting: N:\sources\dlmanifests\security-kerberos-dl.man (803 bytes)
Extracting: N:\sources\dlmanifests\security-ntlm-dl.man (1.4 KB)
Extracting: N:\sources\dlmanifests\security-ntlm-lmc.man (1.1 KB)
Extracting: N:\sources\dlmanifests\shell32-dl.man (6.0 KB)
Extracting: N:\sources\dlmanifests\shmig-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\shutdown-event-tracker-dl.man (1.3 KB)
Extracting: N:\sources\dlmanifests\simpletcp-dl.man (965 bytes)
Extracting: N:\sources\dlmanifests\smartcardsubsystem-dl.man (3.6 KB)
Extracting: N:\sources\dlmanifests\smbserver-dl.man (13.8 KB)
Extracting: N:\sources\dlmanifests\smss-dl.man (2 KB)
Extracting: N:\sources\dlmanifests\smtpsvc-admin-dl.man (1.1 KB)
Extracting: N:\sources\dlmanifests\smtpsvc-service-dl.man (1.2 KB)
Extracting: N:\sources\dlmanifests\snis-dl.man (2.7 KB)
Extracting: N:\sources\dlmanifests\snmp-dl.man (2.4 KB)
Extracting: N:\sources\dlmanifests\speechcommon-dl.man (2.4 KB)
Extracting: N:\sources\dlmanifests\srm-dl.man (4.7 KB)
Extracting: N:\sources\dlmanifests\sua-dl.man (4.9 KB)
Extracting: N:\sources\dlmanifests\tabletpc-tabbtn-dl.man (1.7 KB)
Extracting: N:\sources\dlmanifests\tabletpcinputpanel-dl.man (1.7 KB)
Extracting: N:\sources\dlmanifests\tabletpcjournal-dl.man (8.5 KB)
Extracting: N:\sources\dlmanifests\tabletpcplatforminput-core-dl.man (8.9 KB)
Extracting: N:\sources\dlmanifests\tcpip-dl.man (11.7 KB)
Extracting: N:\sources\dlmanifests\telnet-client-dl.man (2.1 KB)
Extracting: N:\sources\dlmanifests\telnet-server-dl.man (5.1 KB)
Extracting: N:\sources\dlmanifests\terminalservices-appserver-dl.man (1.5 KB)
Extracting: N:\sources\dlmanifests\terminalservices-appserver-licensing-dl.man (1.3 KB)
Extracting: N:\sources\dlmanifests\terminalservices-drivers-dl.man (1.2 KB)
Extracting: N:\sources\dlmanifests\terminalservices-licenseserver-dl.man (2.1 KB)
Extracting: N:\sources\dlmanifests\terminalservices-localsessionmanager-dl.man (1.4 KB)
Extracting: N:\sources\dlmanifests\terminalservices-rdp-winstationextensions-dl.man (20.4 KB)
Extracting: N:\sources\dlmanifests\terminalservices-remoteconnectionmanager-dl.man (1.4 KB)
Extracting: N:\sources\dlmanifests\terminalservices-sessiondirectory-client-dl.man (2.2 KB)
Extracting: N:\sources\dlmanifests\terminalservices-sessiondirectory-server-dl.man (2.4 KB)
Extracting: N:\sources\dlmanifests\terminalservices-terminalservicesclient-dl.man (1.9 KB)
Extracting: N:\sources\dlmanifests\textservicesframework-migration-dl.man (2.2 KB)
Extracting: N:\sources\dlmanifests\themeui-dl.man (1.2 KB)
Extracting: N:\sources\dlmanifests\time-service-dl.man (4.3 KB)
Extracting: N:\sources\dlmanifests\unimodem-config-dl.man (1.4 KB)
Extracting: N:\sources\dlmanifests\upnpcontrolpoint-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\upnpdevicehost-dl.man (2.3 KB)
Extracting: N:\sources\dlmanifests\upnpssdp-dl.man (2.1 KB)
Extracting: N:\sources\dlmanifests\video-tvvideocontrol-dl.man (2.0 KB)
Extracting: N:\sources\dlmanifests\virtualdiskservice-dl.man (1.7 KB)
Extracting: N:\sources\dlmanifests\vss-dl.man (1.5 KB)
Extracting: N:\sources\dlmanifests\vsssystemprovider-dl.man (1 KB)
Extracting: N:\sources\dlmanifests\wcf-http-activation-dl.man (2.0 KB)
Extracting: N:\sources\dlmanifests\wcf-http-activation-postapply-dl.man (1.4 KB)
Extracting: N:\sources\dlmanifests\wcf-nonhttp-activation-dl.man (1.4 KB)
Extracting: N:\sources\dlmanifests\wds-dl.man (19.7 KB)
Extracting: N:\sources\dlmanifests\web-services-for-management-core-dl.man (1.9 KB)
Extracting: N:\sources\dlmanifests\webdavredir-dl.man (2.5 KB)
Extracting: N:\sources\dlmanifests\webdavredir-mrxdav-dl.man (3.7 KB)
Extracting: N:\sources\dlmanifests\webenroll-dl.man (1.6 KB)
Extracting: N:\sources\dlmanifests\win32k-settings-dl.man (11.8 KB)
Extracting: N:\sources\dlmanifests\windowssearchengine-dl.man (5.6 KB)
Extracting: N:\sources\dlmanifests\winhttp60-dl.man (2.8 KB)
Extracting: N:\sources\dlmanifests\winlogon-dl.man (2.3 KB)
Extracting: N:\sources\dlmanifests\wirelessnetworking-dl.man (1.3 KB)
Extracting: N:\sources\dlmanifests\wmi-core-dl.man (2.3 KB)
Extracting: N:\sources\dlmanifests\wmi-snmp-provider-dl.man (1.4 KB)
Extracting: N:\sources\dlmanifests\workstationservice-dl.man (1.8 KB)
Extracting: N:\sources\dlmanifests\wsinfra-upgrade-dl.man (1.7 KB)
Extracting: N:\sources\dlmanifests\wsrm-service-dl.man (25.8 KB)
Extracting: N:\sources\dpx.dll (390.5 KB)
Extracting: N:\sources\drupdate.dll (199 KB)
Extracting: N:\sources\drvmain.sdb (103.4 KB)
Extracting: N:\sources\drvmgrtn.dll (140 KB)
Extracting: N:\sources\drvstore.dll (413 KB)
Extracting: N:\sources\du.dll (89 KB)
Extracting: N:\sources\embeddedutil.dll (56.5 KB)
Extracting: N:\sources\en-us\actionqueue.dll.mui (3 KB)
Extracting: N:\sources\en-us\apds.dll.mui (48 KB)
Extracting: N:\sources\en-us\apircl.dll.mui (4.5 KB)
Extracting: N:\sources\en-us\apss.dll.mui (3 KB)
Extracting: N:\sources\en-us\arunres.dll.mui (4 KB)
Extracting: N:\sources\en-us\cbsmsg.dll.mui (12 KB)
Extracting: N:\sources\en-us\cmisetup.dll.mui (4 KB)
Extracting: N:\sources\en-us\compatprovider.dll.mui (12.5 KB)
Extracting: N:\sources\en-us\compres.dll.mui (10 KB)
Extracting: N:\sources\en-us\dism.exe.mui (28 KB)
Extracting: N:\sources\en-us\dismcore.dll.mui (6 KB)
Extracting: N:\sources\en-us\dismhost.exe.mui (2.5 KB)
Extracting: N:\sources\en-us\dismprov.dll.mui (2 KB)
Extracting: N:\sources\en-us\du_help_what_info_sent_to_ms.rtf (42.7 KB)
Extracting: N:\sources\en-us\du_help_why_get_updates.rtf (45.5 KB)
Extracting: N:\sources\en-us\embeddedutil.dll.mui (2 KB)
Extracting: N:\sources\en-us\erofflps.txt (6.9 KB)
Extracting: N:\sources\en-us\folderprovider.dll.mui (2 KB)
Extracting: N:\sources\en-us\help_what_is_activation.rtf (41.5 KB)
Extracting: N:\sources\en-us\input.dll.mui (23.5 KB)
Extracting: N:\sources\en-us\logprovider.dll.mui (5.5 KB)
Extracting: N:\sources\en-us\mofd.dll.mui (7.5 KB)
Extracting: N:\sources\en-us\msxml6r.dll.mui (77.5 KB)
Extracting: N:\sources\en-us\nlsbres.dll.mui (67 KB)
Extracting: N:\sources\en-us\oobe_help_opt_in_details.rtf (50.5 KB)
Extracting: N:\sources\en-us\pnpibs.dll.mui (4.5 KB)
Extracting: N:\sources\en-us\privacy.rtf (133.2 KB)
Extracting: N:\sources\en-us\readme.rtf (135.5 KB)
Extracting: N:\sources\en-us\rollback.exe.mui (4 KB)
Extracting: N:\sources\en-us\setup.exe.mui (11.5 KB)
Extracting: N:\sources\en-us\setup_help_upgrade_or_custom.rtf (46.2 KB)
Extracting: N:\sources\en-us\smiengine.dll.mui (11.5 KB)
Extracting: N:\sources\en-us\sperr32.exe.mui (3 KB)
Extracting: N:\sources\en-us\spwizres.dll.mui (7 KB)
Extracting: N:\sources\en-us\upgdriver.dll.mui (6.5 KB)
Extracting: N:\sources\en-us\upgloader.dll.mui (22 KB)
Extracting: N:\sources\en-us\upgreport.dll.mui (2.5 KB)
Extracting: N:\sources\en-us\upgres.dll.mui (9 KB)
Extracting: N:\sources\en-us\uxlibres.dll.mui (2.5 KB)
Extracting: N:\sources\en-us\vofflps.rtf (63.8 KB)
Extracting: N:\sources\en-us\w32uires.dll.mui (254.5 KB)
Extracting: N:\sources\en-us\wbemcore.dll.mui (3 KB)
Extracting: N:\sources\en-us\wdsclient.dll.mui (7 KB)
Extracting: N:\sources\en-us\wdsimage.dll.mui (5.5 KB)
Extracting: N:\sources\en-us\winsetup.dll.mui (50.5 KB)
Extracting: N:\sources\en-us\wmiutils.dll.mui (17 KB)
Extracting: N:\sources\envmig.xml (10.6 KB)
Extracting: N:\sources\esscli.dll (430 KB)
Extracting: N:\sources\etwproviders\actionqueueetw.dll (4 KB)
Extracting: N:\sources\etwproviders\auditetw.dll (4 KB)
Extracting: N:\sources\etwproviders\cmisetupetw.dll (3.5 KB)
Extracting: N:\sources\etwproviders\en-us\actionqueueetw.dll.mui (3 KB)
Extracting: N:\sources\etwproviders\en-us\auditetw.dll.mui (3 KB)
Extracting: N:\sources\etwproviders\en-us\cmisetupetw.dll.mui (4 KB)
Extracting: N:\sources\etwproviders\en-us\oobeldretw.dll.mui (3 KB)
Extracting: N:\sources\etwproviders\en-us\setupcletw.dll.mui (4.5 KB)
Extracting: N:\sources\etwproviders\en-us\setupetw.dll.mui (3.5 KB)
Extracting: N:\sources\etwproviders\en-us\setupugcetw.dll.mui (3 KB)
Extracting: N:\sources\etwproviders\en-us\sysprepetw.dll.mui (3 KB)
Extracting: N:\sources\etwproviders\en-us\windeployetw.dll.mui (3 KB)
Extracting: N:\sources\etwproviders\en-us\winsetupetw.dll.mui (50.5 KB)
Extracting: N:\sources\etwproviders\etwproviderinstall.vbs (6.7 KB)
Extracting: N:\sources\etwproviders\oobeldretw.dll (4 KB)
Extracting: N:\sources\etwproviders\setupcletw.dll (5.5 KB)
Extracting: N:\sources\etwproviders\setupetw.dll (5 KB)
Extracting: N:\sources\etwproviders\setupugcetw.dll (4 KB)
Extracting: N:\sources\etwproviders\sysprepetw.dll (4 KB)
Extracting: N:\sources\etwproviders\windeployetw.dll (3.5 KB)
Extracting: N:\sources\etwproviders\winsetupetw.dll (6.5 KB)
Extracting: N:\sources\fastprox.dll (888 KB)
Extracting: N:\sources\folderprovider.dll (52.5 KB)
Extracting: N:\sources\fveupg.dll (44 KB)
Extracting: N:\sources\globalinstallorder.xml (1.9 MB)
Extracting: N:\sources\helpcins.dll (139 KB)
Extracting: N:\sources\hwcompat.dll (193 KB)
Extracting: N:\sources\hwcompat.txt (513 KB)
Extracting: N:\sources\hwexclude.txt (1.7 KB)
Extracting: N:\sources\hypervcomplcheck.dll (34 KB)
Extracting: N:\sources\idwbinfo.txt (123 bytes)
Extracting: N:\sources\iiscomp.dll (18.5 KB)
Extracting: N:\sources\inf\setup.cfg (1.3 KB)
Extracting: N:\sources\input.dll (241 KB)
Extracting: N:\sources\install.wim (4.6 GB)
Extracting: N:\sources\lang.ini (78 bytes)
Extracting: N:\sources\license\_default\_default\enterprise\license.rtf (99.2 KB)
Extracting: N:\sources\license\_default\_default\enterprisee\license.rtf (28.3 KB)
Extracting: N:\sources\license\_default\_default\enterprisen\license.rtf (29.7 KB)
Extracting: N:\sources\license\_default\_default\homebasic\license.rtf (109.5 KB)
Extracting: N:\sources\license\_default\_default\homebasice\license.rtf (28.3 KB)
Extracting: N:\sources\license\_default\_default\homebasicn\license.rtf (28.3 KB)
Extracting: N:\sources\license\_default\_default\homepremium\license.rtf (112.9 KB)
Extracting: N:\sources\license\_default\_default\homepremiume\license.rtf (28.3 KB)
Extracting: N:\sources\license\_default\_default\homepremiumn\license.rtf (105.8 KB)
Extracting: N:\sources\license\_default\_default\lipeula.rtf (7.5 KB)
Extracting: N:\sources\license\_default\_default\lpeula.rtf (733 bytes)
Extracting: N:\sources\license\_default\_default\professional\license.rtf (119.2 KB)
Extracting: N:\sources\license\_default\_default\professionale\license.rtf (28.3 KB)
Extracting: N:\sources\license\_default\_default\professionaln\license.rtf (107.4 KB)
Extracting: N:\sources\license\_default\_default\starter\license.rtf (99.7 KB)
Extracting: N:\sources\license\_default\_default\startere\license.rtf (33.4 KB)
Extracting: N:\sources\license\_default\_default\startern\license.rtf (95 KB)
Extracting: N:\sources\license\_default\_default\ultimate\license.rtf (113.7 KB)
Extracting: N:\sources\license\_default\_default\ultimatee\license.rtf (28.3 KB)
Extracting: N:\sources\license\_default\_default\ultimaten\license.rtf (105.6 KB)
Extracting: N:\sources\license\_default\eval\enterprise\license.rtf (99.2 KB)
Extracting: N:\sources\license\_default\eval\enterprisee\license.rtf (28.3 KB)
Extracting: N:\sources\license\_default\eval\enterprisen\license.rtf (29.7 KB)
Extracting: N:\sources\license\_default\eval\homebasic\license.rtf (28.3 KB)
Extracting: N:\sources\license\_default\eval\homebasice\license.rtf (28.3 KB)
Extracting: N:\sources\license\_default\eval\homebasicn\license.rtf (28.3 KB)
Extracting: N:\sources\license\_default\eval\homepremium\license.rtf (28.3 KB)
Extracting: N:\sources\license\_default\eval\homepremiume\license.rtf (28.3 KB)
Extracting: N:\sources\license\_default\eval\homepremiumn\license.rtf (28.3 KB)
Extracting: N:\sources\license\_default\eval\professional\license.rtf (28.3 KB)
Extracting: N:\sources\license\_default\eval\professionale\license.rtf (28.3 KB)
Extracting: N:\sources\license\_default\eval\professionaln\license.rtf (28.3 KB)
Extracting: N:\sources\license\_default\eval\starter\license.rtf (28.3 KB)
Extracting: N:\sources\license\_default\eval\startere\license.rtf (28.3 KB)
Extracting: N:\sources\license\_default\eval\startern\license.rtf (28.3 KB)
Extracting: N:\sources\license\_default\eval\ultimate\license.rtf (28.3 KB)
Extracting: N:\sources\license\_default\eval\ultimatee\license.rtf (28.3 KB)
Extracting: N:\sources\license\_default\eval\ultimaten\license.rtf (28.3 KB)
Extracting: N:\sources\license\_default\oem\enterprise\license.rtf (637 bytes)
Extracting: N:\sources\license\_default\oem\enterprisee\license.rtf (28.3 KB)
Extracting: N:\sources\license\_default\oem\enterprisen\license.rtf (640 bytes)
Extracting: N:\sources\license\_default\oem\homebasic\license.rtf (101.1 KB)
Extracting: N:\sources\license\_default\oem\homebasice\license.rtf (28.3 KB)
Extracting: N:\sources\license\_default\oem\homebasicn\license.rtf (28.3 KB)
Extracting: N:\sources\license\_default\oem\homepremium\license.rtf (105.7 KB)
Extracting: N:\sources\license\_default\oem\homepremiume\license.rtf (36.8 KB)
Extracting: N:\sources\license\_default\oem\homepremiumn\license.rtf (95.5 KB)
Extracting: N:\sources\license\_default\oem\professional\license.rtf (40.5 KB)
Extracting: N:\sources\license\_default\oem\professionale\license.rtf (38.3 KB)
Extracting: N:\sources\license\_default\oem\professionaln\license.rtf (35 KB)
Extracting: N:\sources\license\_default\oem\starter\license.rtf (99.7 KB)
Extracting: N:\sources\license\_default\oem\startere\license.rtf (33.4 KB)
Extracting: N:\sources\license\_default\oem\startern\license.rtf (95 KB)
Extracting: N:\sources\license\_default\oem\ultimate\license.rtf (39.9 KB)
Extracting: N:\sources\license\_default\oem\ultimatee\license.rtf (37.7 KB)
Extracting: N:\sources\license\_default\oem\ultimaten\license.rtf (34.5 KB)
Extracting: N:\sources\license\en-us\_default\enterprise\license.rtf (99.2 KB)
Extracting: N:\sources\license\en-us\_default\enterprisee\license.rtf (28.3 KB)
Extracting: N:\sources\license\en-us\_default\enterprisen\license.rtf (29.7 KB)
Extracting: N:\sources\license\en-us\_default\homebasic\license.rtf (109.5 KB)
Extracting: N:\sources\license\en-us\_default\homebasice\license.rtf (28.3 KB)
Extracting: N:\sources\license\en-us\_default\homebasicn\license.rtf (28.3 KB)
Extracting: N:\sources\license\en-us\_default\homepremium\license.rtf (112.9 KB)
Extracting: N:\sources\license\en-us\_default\homepremiume\license.rtf (28.3 KB)
Extracting: N:\sources\license\en-us\_default\homepremiumn\license.rtf (105.8 KB)
Extracting: N:\sources\license\en-us\_default\lipeula.rtf (7.5 KB)
Extracting: N:\sources\license\en-us\_default\lpeula.rtf (733 bytes)
Extracting: N:\sources\license\en-us\_default\professional\license.rtf (119.2 KB)
Extracting: N:\sources\license\en-us\_default\professionale\license.rtf (28.3 KB)
Extracting: N:\sources\license\en-us\_default\professionaln\license.rtf (107.4 KB)
Extracting: N:\sources\license\en-us\_default\starter\license.rtf (99.7 KB)
Extracting: N:\sources\license\en-us\_default\startere\license.rtf (33.4 KB)
Extracting: N:\sources\license\en-us\_default\startern\license.rtf (95 KB)
Extracting: N:\sources\license\en-us\_default\ultimate\license.rtf (113.7 KB)
Extracting: N:\sources\license\en-us\_default\ultimatee\license.rtf (28.3 KB)
Extracting: N:\sources\license\en-us\_default\ultimaten\license.rtf (105.6 KB)
Extracting: N:\sources\license\en-us\eval\enterprise\license.rtf (99.2 KB)
Extracting: N:\sources\license\en-us\eval\enterprisee\license.rtf (28.3 KB)
Extracting: N:\sources\license\en-us\eval\enterprisen\license.rtf (29.7 KB)
Extracting: N:\sources\license\en-us\eval\homebasic\license.rtf (28.3 KB)
Extracting: N:\sources\license\en-us\eval\homebasice\license.rtf (28.3 KB)
Extracting: N:\sources\license\en-us\eval\homebasicn\license.rtf (28.3 KB)
Extracting: N:\sources\license\en-us\eval\homepremium\license.rtf (28.3 KB)
Extracting: N:\sources\license\en-us\eval\homepremiume\license.rtf (28.3 KB)
Extracting: N:\sources\license\en-us\eval\homepremiumn\license.rtf (28.3 KB)
Extracting: N:\sources\license\en-us\eval\professional\license.rtf (28.3 KB)
Extracting: N:\sources\license\en-us\eval\professionale\license.rtf (28.3 KB)
Extracting: N:\sources\license\en-us\eval\professionaln\license.rtf (28.3 KB)
Extracting: N:\sources\license\en-us\eval\starter\license.rtf (28.3 KB)
Extracting: N:\sources\license\en-us\eval\startere\license.rtf (28.3 KB)
Extracting: N:\sources\license\en-us\eval\startern\license.rtf (28.3 KB)
Extracting: N:\sources\license\en-us\eval\ultimate\license.rtf (28.3 KB)
Extracting: N:\sources\license\en-us\eval\ultimatee\license.rtf (28.3 KB)
Extracting: N:\sources\license\en-us\eval\ultimaten\license.rtf (28.3 KB)
Extracting: N:\sources\license\en-us\oem\enterprise\license.rtf (637 bytes)
Extracting: N:\sources\license\en-us\oem\enterprisee\license.rtf (28.3 KB)
Extracting: N:\sources\license\en-us\oem\enterprisen\license.rtf (640 bytes)
Extracting: N:\sources\license\en-us\oem\homebasic\license.rtf (101.1 KB)
Extracting: N:\sources\license\en-us\oem\homebasice\license.rtf (28.3 KB)
Extracting: N:\sources\license\en-us\oem\homebasicn\license.rtf (28.3 KB)
Extracting: N:\sources\license\en-us\oem\homepremium\license.rtf (105.7 KB)
Extracting: N:\sources\license\en-us\oem\homepremiume\license.rtf (36.8 KB)
Extracting: N:\sources\license\en-us\oem\homepremiumn\license.rtf (95.5 KB)
Extracting: N:\sources\license\en-us\oem\professional\license.rtf (40.5 KB)
Extracting: N:\sources\license\en-us\oem\professionale\license.rtf (38.3 KB)
Extracting: N:\sources\license\en-us\oem\professionaln\license.rtf (35 KB)
Extracting: N:\sources\license\en-us\oem\starter\license.rtf (99.7 KB)
Extracting: N:\sources\license\en-us\oem\startere\license.rtf (33.4 KB)
Extracting: N:\sources\license\en-us\oem\startern\license.rtf (95 KB)
Extracting: N:\sources\license\en-us\oem\ultimate\license.rtf (39.9 KB)
Extracting: N:\sources\license\en-us\oem\ultimatee\license.rtf (37.7 KB)
Extracting: N:\sources\license\en-us\oem\ultimaten\license.rtf (34.5 KB)
Extracting: N:\sources\locale.nls (410 KB)
Extracting: N:\sources\locdrv.dll (361.5 KB)
Extracting: N:\sources\logprovider.dll (104.5 KB)
Extracting: N:\sources\migisol.dll (121 KB)
Extracting: N:\sources\migtestplugin.dll (39.5 KB)
Extracting: N:\sources\mofd.dll (272 KB)
Extracting: N:\sources\mofinstall.dll (74.5 KB)
Extracting: N:\sources\msdelta.dll (441 KB)
Extracting: N:\sources\msftedit.dll (781 KB)
Extracting: N:\sources\mspatcha.dll (45.5 KB)
Extracting: N:\sources\msxml6.dll (1.7 MB)
Extracting: N:\sources\msxml6r.dll (2 KB)
Extracting: N:\sources\ndiscompl.dll (102.5 KB)
Extracting: N:\sources\nlsbres.dll (67.5 KB)
Extracting: N:\sources\ntdsupg.dll (23.5 KB)
Extracting: N:\sources\ntfrsupg.dll (42.5 KB)
Extracting: N:\sources\oemhelpins.dll (217 KB)
Extracting: N:\sources\offline.xml (35.9 KB)
Extracting: N:\sources\oscomps.xml (573.9 KB)
Extracting: N:\sources\osfilter.inf (20.5 KB)
Extracting: N:\sources\pidgenx.dll (1.4 MB)
Extracting: N:\sources\pkeyconfig.xrm-ms (995 KB)
Extracting: N:\sources\pnpibs.dll (80 KB)
Extracting: N:\sources\product.ini (3.9 KB)
Extracting: N:\sources\readme.rtf (135.5 KB)
Extracting: N:\sources\repdrvfs.dll (441 KB)
Extracting: N:\sources\replacementmanifests\activedirectory-webservices-replacement.man (1.7 KB)
Extracting: N:\sources\replacementmanifests\application-experience-program-compatibility-assistant-replacement.man (11.7 KB)
Extracting: N:\sources\replacementmanifests\audiommecore-other-migration-replacement.man (1.1 KB)
Extracting: N:\sources\replacementmanifests\authui-migration-replacement.man (6.2 KB)
Extracting: N:\sources\replacementmanifests\bthmig-replacement.man (853 bytes)
Extracting: N:\sources\replacementmanifests\capi2_certs-repl.man (10.5 KB)
Extracting: N:\sources\replacementmanifests\dhcpclientdll-repl.man (4.0 KB)
Extracting: N:\sources\replacementmanifests\dhcpservermigplugin-rep.man (12.5 KB)
Extracting: N:\sources\replacementmanifests\ehome-reg-inf_repl.man (3 KB)
Extracting: N:\sources\replacementmanifests\eudcedit-replacement.man (2 KB)
Extracting: N:\sources\replacementmanifests\extensibleauthenticationprotocolhostservice-rep.man (2.9 KB)
Extracting: N:\sources\replacementmanifests\failovercluster-core-wow64-rm.man (929 bytes)
Extracting: N:\sources\replacementmanifests\fonts-type1-replacement.man (1.4 KB)
Extracting: N:\sources\replacementmanifests\fundisc-replacement.man (1.4 KB)
Extracting: N:\sources\replacementmanifests\gameuxmig-replacement.man (954 bytes)
Extracting: N:\sources\replacementmanifests\iis-ftpextensibility-rm.man (1 KB)
Extracting: N:\sources\replacementmanifests\iis-ftpsvc-rm.man (1.2 KB)
Extracting: N:\sources\replacementmanifests\iis-powershellprovider-rm.man (1 KB)
Extracting: N:\sources\replacementmanifests\iis-sharedlibraries-rm.man (1.5 KB)
Extracting: N:\sources\replacementmanifests\iis-webdav-rm.man (1003 bytes)
Extracting: N:\sources\replacementmanifests\international-core-replacement.man (10.3 KB)
Extracting: N:\sources\replacementmanifests\ipv4ipv6coexistencemigration-replacement.man (3.4 KB)
Extracting: N:\sources\replacementmanifests\microsoft-activedirectory-webservices\adwsmigrate.dll (83.5 KB)
Extracting: N:\sources\replacementmanifests\microsoft-hyper-v\vmswitchmigrationplugin.dll (396 KB)
Extracting: N:\sources\replacementmanifests\microsoft-hyper-v-client-migration-replacement.man (1.3 KB)
Extracting: N:\sources\replacementmanifests\microsoft-hyper-v-drivers-migration-replacement.man (1 KB)
Extracting: N:\sources\replacementmanifests\microsoft-hyper-v-migration-replacement.man (2.4 KB)
Extracting: N:\sources\replacementmanifests\microsoft-international-core\nlscoremig.dll (98 KB)
Extracting: N:\sources\replacementmanifests\microsoft-windows-audio-mmecore-other\audmigplugin.dll (74.5 KB)
Extracting: N:\sources\replacementmanifests\microsoft-windows-bth-user\bthmigplugin.dll (84 KB)
Extracting: N:\sources\replacementmanifests\microsoft-windows-fax-service-replacement.man (3.9 KB)
Extracting: N:\sources\replacementmanifests\microsoft-windows-gameuxmig\gameuxmig.dll (23 KB)
Extracting: N:\sources\replacementmanifests\microsoft-windows-ie-adminkitbranding-repl.man (6.4 KB)
Extracting: N:\sources\replacementmanifests\microsoft-windows-ie-internetexplorer-repl.man (32.3 KB)
Extracting: N:\sources\replacementmanifests\microsoft-windows-iis-rm\iismig.dll (325.5 KB)
Extracting: N:\sources\replacementmanifests\microsoft-windows-ndis\ndismigplugin.dll (163 KB)
Extracting: N:\sources\replacementmanifests\microsoft-windows-netfx35cdfcomp-replacement.man (911 bytes)
Extracting: N:\sources\replacementmanifests\microsoft-windows-netfxcorecomp-repl.man (44.3 KB)
Extracting: N:\sources\replacementmanifests\microsoft-windows-offlinefiles-core\cscmig.dll (134 KB)
Extracting: N:\sources\replacementmanifests\microsoft-windows-offlinefiles-core\en-us\cscmig.dll.mui (2.5 KB)
Extracting: N:\sources\replacementmanifests\microsoft-windows-offlinefiles-replacement.man (2.5 KB)
Extracting: N:\sources\replacementmanifests\microsoft-windows-power-policy\powermigplugin.dll (108.5 KB)
Extracting: N:\sources\replacementmanifests\microsoft-windows-powershell-replacement.man (2.4 KB)
Extracting: N:\sources\replacementmanifests\microsoft-windows-securestartup-filterdriver-replacement.man (2 KB)
Extracting: N:\sources\replacementmanifests\microsoft-windows-shmig\shmig.dll (101 KB)
Extracting: N:\sources\replacementmanifests\microsoft-windows-terminalservices-appserver-licensing\tsmigplugin.dll (129 KB)
Extracting: N:\sources\replacementmanifests\microsoft-windows-terminalservices-licenseserver\tlsrepplugin.dll (101 KB)
Extracting: N:\sources\replacementmanifests\microsoft-windows-wcfcorecomp-replacement.man (865 bytes)
Extracting: N:\sources\replacementmanifests\microsoft.windows.servermanager-non_msil-replacement.man (711 bytes)
Extracting: N:\sources\replacementmanifests\mmsys-migration-replacement.man (1.3 KB)
Extracting: N:\sources\replacementmanifests\ndis-repl.man (3.0 KB)
Extracting: N:\sources\replacementmanifests\nfs-admincore-repl.man (1.2 KB)
Extracting: N:\sources\replacementmanifests\nfs-clientcore-repl.man (1.2 KB)
Extracting: N:\sources\replacementmanifests\nfs-servercore-repl.man (1.2 KB)
Extracting: N:\sources\replacementmanifests\powermanagement-powerpolicy-definitions-replacement.man (1.4 KB)
Extracting: N:\sources\replacementmanifests\powermanagement-powerpolicy-migration-replacement.man (652 bytes)
Extracting: N:\sources\replacementmanifests\printing-localprinting-replacement.man (1.2 KB)
Extracting: N:\sources\replacementmanifests\printing-servercore-wow64-rm.man (930 bytes)
Extracting: N:\sources\replacementmanifests\propsys-replacement.man (2.0 KB)
Extracting: N:\sources\replacementmanifests\provsvc-replacement.man (1.4 KB)
Extracting: N:\sources\replacementmanifests\rasapi-repl.man (5.5 KB)
Extracting: N:\sources\replacementmanifests\rasmanservice-repl.man (1.7 KB)
Extracting: N:\sources\replacementmanifests\rasppp-repl.man (2.7 KB)
Extracting: N:\sources\replacementmanifests\rights-management-client-v1-api-replacement.man (4.4 KB)
Extracting: N:\sources\replacementmanifests\servercore-ea-ime-wow64-rm.man (777 bytes)
Extracting: N:\sources\replacementmanifests\servercore-wow64-rm.man (763 bytes)
Extracting: N:\sources\replacementmanifests\shmig-replacement.man (1.1 KB)
Extracting: N:\sources\replacementmanifests\sounds-migration-replacement.man (2.3 KB)
Extracting: N:\sources\replacementmanifests\srm-datascrndriver-repl.man (2.6 KB)
Extracting: N:\sources\replacementmanifests\srm-quotadriver-repl.man (2.5 KB)
Extracting: N:\sources\replacementmanifests\srm-service-repl.man (4.0 KB)
Extracting: N:\sources\replacementmanifests\srm-service-reports-repl.man (2.8 KB)
Extracting: N:\sources\replacementmanifests\srm-ui-repl.man (2.4 KB)
Extracting: N:\sources\replacementmanifests\stickynotes-replacement.man (1.4 KB)
Extracting: N:\sources\replacementmanifests\suacore-wow64-rm.man (918 bytes)
Extracting: N:\sources\replacementmanifests\sysdm-replacement.man (1.4 KB)
Extracting: N:\sources\replacementmanifests\sysmain-replacement.man (1.7 KB)
Extracting: N:\sources\replacementmanifests\tabletpc-uihub-replacement.man (10.9 KB)
Extracting: N:\sources\replacementmanifests\tabletpcplatforminput-core-replacement.man (15.3 KB)
Extracting: N:\sources\replacementmanifests\tabletpcstickynotes-replacement.man (1.9 KB)
Extracting: N:\sources\replacementmanifests\tcpip-replacement.man (15.9 KB)
Extracting: N:\sources\replacementmanifests\terminalservices-appserver-licensing-replacement.man (1.1 KB)
Extracting: N:\sources\replacementmanifests\terminalservices-licenseserver-replacement.man (1.5 KB)
Extracting: N:\sources\replacementmanifests\terminalservices-manager-snapin-replacement.man (1.1 KB)
Extracting: N:\sources\replacementmanifests\terminalservices-rapwebpart-replacement.man (1.1 KB)
Extracting: N:\sources\replacementmanifests\terminalservices-sbmgr-snapin-non_msil-replacement.man (786 bytes)
Extracting: N:\sources\replacementmanifests\usb\usbmigplugin.dll (78 KB)
Extracting: N:\sources\replacementmanifests\usbmigplugin-replacement.man (642 bytes)
Extracting: N:\sources\replacementmanifests\virtualdiskservice-repl.man (1.7 KB)
Extracting: N:\sources\replacementmanifests\vssservice-repl.man (4 KB)
Extracting: N:\sources\replacementmanifests\vsssystemprovider-replacement.man (2.9 KB)
Extracting: N:\sources\replacementmanifests\wcf-http-activation-replacement.man (850 bytes)
Extracting: N:\sources\replacementmanifests\wcf-nonhttp-activation-replacement.man (860 bytes)
Extracting: N:\sources\replacementmanifests\windows-markettheme-mctadmin-component-replacement.man (973 bytes)
Extracting: N:\sources\replacementmanifests\windowssearchengine\wsearchmigplugin.dll (76.5 KB)
Extracting: N:\sources\replacementmanifests\windowssearchengine-replacement.man (5.8 KB)
Extracting: N:\sources\replacementmanifests\wmdmigration-replacement.man (4 KB)
Extracting: N:\sources\replacementmanifests\wmi-core-replacement.man (1.8 KB)
Extracting: N:\sources\replacementmanifests\wsrm-service-replacement.man (2.1 KB)
Extracting: N:\sources\rmsupg.dll (57 KB)
Extracting: N:\sources\rollback.exe (110.5 KB)
Extracting: N:\sources\schema.dat (88 KB)
Extracting: N:\sources\sdbapiu.dll (115.5 KB)
Extracting: N:\sources\segoeui.ttf (505.3 KB)
Extracting: N:\sources\servicing\0.0.0.1\xmllite.dll (195 KB)
Extracting: N:\sources\servicingstackmisc\apds.dll (2.1 MB)
Extracting: N:\sources\servicingstackmisc\apircl.dll (270 KB)
Extracting: N:\sources\servicingstackmisc\apss.dll (229.5 KB)
Extracting: N:\sources\setup.exe (260 KB)
Extracting: N:\sources\sfcn.dat (1.8 KB)
Extracting: N:\sources\sflcid.dat (1.6 KB)
Extracting: N:\sources\sflistlh.dat (3.1 MB)
Extracting: N:\sources\sflistw7.dat (2 MB)
Extracting: N:\sources\sflistxp.dat (1.4 MB)
Extracting: N:\sources\sfpat.inf (10.2 KB)
Extracting: N:\sources\sfpatlh.inf (9.4 KB)
Extracting: N:\sources\sfpatpg.inf (462 bytes)
Extracting: N:\sources\sfpatw7.inf (3.3 KB)
Extracting: N:\sources\sfpatxp.inf (4.3 KB)
Extracting: N:\sources\smiengine.dll (911.5 KB)
Extracting: N:\sources\smipi.dll (102 KB)
Extracting: N:\sources\sperr32.exe (120.6 KB)
Extracting: N:\sources\spflvrnt.dll (24.5 KB)
Extracting: N:\sources\spprgrss.dll (56.5 KB)
Extracting: N:\sources\spwizeng.dll (435.5 KB)
Extracting: N:\sources\spwizimg.dll (8.0 MB)
Extracting: N:\sources\spwizres.dll (7.5 KB)
Extracting: N:\sources\sqmapi.dll (239 KB)
Extracting: N:\sources\ssshim.dll (119 KB)
Extracting: N:\sources\sysmain.sdb (121.8 KB)
Extracting: N:\sources\sysmain32.sdb (3.7 MB)
Extracting: N:\sources\uddicomp.dll (40 KB)
Extracting: N:\sources\unattend.dll (243 KB)
Extracting: N:\sources\unbcl.dll (979 KB)
Extracting: N:\sources\upgcmi2migxml.dll (232 KB)
Extracting: N:\sources\upgcompat.inf (18.6 KB)
Extracting: N:\sources\upgcore.dll (7.8 MB)
Extracting: N:\sources\upgcsiagent.dll (446.5 KB)
Extracting: N:\sources\upgdriver.dll (885.5 KB)
Extracting: N:\sources\upghost.exe (259.5 KB)
Extracting: N:\sources\upgloader.dll (257.5 KB)
Extracting: N:\sources\upgmxeagent.dll (145 KB)
Extracting: N:\sources\upgrade_bulk.xml (163.8 KB)
Extracting: N:\sources\upgradeagent.dll (3.6 MB)
Extracting: N:\sources\upgradeagent.xml (58.3 KB)
Extracting: N:\sources\upgreport.dll (549 KB)
Extracting: N:\sources\upgres.dll (36 KB)
Extracting: N:\sources\upgwow_bulk.xml (91.9 KB)
Extracting: N:\sources\uxlib.dll (151 KB)
Extracting: N:\sources\uxlibres.dll (2.5 KB)
Extracting: N:\sources\vofflps.rtf (63.8 KB)
Extracting: N:\sources\w32uiimg.dll (2.9 MB)
Extracting: N:\sources\w32uires.dll (254.5 KB)
Extracting: N:\sources\warning.gif (597 bytes)
Extracting: N:\sources\wbemcomn.dll (517 KB)
Extracting: N:\sources\wbemcore.dll (1.2 MB)
Extracting: N:\sources\wbemprox.dll (42.5 KB)
Extracting: N:\sources\wcmtypes.xsd (1 KB)
Extracting: N:\sources\wcp.dll (2.6 MB)
Extracting: N:\sources\wdsclient.dll (609.5 KB)
Extracting: N:\sources\wdsclientapi.dll (143.5 KB)
Extracting: N:\sources\wdscore.dll (265 KB)
Extracting: N:\sources\wdscsl.dll (67.5 KB)
Extracting: N:\sources\wdsimage.dll (688.5 KB)
Extracting: N:\sources\wdstptc.dll (144.5 KB)
Extracting: N:\sources\wdsupgcompl.dll (10.5 KB)
Extracting: N:\sources\wdsutil.dll (57 KB)
Extracting: N:\sources\win32ui.dll (564 KB)
Extracting: N:\sources\winsetup.dll (2.1 MB)
Extracting: N:\sources\wmi_tracing.mof (1.6 KB)
Extracting: N:\sources\wmicmiplugin.dll (512 KB)
Extracting: N:\sources\wmiutils.dll (134 KB)
Extracting: N:\sources\xmllite.dll (195 KB)
Extracting: N:\support\logging\actionqueueetw.dll (4 KB)
Extracting: N:\support\logging\auditetw.dll (4 KB)
Extracting: N:\support\logging\cmisetupetw.dll (3.5 KB)
Extracting: N:\support\logging\en-us\actionqueueetw.dll.mui (3 KB)
Extracting: N:\support\logging\en-us\auditetw.dll.mui (3 KB)
Extracting: N:\support\logging\en-us\cmisetupetw.dll.mui (4 KB)
Extracting: N:\support\logging\en-us\oobeldretw.dll.mui (3 KB)
Extracting: N:\support\logging\en-us\setupcletw.dll.mui (4.5 KB)
Extracting: N:\support\logging\en-us\setupetw.dll.mui (3.5 KB)
Extracting: N:\support\logging\en-us\setupugcetw.dll.mui (3 KB)
Extracting: N:\support\logging\en-us\sysprepetw.dll.mui (3 KB)
Extracting: N:\support\logging\en-us\windeployetw.dll.mui (3 KB)
Extracting: N:\support\logging\en-us\winsetupetw.dll.mui (50.5 KB)
Extracting: N:\support\logging\etwproviderinstall.vbs (6.7 KB)
Extracting: N:\support\logging\microsoft-windows-actionqueue-instrumentation.man (5.7 KB)
Extracting: N:\support\logging\microsoft-windows-audit-instrumentation.man (6.6 KB)
Extracting: N:\support\logging\microsoft-windows-cmisetup-instrumentation.man (6.2 KB)
Extracting: N:\support\logging\microsoft-windows-oobeldr-instrumentation.man (7.6 KB)
Extracting: N:\support\logging\microsoft-windows-setup-events.man (10.2 KB)
Extracting: N:\support\logging\microsoft-windows-setup-instrumentation.man (8.1 KB)
Extracting: N:\support\logging\microsoft-windows-setupcl-instrumentation.man (10.6 KB)
Extracting: N:\support\logging\microsoft-windows-setupugc-instrumentation.man (6.6 KB)
Extracting: N:\support\logging\microsoft-windows-sysprep-instrumentation.man (6 KB)
Extracting: N:\support\logging\microsoft-windows-windeploy-instrumentation.man (6.6 KB)
Extracting: N:\support\logging\oobeldretw.dll (4 KB)
Extracting: N:\support\logging\setupcletw.dll (5.5 KB)
Extracting: N:\support\logging\setupetw.dll (5 KB)
Extracting: N:\support\logging\setupugcetw.dll (4 KB)
Extracting: N:\support\logging\sysprepetw.dll (4 KB)
Extracting: N:\support\logging\windeployetw.dll (3.5 KB)
Extracting: N:\support\logging\winsetupetw.dll (6.5 KB)
Extracting: N:\support\migwiz\cable\cableinst.exe (10.5 KB)
Extracting: N:\support\migwiz\cmi2migxml.dll (233 KB)
Extracting: N:\support\migwiz\csiagent.dll (629 KB)
Extracting: N:\support\migwiz\en-us\input.dll.mui (23.5 KB)
Extracting: N:\support\migwiz\en-us\migautoplay.exe.mui (2 KB)
Extracting: N:\support\migwiz\en-us\migres.dll.mui (7 KB)
Extracting: N:\support\migwiz\en-us\migsetup.exe.mui (3.5 KB)
Extracting: N:\support\migwiz\en-us\migwiz.exe.mui (2 KB)
Extracting: N:\support\migwiz\en-us\postmig.exe.mui (21 KB)
Extracting: N:\support\migwiz\en-us\svrmig.dll.mui (2.5 KB)
Extracting: N:\support\migwiz\en-us\wet.dll.mui (89 KB)
Extracting: N:\support\migwiz\imjpmig.dll (39.5 KB)
Extracting: N:\support\migwiz\imkrmig.dll (46 KB)
Extracting: N:\support\migwiz\imscmig.dll (36 KB)
Extracting: N:\support\migwiz\imtcmig.dll (23.5 KB)
Extracting: N:\support\migwiz\input.dll (240.5 KB)
Extracting: N:\support\migwiz\installsvrmig.cmd (1.5 KB)
Extracting: N:\support\migwiz\migapp.xml (543 KB)
Extracting: N:\support\migwiz\migautoplay.exe (89.4 KB)
Extracting: N:\support\migwiz\migcore.dll (7.7 MB)
Extracting: N:\support\migwiz\migfiles.dat (324 bytes)
Extracting: N:\support\migwiz\mighost.exe (259.5 KB)
Extracting: N:\support\migwiz\migisol.dll (121 KB)
Extracting: N:\support\migwiz\migres.dll (7 KB)
Extracting: N:\support\migwiz\migsetup.exe (159.8 KB)
Extracting: N:\support\migwiz\migstore.dll (1.1 MB)
Extracting: N:\support\migwiz\migsys.dll (377 KB)
Extracting: N:\support\migwiz\migwiz.exe (532 KB)
Extracting: N:\support\migwiz\msctfmig.dll (194.5 KB)
Extracting: N:\support\migwiz\mxeagent.dll (300 KB)
Extracting: N:\support\migwiz\postmig.exe (768 KB)
Extracting: N:\support\migwiz\postmigres\data\hardwarevendors.xml (984 bytes)
Extracting: N:\support\migwiz\postmigres\web\base_images\appinstalled.gif (1 KB)
Extracting: N:\support\migwiz\postmigres\web\base_images\clickdownexpanded.gif (1.1 KB)
Extracting: N:\support\migwiz\postmigres\web\base_images\clickdownnormal.gif (1.1 KB)
Extracting: N:\support\migwiz\postmigres\web\base_images\column.bmp (18.2 KB)
Extracting: N:\support\migwiz\postmigres\web\base_images\documents.gif (1.1 KB)
Extracting: N:\support\migwiz\postmigres\web\base_images\failure.gif (1.9 KB)
Extracting: N:\support\migwiz\postmigres\web\base_images\programs.gif (2.3 KB)
Extracting: N:\support\migwiz\postmigres\web\base_images\system.gif (1.9 KB)
Extracting: N:\support\migwiz\postmigres\web\base_images\users.gif (2.1 KB)
Extracting: N:\support\migwiz\postmigres\web\base_images\windowsmail.bmp (4.1 KB)
Extracting: N:\support\migwiz\postmigres\web\base_images\windowsmoviemaker.bmp (4.1 KB)
Extracting: N:\support\migwiz\postmigres\web\base_images\windowsoutlookexpress.bmp (4.1 KB)
Extracting: N:\support\migwiz\postmigres\web\base_images\windowsphotogallery.bmp (4.1 KB)
Extracting: N:\support\migwiz\postmigres\web\reportapi.js (18.9 KB)
Extracting: N:\support\migwiz\segoeui.ttf (402.9 KB)
Extracting: N:\support\migwiz\sfcn.dat (1.8 KB)
Extracting: N:\support\migwiz\sflcid.dat (1.6 KB)
Extracting: N:\support\migwiz\sflistlh.dat (3.1 MB)
Extracting: N:\support\migwiz\sflistw7.dat (2 MB)
Extracting: N:\support\migwiz\sflistxp.dat (1.4 MB)
Extracting: N:\support\migwiz\sfpat.inf (10.2 KB)
Extracting: N:\support\migwiz\sfpatlh.inf (9.4 KB)
Extracting: N:\support\migwiz\sfpatpg.inf (462 bytes)
Extracting: N:\support\migwiz\sfpatw7.inf (3.3 KB)
Extracting: N:\support\migwiz\sfpatxp.inf (4.3 KB)
Extracting: N:\support\migwiz\svrmig.dll (667.5 KB)
Extracting: N:\support\migwiz\svrmigtest.dll (74 KB)
Extracting: N:\support\migwiz\tabletextservicemig.dll (40 KB)
Extracting: N:\support\migwiz\unbcl.dll (979 KB)
Extracting: N:\support\migwiz\wdscore.dll (265 KB)
Extracting: N:\support\migwiz\wet.dll (9.6 MB)
Extracting: N:\support\tools\gbunicnv.exe (37 KB)
Extracting: N:\upgrade\netfx\netfx.msi (5.6 MB)
Extracting: N:\upgrade\netfx\netfx.msp (18.3 MB)
Extracting: N:\upgrade\netfx\netfx1.cab (16.1 MB)
Extracting: N:\upgrade\netfx\netfxupdate.exe (72 KB)
Finalizing, please wait...
N:autorun.inf already exists - keeping it
NTFS Fixup (Checkdisk)...
Volume label is Win7AIO-SP1-x64-Mar2014.

CHKDSK is verifying files (stage 1 of 3)...
  1280 file records processed.
File verification completed.
  0 large file records processed.
  0 bad file records processed.
  0 EA records processed.
  0 reparse records processed.
CHKDSK is verifying indexes (stage 2 of 3)...
  1710 index entries processed.
Index verification completed.
CHKDSK is verifying security descriptors (stage 3 of 3)...
  1280 file SDs/SIDs processed.
Security descriptor verification completed.
  215 data files processed.
Windows has checked the file system and found no problems.

  10484735 KB total disk space.
   5408304 KB in 898 files.
       372 KB in 217 indexes.
     56495 KB in use by the system.
     54480 KB occupied by the log file.
   5019564 KB available on disk.
      4096 bytes in each allocation unit.
   2621183 total allocation units on disk.
   1254891 allocation units available on disk.
NTFS Fixup completed.

Found VHD device 'Msft Virtual Disk SCSI Disk Device'
Device eliminated because it was detected as an USB Hard Drive (score 3 > 0)
If this device is not an USB Hard Drive, please e-mail the author of this application
NOTE: You can enable the listing of USB Hard Drives in 'Advanced Options' (after clicking the white triangle)
Found USB device 'Multiple Card  Reader USB Device' (058F:6366)
Device eliminated because it appears to contain no media
0 devices found

i will be very thankful if you can help me correct my corrupt USBs.

ghost picture ghost on 16 Apr 2014

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?

pbatard picture pbatard on 16 Apr 2014

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.
i really hope i can correct them.

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.

ghost picture ghost on 16 Apr 2014

question: how can i delete VHD?

ghost picture ghost on 16 Apr 2014

sorry for doubting your nice software

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?

question: how can i delete VHD?

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 .vhd file at the location where you chose to save it.

pbatard picture pbatard on 16 Apr 2014

when i right-click on "disk management", there is only "create VHD" and "attach VHD".
"Detach VHD" does not exist!
and i cant delete .vhd file because "the file is open in system"!

ghost picture ghost on 16 Apr 2014

You need to click on the part that has the Disk number, NOT "Disk management". See the following screenshot:

image1

pbatard picture pbatard on 16 Apr 2014

thanks for the answer
my last question: is it possible that i install windows from a bootable VHD?

ghost picture ghost on 16 Apr 2014

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 dd, after having mounted the VHD in Disk Manager or using the .vhd as the source (from what I can see, the VHD content is a flat copy of the disk data blocks, without anything extra added, so you should be able to use the file as the source, without having to mount it). Basically, what you want to do is clone one drive to another, except the source will be virtual rather than physical. Hope that helps.

pbatard picture pbatard on 16 Apr 2014

thanks again for the answer.

ghost picture ghost on 16 Apr 2014

Closing this issue.

pbatard picture pbatard on 15 May 2014

In millions of downloads of Rufus, this is really the only report I have ever gotten of a drive failing with write protected

Make it two, last night my USB drive became write protected after I used Rufus to write a Windows 10 image to it.

sarathkcm picture sarathkcm on 16 Apr 2017

for what it's worth, this software messes up with USB drives.
definitely not a coincidence that perfectly working usb drive would take the blame after using this tool and getting your usb into write-protect state.

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.

jin0001 picture jin0001 on 12 Aug 2017

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

pbatard picture pbatard on 12 Aug 2017

Hi @pbatard :wave:

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.

unsungNovelty picture unsungNovelty on 13 Aug 2017

I don't think it is an isolated incident.

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.

just now confirmed the end point was Rufus.

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:
_"But what if Rufus screws up the data it sends to the Hardware Abstraction Layer? Couldn't that somehow result in Windows sending bad USB commands to the flash drive?"_

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.
Also, and this is the most important point, you have to realize that these APIs are very limited. For instance, here is the __ONLY__ API call that is ever used in Rufus to write to an USB flash drive (either directly or indirectly, but the indirect calls always translate to WriteFile() being issued in the end).
If you know a little bit about programming, you'll have to explain to me how it's possible to screw up parameters so bad that Windows will end up sending a "bad" USB command on the USB bus. If you use the wrong handle, you're not gonna be accessing the flash drive at all (unless Windows is super buggy) so we can eliminate that. And we never use Overlapped mode (which wouldn't screw us up in the first place anyway), so that leaves passing either a wrong buffer (but if you address is corrupt, you'll get a segmentation fault in the Windows application, not on the target device) or a buffer with bad data... knowing that there's nothing in the Mass Storage protocol that will make the USB bus choke on specific data content (because it's of course designed to be data agnostic, meaning that, as far as the Mass Storage USB protocol is concerned, __any__ data you have in your buffer is just fine and there's no such thing as data that is "more valid" than other). In other words, you could write whatever random stuff you want in your buffer, it's never going to end up producing anything on the USB bus but a Mass Storage message that says "Here's some data for you, that you should write at address N". Especially, it's NEVER going to result in a non Mass Storage USB command (such as "vendor-internal: switch to read-only") being issued on the USB bus. Even if Rufus is buggy, all you'll ever get on the USB bus are regular "read sector N" or "write sector N" messages, that are the only messages Windows can produce in the way the application works, and that's it.

And with this we come nicely to "comeback" 3:
_"But what if you actually send garbage data for the USB controller to write, or tell it to write the data to some 'special sectors'? Surely if you do that, you may end up screwing up the drive!"_

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

  1. The idea that there exists "special sectors" on an USB flash drive, __that can be accessed through standard USB commands (such as the "write sector N" we've seen above)__ is wrong. That's not to say that there might not exist special sectors that are being used to store the controller firmware, but, unless that controller is buggy, it should never let you access these sectors through the regular "write/read sector N" commands. Especially, the sector at address 0 should be the very first sector that the controller designates as accessible for storing user data (NB: this includes the MBR or any sector that belongs to a partition table, which, as far as the controller, Windows and Rufus are concerned __ARE__ pure user data), and, unless it has a major bug, it should return an error whenever it receives a standard command that asks it to read a sector that is lower than 0 or higher than the total capacity the controller has reserved for user data.
    All this to say, even if you were to have a buggy application that somehow manages to get Windows to send a "write sector -1 with this data" command on the USB bus, the Flash drive controller will always validate that the sector it is being asked to write to belongs to the user data range, __before__ it does anything, and will return an error if it doesn't (that is, unless your firmware is very buggy, but even then, I can tell you that Windows should have validated the sector range before the controller gets to do the same, so even if your firmware is buggy, it shouldn't actually matter). In other words, no matter how hard you try, you can not use Windows's WriteFile() (which, again, after device enumeration, is the only call that Rufus ever uses that translates into sending USB bus commands) to overwrite something like the memory area that is used by the firmware (the only exception I can see for this is if you are using a "fake" drive, but if you do, then you can't expect any application, including Windows, not to mess that drive up as soon as you write more data than to it than its actual "non-fake" capacity), let alone toggle a firmware-internal flag such as "read-only" mode.
  2. But what about partition table sectors? Surely the sectors that hold the partition table must be "special" and writing buggy data into them might be the reason why a drive could turn read-only?
    Unfortunately, that whole reasoning falls flat when you know that Windows (or any other OS for that matter) does not see the partition table sectors (or MBR, or VBR/PBR or whatever other set or sector you were told were "special" because if you overwrite them you could lose your data — but please don't conflate losing data with rendering a drive inoperable, since you can always reuse a drive after you lose the data it contained) as any different than any other sectors from your drive. If you can take a completely blank drive and repartition it/reformat it in Windows, or even a drive that has been secure-erased, then clearly, there's nothing that "special" about some sectors compared to other, and, even if you write garbage data on these, the worst thing you'll have to do is repartition/reformat the drive. Especially, you will NEVER end up in a situation where you actually can't recover the drive, no matter what amount of sectors were overwritten with garbage data. Therefore, it is not possible to screw up a drive simply by writing the "wrong" data to any of the sectors that Windows can access.

So, in summary, and as I have tried to establish:

  1. Contary to what you may believe, The Rufus code does not construct and send USB commands on the bus, so, even if there's a major bug, it just cannot inadvertently construct and send a "self destruct" command to a device. Instead it uses the Windows Hardware Abstraction Layer, that makes ALL disk devices (USB, SCSI, etc.) be accessed in the same __abstracted__ manner, i.e. without any direct possibility of control over the USB bus.
  2. Even if Rufus somehow sent garbage/buggy data to the Windows Hardware Abstraction Layer (which pretty much means to WriteFile() since that's all it ever uses to write to a device), the only way it would be able to screw up a USB flash drive is if it were to write to the non-accessible firmware-internal flash drive memory, by attempting to write to a sector that is outside of the regular range for the device. Unfortunately, the only way that could ever happen is if both Windows and the flash drive controller are buggy, because both these entities are supposed to validate the range being accessed, and reject the request if the range is invalid. That's simply not realistic (but if you believe it is, then by all means you should complain to your hardware manufacturer first, because you have just acknowledged that they have done a very crappy job).
  3. And finally, with the knowledge that, even if it was buggy, the only thing Rufus can only ever realistically access are the actual user data sectors reported by the device, and that none of these sectors (partition table, etc.) are any special, and that any competent OS will always be able to rewrite them, no matter the garbage data they contain, we have pretty much demonstrated that it is simply not logically possible for an application like Rufus to render a USB flash drive read-only or make it fail, __UNLESS THAT FLASH DRIVE ALREADY HAD A HARDWARE ISSUE IN THE FIRST PLACE__ (in which case, writing a large amount of data, which is what Rufus typically does, will produce the same issue, regardless of the application being used).

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

PS: I don't think the majority of the people know about Github in the first place

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:
"Hey, I bought a couple of drives from a reputable vendor (e.g. SanDisk, Adata, etc.), but when I used them with Rufus, these drives switched to read-only. So I RMA'd the drives to the vendor, describing what I did, to ask them if they could replicate the issue. They have now come back to me and confirmed that Rufus is the source of the problem because [insert explanation from people who actually have some expertise on the matter here]...".

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

pbatard picture pbatard on 13 Aug 2017
👍4

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.

image

johnheintz picture johnheintz on 16 Aug 2017

I have lost 3 USB drives to this same issue from different vendors.

Full make and model please, and capacity. Did you purchase them from the same vendor? When were they purchased?
Also, what was the log from Rufus? I would expect that, by the 3rd time, you would be taking a close look at the Rufus log to see what's going on. Do you at least remember the error Rufus produced? And have you ever tried running a bad blocks check __before__ trying to copy an ISO? If so, what did the bad blocks check report?
What did the vendor(s) say when you RMA'd your drives? If they are recent purchases, you should have no trouble RMAing them. If, on the other hand you cannot RMA these failed drives, it means that they are pretty old, and therefore more prone to having memory issues.

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.

To date, i have not been able to recover any of them.

What do you see in Windows Disk Manager? Have you tried plugging them on a Linux machine? What does dmesg on Linux report after you plug them?

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 WriteFile() to access USB Flash Drives to make these drive fails.

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.

pbatard picture pbatard on 16 Aug 2017

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.

pbatard picture pbatard on 16 Aug 2017

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

johnheintz picture johnheintz on 16 Aug 2017

I can setup a webex to show what happens on my computer when I try and use the tool.

I'd rather you answer all the questions I asked. Or provide a log from Rufus. Webex will not tell me anything more that I can't get from the log.

I have not RMA’d any of the UBS stick as most are from vendors at trade shows.

Well, if I know one thing from trade shows is that they're certainly not going to give quality drives for free. If they went with the cheapest seller, there's a good chance some of these drives to be fake, which would explain a lot...

As I said, any attempt to point the finger at Rufus will be a lot more credible if you actually RMA the drive and get some info from the vendor as to what they think have caused the failure...

pbatard picture pbatard on 16 Aug 2017

Same problem with 3 my pen drive :(

emax810 picture emax810 on 17 Aug 2017

And same questions as here.

Unless you can provide comprehensive details, I'm going to have to assume a lot of things, which aren't going to be in your favour, such as:

  • You probably bought a batch of cheap "fake" USB Flash Drives. Of course, if you try to use a "fake" drive, that reports something like 16 or 32 GB capacity, when it only has 2 or 4GB actual flash memory, you are going to think that everything is fine as you only use it with a small amount of files. But then, as soon as you use Rufus with an ISO, you're going to go over the actual drive capacity, and believe that Rufus destroyed your drive, whereas the only issue is that your drive was a fake.
  • You are probably mistaken and think your drive is read-only or damaged, because you can't access its data in Windows, whereas your drive is working just fine, and you just don't know how to properly reset it. For instance, do you know that if you apply some Chromium image files to an USB drive (#759), it will look as if it is damaged, because Windows can't format it at all (NB: This is a Windows bug and you can se this behaviour without using Rufus at all)? But if you repartition and reformat it in Linux, then everything is back to normal? In other words it's very easy to erroneously conclude that a flash drive is damaged, when it isn't and can be easily recovered. Especially, you gotta try with a different OS than Windows before you can conclude that a drive is defective.
  • Your drives were defective from the start in one manner or another. The fact that someone would happen to lose 3 flash drives but decide not to run a bad blocks check after they already seem to have lost 2 drives is usually an indication that someone is using cheap drives, that are prone to be defective. I have yet to see a report stating "I did run a bad blocks check before I tried with my 3rd drive, and it was okay - Here is the log to prove it"
  • Besides OP, noone seems to want to report the errors they got in Rufus when their drive failed, or their logs. If you lost 3 drives, and __believe__ that Rufus is the issue, the first thing I'd expect is that you wrote the error down, or saved the log, and would contact me (through e-mail or through this issue tracker) right away to report that. For instance, you would be able to report something like _"I got the error Could not delete drive layout"_ as OP reported. Coz, if you didn't get an error, it means that your drive clearly wasn't read-only by the time Rufus was done with it, and you shouldn't piggyback on a thread that says "Rufus write protected my USB drives" when your drives apparently turned to read-only long after you were done with Rufus. In other words, unless you can report an error, I'm going to assume that Rufus had no issue creating your drives, but that they turned read-only later on, and that you are jumping on the bandwagon of "Rufus write protected my USB drives" because you happened to use Rufus once, on flash drives that have become defective.

So, it's fine and all to want to report that you have failed drives, but you also need to be prepared to provide comprehensive details about these drives. Piggybacking on this thread to say _"me too"_ is not going to help anyone, be it the people who think that Rufus can somehow turn a drive to read-only, or the people who are trying to demonstrate that the explanation for this behaviour has to be found elsewhere.

pbatard picture pbatard on 17 Aug 2017

Hello Pete,

I appreciate you addressing this issue with a full bloat of logical explanation.
How about you loosen up a bit, be open minded and see the bigger picture here.

The incidents clearly imply that random USB drive, doesn't matter what brand or make, be it cheap or high-end "can be" damaged by Rufus. This may be superficial to your point of view but isn't this a notion for future improvement of this tool.

Unreported incidents should not be taken out of the equation here as that is a bit small thinking.
There may be millions of satisfied users using this tool but the isolated incidents affecting a fraction of this million, are in hundreds or even a thousand. Very puny percentile compared to the lucky million users.

The incident reports are purely identical. Random user, downloaded Rufus, plugged-in USB, modified setting based on his/her requirement, ran the tool and voila!
Isn't that definitive enough to ponder about?

IMO, it would be nice if this will be investigated further by your team and not just be taken for granted.
I totally get the point of coincidence but that gives me the idea that this tool somehow catalyzes the probability of ruining a perfectly working USB drive. What went wrong?
That is something to probe further by Rufus DevOps.
There could be a common denominator in these wrecked drives that Rufus is just unfriendly about.

Either way, I've stated my point, I am not here to be a burden, I'm just a messenger.
I look forward to the improvement of this tool.

PS: I still have the corpse of my late USB drive, should you need it, I'd be happy to donate for autopsy.

jin0001 picture jin0001 on 17 Aug 2017

How about you loosen up a bit, be open minded and see the bigger picture here.

I'm afraid that all I'm seeing from these reports is people who consistently fail to provide detailed information about their failed drives. Every time I have been asking for a make and model of these failed drives recently, and whether they had been recently been checked for bad blocks, I am met with stony silence.

The incidents clearly imply that random USB drive, doesn't matter what brand or make, be it cheap or high-end "can be" damaged by Rufus.

I beg to very much differ. Especially, since people don't want to report the make or model of their drives, and also, don't seem to care that much about RMA'ing them (which should be no trouble if they got it from a reputable brand, such as SanDisk), I don't see how you can conclude that it doesn't matter what brand or make. Especially, it could be that all the people who are reporting these issues have been using PNY drives (the ones with the faulty firmware), but since noone actually wants to provide any data that would help draw some conclusions about the real cause of the issue, it doesn't look like we'll ever know... The only information I've gotten so far about the kind of drives that appear to have been damaged are that these had been gotten for free, and therefore, unlikely to be high quality.

At this stage, I am very puzzled: Why does it seem to hard for people to actually report the brand and model of the USB Flash Drives that they say Rufus turned to read-only? Surely, if one does care about this issue being explained, they should have no trouble providing this kind of information.

Or do you guys really think that I'm secretly sitting on a stack of damaged drives, and that I'm simply pretending everything is fine? For the record, I have used dozens of USB flash drives with Rufus, on all kind of Windows platforms. If the issue was as prevalent as it is, I should be one of the people most affected by it. Yet, I have never ever gotten a drive that switched to read-only after using Rufus. And, as I pointed out, neither seem to have the many power users who use Rufus on a daily basis, also with all kind of flash drives. So, what's the most logical here? That the people who are most prone to confirm that there is an actual issue with Rufus, and provide comprehensive details that validate that Rufus is the cause of it, have been super lucky with their day-to-day usage of it? Or that it only affects people who happen to use unreliable drives (e.g. the stuff you get at trade shows - I got one of these once, and it barely lasted one year... and that was a quite some time before I started developing Rufus, so even if I wanted to, I could hardly blame Rufus for that failure) and/or aren't tech savvy enough to provide comprehensive data about the potential failure (such as, whether they ever tested their drive for bad blocks/ fake drive, the error/log they got from Rufus, what other platforms report when they plug the drive, in order to confirm that it is indeed failed).

Unreported incidents should not be taken out of the equation here as that is a bit small thinking.

Again, why on earth wouldn't tech-savvy people or manufacturers not report software that is allegedly damaging hardware? If you want to go with the hypothesis that Rufus does damage flash drives, then you also have to go with the hypothesis that, out of the 3 million people who download it each month, there's bound to be some who have enough expertise to provided comprehensive reports about the failure, such as a repeated test demonstrating the failure with an USB bus trace (not that difficult to get on Windows) and the kind of detailed information I asked above. Again, if Rufus was the "destroyer" of drives that people in this thread seem to want to insist it is, then surely we'd find that information plastered all over the many social media sites that people like to frequent (such as Reddit, and user forums). Yet, we're certainly not seeing the _"DON'T USE RUFUS!1!! IT'LL DESTROY YOUR FLASH DRIVES!"_ message one would expect to see there if that was actually the case. In the age where anybody can post whatever opinion they like, it's surprising that social media are awfully quiet of an issue that is supposed to affect such the large number of people you assert it affects.

The incident reports are purely identical. Random user, downloaded Rufus, plugged-in USB, modified setting based on his/her requirement, ran the tool and voila!

And yet, here I am, having tested Rufus in every condition imaginable, against a whole plethora of flash drives, and never ever having experienced this issue. And neither seem to have the many experienced people from reboot.pro (who tend to have some knowledge of these matters, and some of which i know use Rufus), or the people who use Rufus in a professional manner, even more frequently than I do, and from whom I don't recall ever receiving any e-mail such as "Rufus seems to destroy the flash drives I use" (and yet will have no trouble e-mailing "Thank you for Rufus" messages from time to time).

So, I'm afraid it's not "voila". There's something more to it, and, strangely, that something more does not affect the people who should be most affected...

Isn't that definitive enough to ponder about?

The only definitive I have from this thread is:

  1. OP has experienced the failure for 2 drives, but these drives were the same model from the same manufacturer (APTECH, which, as far as as I'm concerned, seems to be a no-name manufacturer). Most likely: bad batch or fake drive.
  2. Someone indicating that they have experienced the same issue (drive turning to read-only)... but without using Rufus. And they managed to recover their drive afterwards using a __regular__ formatting application, none of the applications they listed are manufacturer specific, which makes me think that the drive was never actually read-only, but that Windows simply prevented read-access for some reason... a reason that could hardly be blamed on Rufus, since it wasn't involved at all... If we're not going to ignore user reports, then here we have a report that seems to provide evidence that users do see drives switching to read-only regardless of the application that was used to access them.
  3. OP using a drive that is different from the model that failed, and having no issue. Interestingly, this drive was from a reputable brand (HP).
  4. __more than 3 years without any piggyback reports__ (which, considering that this issue should be one of the first thing that pop up when googling "Rufus" and "write protected flash drive" is somewhat surprising, if Rufus did affect drives that dramatically, even if people don't like to use github), and someone reporting a similar failure on one drive... which makes it hard not to dismiss it as coincidental.
  5. Someone (you) reporting failure for 2 drives, and ignoring all of the above to jump to the immediate conclusion that this must mean that Rufus destroys flash drives. But no info about brand, model, or how exactly they concluded that their drives were "perfectly working" beforehand.
  6. Another person reporting failure on one drive, and extrapolating that one failure to conclude that Rufus has to be the culprit. Sorry, but you can't exactly extrapolate from a one-drive failure, even if you are reporting it in a thread where people seem to be keen-on pointing the finger at an application.
  7. Someone reporting that they saw a failure on 3 drives. Okay, that's actually the only report in this whole series that could be indicative of a real issue. But soon enough, instead of the information requested, we learned that these drives had been gotten for free, at trade shows. Well, I've only ever gotten one drive at a trade show, but if you want to extrapolate, then let me also extrapolate from my experience by saying that these drives are pure crap. So, back to square one with no logical evidence that Rufus is going to damage your drives more than any other application, especially if you stick with reputable brands.
  8. Another person reporting failure on 3 drives, but who fails to provide any more information. Good luck finding a _common denominator_ then. Can't help to find it strange that someone who just post a "me too" right now, and also completely ignore my request for information about their drives, especially if they have experienced 3 failures... As much as I don't want to dismiss that report, it's hard to see it as valid unless additional evidence is provided, even more so as I have some reasons to be dubious about the sudden occurrence of a providential "me too" post, if the user doesn't follow up.

So, there we stand. If that's your definition of "definitive enough", then I think we have a very different opinion about what constitutes definitive data, especially if we consider the whole picture and the duration of time this thread was open for anyone with this issue to comment.

IMO, it would be nice if this will be investigated further by your team and not just be taken for granted.

Sigh. What people don't seem to understand is that I did just that when I explained how Rufus does not actually do anything different to access a USB flash drive or a regular HDD (and Rufus can access any SATA/SCSI HDDs if you use Ctrl-Alt-F and have set them to removable in your BIOS), and is only using the Windows Hardware Abstraction Layer and the super-abstracted WriteFile() call.

At this stage, I feel like I'm trying to demonstrate to people how the earth is round, by talking about the length of shadows taken at the same time at different latitudes and trigonometry, and the only answer I get is "well, I don't know about trigonometry, so, as far as I'm concerned, even if any specialist is going to have no choice but to agree with your proof, I'm still not seeing any evidence that the earth isn't flat".

I look forward to the improvement of this tool.

Not as much as a look forward to anyone who will actually demonstrate that it's actually possible to use the Hardware Abstraction Layer of Windows to turn a USB flash drive to read only, be it by pointing to the code section of Rufus that actually manages to do just that, or a RMA report from a flash drive manufacturer that indicates that their engineers confirmed that Rufus sends damaging commands to USB Flash Drives.

Since I already went over the topic, it appears that your current expectation is that I'm also going to teach people trigonometry (i.e. software programming on Windows), so that you can finally accept the __scientific__ conclusion that the earth is indeed round (i.e. that Rufus can simply not damage flash drives in the way described here). I'm afraid that's not going to happen. And I'm also afraid that, no, as much as you'd like to think otherwise, even in the large amount of code that Rufus uses, it is not possible for a software developer overlook something as dramatic as inadvertently sending self-destruct commands on the USB bus. We're not talking about a NULL pointer, or an index being overflown, that could "somehow" translate into dodgy vendor-internal USB commands being sent instead of the regular Mass Storage ones (which again, is the only way you'll get USB flash drives to toggle to read-only from an external cause). But hey, if you or anyone can provide me with the full set of conditions that will for sure turn a drive to read-only (rather than an "I've seen it happen, so everybody else should see it too!"), and that I can replicate on one of my various test machines, I'll be happy to perform an in depth USB trace analysis for you, to provide further evidence that whatever you think you've seen happening does not have anything to do with using Rufus.

PS: I still have the corpse of my late USB drive, should you need it, I'd be happy to donate for autopsy.

I'm fine with that (if you don't mind paying postage - if you e-mail me, I'll give you my address), but I'd rather get the make and model of that drive, as well as where you purchased it, plus some comprehensive details about the environment you were using Rufus on, since, if the issue is as certain as some people here seem to believe it is, I should have no problem getting the same failure with a brand new drive. Heck, as soon as someone comes to me with "I've been getting consistent failure on drive X from brand Y, which I purchased at Z, when used with Rufus" (as long as these are not the PNY drives which we know have a buggy firmware), I'll be happy to go purchase a couple of these drives on my own, to try to see what the story is.

But, as long as people here consider that the problem is so widespread that providing actionable evidence is superfluous (and that, no matter how many details I try to provide about the internals of programmatically accessing an USB Flash Drive in Windows, I must definitely have overlooked a section of code that can actually destroy drives), I'm going to continue to wait for reports that provide enough data to actually be acted upon.

pbatard picture pbatard on 17 Aug 2017

My Flash drive's make was Sandisk, model Cruzer Egde, capacity 4GB.
I was using it in Windows 10 to write a Windows 10 image to the drive, after which it became read-only.

I don't have the flashdrive now, as I threw it somewhere I don't remember. Therefore I cannot generate any diagnostic details/logs you would want to investigate.

It's because I happened to read your comment, quoted below, I commented here about the incident.
I just thought you should know.

In millions of downloads of Rufus, this is really the only report I have ever gotten of a drive failing with write protected

Regarding your comment quoted below:

I'm afraid that all I'm seeing from these reports is people who consistently fail to provide detailed information about their failed drives.

Having no knowledge of how USB works I didn't know what details you would have wanted if you were to investigate the issue. May be if you had guidelines on how to get the required logs/ what all information should be included while reporting, I would have included them.

If you are willing to acknowledge incidents like this and collect such reports to find a pattern, please do make it easy for people like me with no knowledge about USB to report such incidents.

It would be nice if you could create a form like I have created here
Or
if you could provide a form in your own website

Or
if you could create an auto template for GitHub issues opened for this repo.

Or
if you could at least provide guidelines in your wiki on how to get the logs & details you would want.

Only if you are willing.

sarathkcm picture sarathkcm on 18 Aug 2017

My Flash drive's make was Sandisk, model Cruzer Egde, capacity 4GB.

Thanks. But as I tried to explain, seeing a one drive failure is not that indicative of an issue. The flash memory used in USB devices has a limited number of write cycles before it will fail, at which case the controller present on the USB drive may switch it to read-only. This will happen regardless of the application being used. As opposed to people reporting consistent multiple failures when using different drives from different brands while using Rufus, knowing what I know about flash memory, I am pretty confident that, out of the million people who download Rufus each month, there's probably going to be tens or hundreds who will experience a __coincidental__ drive failure while using it (especially people using cheap drives), because any USB flash drive will eventually fail while using it. And I'm not even talking about the people who will have gotten "fake" drives, that report a wrong capacity and that are therefore bound to fail no matter what. But the same is true of people simply using Windows File Explorer or other applications (i.e. drives will fail in the same rate regardless of what you use to write to them). Unfortunately, what many people don't seem to realize is that the rate of failure of flash drive is a lot higher than the one from regular HDD, though this has fortunately improved in recent years, when using reputable brands.

If one were to consider that every single punctual failure of an USB Flash drive, that occurred while using a specific application, was indicative of an issue with that application, then nobody would publish any application that may write to flash drives, including OS manufacturers like Apple or Microsoft. Because, no matter what you do, the rate of failure of USB Flash Drives is just much higher than with other media (again, especially when using cheap drives as these would tend to use the type of flash memory that has the lowest life expectancy), and users of your application or your OS will definitely happen to see flash drives failing at a much higher rate than they would see HDDs or SSDs (since SSDs tend to use more reliable memory than thumb drives).

So, unless you do see consistent failures of flash drives while using Rufus, it's difficult to receive your issue as indicative of an application issue. As I said, I definitely expect tens of people to be able to report that they experienced a failed USB drive while using Rufus each month. But I also expect exactly the same percentage of people to report a USB drive failure when simply using Windows File Explorer or another application to copy files.

I don't have the flashdrive now, as I threw it somewhere I don't remember. Therefore I cannot generate any diagnostic details/logs you would want to investigate.

That's fine. I think you probably could have RMA'd your drive as SanDisk tend to provide a fair amount of warranty, but that was your call.

As to the log, what I'm really after is the log at the time of failure, just as OP provided. Even if Rufus failed to complete its task, you can always click on the Log button and then post that log. If we could get a bunch of such log, I may have a better time convincing people that what they are observing is the expected rate of failure, by showing that there's no real common denominator between these logs.

If you are willing to acknowledge incidents like this

I am willing, if people also acknowledge that USB flash drives do fail, at a much higher rate than other storage devices, and that the occasional single drive failure is by no means indicative of an application issue, __unless__ it happens to consistently affect a very large number of people, including people who use Rufus on a daily basis, power users who are aware of flash drive reliability and can easily determine whether an application like Rufus appears to destroy drives at a higher rate than Windows File Explorer, and so on. As I said, I do expect tens of people every month to be able to report that their USB Flash Drive will have failed while using Rufus, as part of the regular wear and tear one does expect from using such devices. But I also expect any of these people to not see any more failure (unless they are very unlucky) if they switch to using a brand new drive, or a drive from a different batch, which, for instance, is exactly what OP saw. Now, if that can be confirmed to not being the case, I am interested. But then I'll expect that the first people affected will be the small shops and power users who use Rufus on a daily basis, and have a bunch of drives lying around... which have been way too silent on the matter so far for me not to __deduce__ that, along with the impossibility that is having Windows WriteFile() sending the kind of destructive command to flash drives that non programmers imagine it can, what people have been experiencing so far is entirely external to Rufus.

please do make it easy for people like me with no knowledge about USB to report such incidents.

Well, if you create a new issue, you will get a very clear checklist (github auto-template) of what you should do to help troubleshoot a problem, including a super explicit request to please please please paste the __full__ log from Rufus. Now, the problem is, when people simply piggyback on an issue they don't see the checklist, so they don't provide the data that is needed. For the record, piggybacking on an issue is usually a bad idea: "Me too" posts are a lot less helpful than creating a new issue, as doing so makes it a lot easier to determine if the issue is really the same or not. For instance, I'd expect most people to title the issue with the error they got from Rufus, which would already provide a good indication of whether the drive failed at the same stage. And if one pastes the log as requested, I don't even need to ask for manufacturer and model, as I can get it from there, as well as other insightful details.

In summary, by all means, if you do see consistent failures when using Rufus with multiple drives, you should create a new issue and follow the check list (as well as please try to properly check the reliability of any new drive you are planning to use). But if you only experienced a one-of failure, I'm not going to do much about your report, besides advising you to maybe try to see if you can recover your drive using Linux, or any other advice that will seem pertinent according to the data I'm seeing from the log.

pbatard picture pbatard on 18 Aug 2017

I did not want to open a new issue as i was not aware this had happened when this key was created and hence don't have that log. I wrote a Linux image to an 8GB USB key in windows 10 and now the key is write protected. I am using rufus-2.6 and a SMART Modular Technologies USB key model: SH9FLAMKS. This is far from a cheap key, you may find it hard to find info on them as they are vendor supplied keys for doing IBM Mainframe HMC backups, i have never seen one fail short of being stepped on... I cant format it or do anything other than read from it now.

Edit:
The only other thing i can think may be useful is rufus downloaded syslinux-6.03 20151222 to create the key. Here are the logs for when i try and use rufus with it now:

Rufus version: 2.6.818
Windows version: Windows 10 64-bit (Build 14393)
Syslinux versions: 4.07/2013-07-25, 6.03/2014-10-06
Grub versions: 0.4.6a, 2.02~beta2
Locale ID: 0x0409
Found USB 2.0 device 'SMART USB 8GB 3 USB Device' (0E39:1014)
NOTE: This device is an USB 3.0 device operating at lower speed...
Using autorun.inf label for drive N: 'Ubuntu-Server 16.04.3 LTS amd64'
1 device found
Disk type: Removable, Sector Size: 512 bytes
Cylinders: 962, TracksPerCylinder: 255, SectorsPerTrack: 63
Partition type: GPT, NB Partitions: 1
Disk GUID: {16093ABF-C7DE-419E-B02C-38E50F1EA851}
Max parts: 128, Start Offset: 17408, Usable = 7918811648 bytes
Partition 1:
  Type: {EBD0A0A2-B9E5-4433-87C0-68B6B72699C7}
  Name: 'Microsoft Basic Data'
  ID: {374C2E48-0E94-4047-B5D4-FF84A8019878}
  Size: 7.4 GB (7917780480 bytes)
  Start Sector: 2048, Attributes: 0x0000000000000000
Scanning image...
ISO analysis:
  Image is an ISO9660 image
  Will use '/isolinux/isolinux.cfg' for Syslinux
  Detected Syslinux version: 6.03/20151222 (from '/isolinux/isolinux.bin')
Could not get ISO-9660 file information for file boot/grub/i386-pc/normal.mod
  Could not read Grub version from 'boot/grub/i386-pc/normal.mod'
  Could not detect Grub version
Disk image analysis:
  Image has an unknown Master Boot Record
  Image is a bootable disk image
ISO label: 'Ubuntu-Server 16.04.3 LTS amd64'
  Size: 865075200 bytes
  Has a >64 chars filename: Yes
  Has Symlinks: Yes
  Has a >4GB file: No
  Uses Bootmgr: No
  Uses EFI: Yes
  Uses Grub 2: No
  Uses Grub4DOS: No
  Uses isolinux: Yes (6.03)
  Uses KolibriOS: No
  Uses ReactOS: No
  Uses WinPE: No
Using image: ubuntu-16.04.3-server-amd64.iso
Will reuse 'ldlinux.sys' and 'ldlinux.bss' from './rufus_files/rufus_files/syslinux-6.03/20151222/' for Syslinux installation

Format operation started
Requesting disk access...
Opened drive \\.\PHYSICALDRIVE2 for write access
Will use 'N:' as volume mountpoint
I/O boundary checks disabled
Analyzing existing boot records...
Drive has a Zeroed Master Boot Record
Volume has an unknown Partition Boot Record
Deleting partitions...
Could not delete drive layout: [0x0000045D] The request could not be performed because of an I/O device error.
Could not reset partitions
Re-mounted volume as 'N:' after error

Found USB 2.0 device 'SMART USB 8GB 3 USB Device' (0E39:1014)
NOTE: This device is an USB 3.0 device operating at lower speed...
Using autorun.inf label for drive N: 'Ubuntu-Server 16.04.3 LTS amd64'
1 device found
Disk type: Removable, Sector Size: 512 bytes
Cylinders: 962, TracksPerCylinder: 255, SectorsPerTrack: 63
Partition type: GPT, NB Partitions: 1
Disk GUID: {16093ABF-C7DE-419E-B02C-38E50F1EA851}
Max parts: 128, Start Offset: 17408, Usable = 7918811648 bytes
Partition 1:
  Type: {EBD0A0A2-B9E5-4433-87C0-68B6B72699C7}
  Name: 'Microsoft Basic Data'
  ID: {374C2E48-0E94-4047-B5D4-FF84A8019878}
  Size: 7.4 GB (7917780480 bytes)
  Start Sector: 2048, Attributes: 0x0000000000000000
Found USB 2.0 device 'SMART USB 8GB 3 USB Device' (0E39:1014)
NOTE: This device is an USB 3.0 device operating at lower speed...
Using autorun.inf label for drive N: 'Ubuntu-Server 16.04.3 LTS amd64'
1 device found
Disk type: Removable, Sector Size: 512 bytes
Cylinders: 962, TracksPerCylinder: 255, SectorsPerTrack: 63
Partition type: GPT, NB Partitions: 1
Disk GUID: {16093ABF-C7DE-419E-B02C-38E50F1EA851}
Max parts: 128, Start Offset: 17408, Usable = 7918811648 bytes
Partition 1:
  Type: {EBD0A0A2-B9E5-4433-87C0-68B6B72699C7}
  Name: 'Microsoft Basic Data'
  ID: {374C2E48-0E94-4047-B5D4-FF84A8019878}
  Size: 7.4 GB (7917780480 bytes)
  Start Sector: 2048, Attributes: 0x0000000000000000
83nf15h picture 83nf15h on 26 Aug 2017

@83nf15h

What happens if you try to repartition the key in Linux? Can you also try to zero it there (dd if=/dev/zero of=/dev/sd# bs=4M where # is the letter for your USB device — be mindful that this command could zero your other disk devices if you are not careful, so please, if you're not familiar with Linux, double check that the /dev/sd# device you use is really your USB target, and not another disk).

Also, I'm seeing that this device is USB 3.0, but Rufus indicates that it's operating at lower speed. Are you using any extension cables at all? Please be mindful that USB 3.0 is very sensitive to using extension cables, and I've seen I/O errors being generated when people used cables that were either of poor quality, or that had degraded over time.

pbatard picture pbatard on 26 Aug 2017

I should also point out that the version of Rufus you use is very old. Please make sure you try with version 2.16, in case you are simply hitting an issue that was fixed or for which there exists a workaround (such as another application keeping a lock to the drive an preventing access, which Rufus 2.16 will be more verbose about).

pbatard picture pbatard on 26 Aug 2017

When trying to partition in Linux i get dd: failed to open '/dev/sdb1' : read-only file system When i made the key initially i did use a front USB port so there was an expansion cable of sorts but i have not had any issues in the past. I have tried with it directly attached now but it seems that once it is read only it is not going to be simple... or maybe possible at all to get it back!

As for the second part that was human error on my part, i thought 2.6 was newer but i am thinking now its 2.06 not 2.6... Goes to should you should clean out your downloads folder! When i try with 2.16 i do get a different error the first time and i get this same error on multiple PCs "The device is in use by another process. Please close any process that may be accessing the device. C:Windowsexplorer.exe (r)" I assume this is because of autostart as when i try again shortly after i get the usual IO error.

Rufus version: 2.16.1170
Windows version: Windows 10 64-bit (Build 14393)
Syslinux versions: 4.07/2013-07-25, 6.03/2014-10-06
Grub versions: 0.4.6a, 2.02
System locale ID: 0x0409
Will use default UI locale 0x0409
SetLGP: Successfully set NoDriveTypeAutorun policy to 0x0000009E
Localization set to 'en-US'
Found non-USB removable device 'C300-CTFDDAC128MAG' => Eliminated
Found non-USB removable device 'Corsair Force GS' => Eliminated
0 devices found
Found non-USB removable device 'C300-CTFDDAC128MAG' => Eliminated
Found non-USB removable device 'Corsair Force GS' => Eliminated
Found USB 2.0 device 'SMART USB 8GB 3 USB Device' (0E39:1014)
NOTE: This device is an USB 3.0 device operating at lower speed...
Using autorun.inf label for drive N: 'Ubuntu-Server 16.04.3 LTS amd64'
1 device found
Disk type: Removable, Sector Size: 512 bytes
Cylinders: 962, TracksPerCylinder: 255, SectorsPerTrack: 63
Partition type: GPT, NB Partitions: 1
Disk GUID: {16093ABF-C7DE-419E-B02C-38E50F1EA851}
Max parts: 128, Start Offset: 17408, Usable = 7918811648 bytes
Partition 1:
  Type: {EBD0A0A2-B9E5-4433-87C0-68B6B72699C7}
  Name: 'Microsoft Basic Data'
  ID: {374C2E48-0E94-4047-B5D4-FF84A8019878}
  Size: 7.4 GB (7917780480 bytes)
  Start Sector: 2048, Attributes: 0x0000000000000000

Format operation started
Requesting disk access...
Opened \\.\PHYSICALDRIVE2 for exclusive write access
Requesting lock...
Will use 'N:' as volume mountpoint
I/O boundary checks disabled
Requesting lock...
Analyzing existing boot records...
Drive has a Zeroed Master Boot Record
Volume has an unknown Partition Boot Record
Clearing MBR/PBR/GPT structures...
Erasing 128 sectors
write_sectors: Write error [0x0000045D] The request could not be performed because of an I/O device error.
  StartSector: 0x00000000, nSectors: 0x1, SectorSize: 0x200
Could not reset partitions
Re-mounted volume as 'N:' after error

Found non-USB removable device 'C300-CTFDDAC128MAG' => Eliminated
Found non-USB removable device 'Corsair Force GS' => Eliminated
Found USB 2.0 device 'SMART USB 8GB 3 USB Device' (0E39:1014)
NOTE: This device is an USB 3.0 device operating at lower speed...
Using autorun.inf label for drive N: 'Ubuntu-Server 16.04.3 LTS amd64'
1 device found
Disk type: Removable, Sector Size: 512 bytes
Cylinders: 962, TracksPerCylinder: 255, SectorsPerTrack: 63
Partition type: GPT, NB Partitions: 1
Disk GUID: {16093ABF-C7DE-419E-B02C-38E50F1EA851}
Max parts: 128, Start Offset: 17408, Usable = 7918811648 bytes
Partition 1:
  Type: {EBD0A0A2-B9E5-4433-87C0-68B6B72699C7}
  Name: 'Microsoft Basic Data'
  ID: {374C2E48-0E94-4047-B5D4-FF84A8019878}
  Size: 7.4 GB (7917780480 bytes)
  Start Sector: 2048, Attributes: 0x0000000000000000

Format operation started
Requesting disk access...
Opened \\.\PHYSICALDRIVE2 for exclusive write access
Requesting lock...
Will use 'N:' as volume mountpoint
I/O boundary checks disabled
Requesting lock...
Analyzing existing boot records...
Drive has a Zeroed Master Boot Record
Volume has an unknown Partition Boot Record
Clearing MBR/PBR/GPT structures...
Erasing 128 sectors
write_sectors: Write error [0x0000045D] The request could not be performed because of an I/O device error.
  StartSector: 0x00000000, nSectors: 0x1, SectorSize: 0x200
Could not reset partitions
Re-mounted volume as 'N:' after error

Found non-USB removable device 'C300-CTFDDAC128MAG' => Eliminated
Found non-USB removable device 'Corsair Force GS' => Eliminated
Found USB 2.0 device 'SMART USB 8GB 3 USB Device' (0E39:1014)
NOTE: This device is an USB 3.0 device operating at lower speed...
Using autorun.inf label for drive N: 'Ubuntu-Server 16.04.3 LTS amd64'
1 device found
Disk type: Removable, Sector Size: 512 bytes
Cylinders: 962, TracksPerCylinder: 255, SectorsPerTrack: 63
Partition type: GPT, NB Partitions: 1
Disk GUID: {16093ABF-C7DE-419E-B02C-38E50F1EA851}
Max parts: 128, Start Offset: 17408, Usable = 7918811648 bytes
Partition 1:
  Type: {EBD0A0A2-B9E5-4433-87C0-68B6B72699C7}
  Name: 'Microsoft Basic Data'
  ID: {374C2E48-0E94-4047-B5D4-FF84A8019878}
  Size: 7.4 GB (7917780480 bytes)
  Start Sector: 2048, Attributes: 0x0000000000000000

Edit: Thanks for fixing the formatting :)

83nf15h picture 83nf15h on 26 Aug 2017

When trying to partition in Linux i get dd: failed to open '/dev/sdb1' : read-only file system

Then this means that the flash memory is most certainly defective, which the flash memory controller on the drive detected, and as a result, toggled your drive to read-only so that you can at least attempt to retrieve data from the drive.

What most people don't seem to realize is that there is internal logic, on most flash drives, that attempts to detect when the memory goes defective. In some flash drives, the end result might be that the controller simply decides that the memory is no longer accessible, in which case you may see a message about media being missing (mostly because manufacturers tend to use similar internal firmware for card-readers and flash drives). In others, like yours, the controller will try to give you a chance to read data, by switching the drive to read-only.

At any rate, I can guarantee that even a super buggy Rufus has absolutely no way of triggering this internal behaviour from flash drive controllers. As you can see from testing on Linux, the read-only behaviour is something that is internal to the drive, and not linked to the OS or application being used. And there is no set of commands, that can be sent over the USB bus, when accessing a drive in Mass Storage mode, that'll tell a flash drive controller to switch to read-only. This is pretty much what I tried to explain above: unless Windows or the flash drive firmware, or most likely both, have a __major__ bug, there is zero possibility that Rufus can send anything but Mass Storage or USB descriptor retrieval commands (again, none of which are being built or decided by Rufus itself), which are a well defined type of USB transfers and unable to conflict with or be misinterpreted as a __potential__ Vendor Command that __may__ (because there's not even any guarantee that such commands exist in the first place, as it's up to the manufacturer to implement these, and, even if they are implemented each manufacturer will use completely different and incompatible command from the next) exist, as a hidden feature, for a specific flash drive.

So, the most likely scenario is:

  1. While Rufus was writing a large amount of data to the drive, the firmware controller on the flash drive detected that the flash memory was defective
  2. In order to feed that issue back to the user, as well as give them a chance to recover their data, the controller switched the drive to read-only.
  3. From that moment, Rufus, Windows and Linux are not able to perform any writes to it.

or maybe possible at all to get it back!

Depending on your manufacturer, your drive, and, more importantly, "luck", you may be able to get your hand on a vendor-specific tool, that'll send a very proprietary set of vendor commands to the drive and tell the firmware to un-toggle the read-only flag. I would usually advise against this, as the flash memory is likely to fail again and at the very least, you should run a bad blocks check before you attempt to use the drive again, since it's easy to think your drive was "recovered", when the underlying issue is that it'll only look this way until you happen to write to the defective region of flash memory... which, because it is not mapped to a permanent sector on the drive, in order to reduce wear and tear, has most likely moved to a completely different sector from the one it was mapped to when it failed.

What this means is that, you might be able to "get it back", but it'll probably only be a matter of time until it fails again, and the first thing you should do on a "recovered" drive is run a thorough bad block check.

pbatard picture pbatard on 26 Aug 2017

I just used Rufus for the first time, and it seems to have worked fine. Nevertheless, I wound up reading this forum for some reason, and found it to be one of the most interesting, entertaining, and educational pieces of its type I've ever read. Thanks.

PhoebeAnn picture PhoebeAnn on 27 Aug 2017

I just stumbled across this forum and made an account because two of my USB drives, which worked perfectly, are now stuck in write only after using Rufus with them.

I didn't check to grab the logs at the time, and I'm extremely wary to risk ruining another drive by using Rufus.

Honestly, pbatard, I'm very disappointed with how you're responding to the community here. I even made an account to comment on it.

Several people have lost use of their devices after using their product. Rather than insist everyone coming here must have faulty or "fake" hardware, perhaps acknowledge that there could be an issue that needs fixing with your software?

mrwally picture mrwally on 20 Sep 2017

perhaps acknowledge that there could be an issue that needs fixing with your software?

You're free not to believe my very logical and detailed explanation as to why it is simply just not possible for Rufus to destroy flash drives. However, that doesn't make it any less valid.

Again, I'm very open to detailed reports from manufacturers, developers or power users who have some knowledge of how USB Flash Drives are designed (and how Windows actually accesses them), that provide some evidence that Rufus does have an issue.

And again, in case you all wonder, I am eating my own dog food here, and I use Rufus more or less on a daily basis, in various environments, to test new ISOs and/or features. Yet, I am not sitting on a stack of dead drives, which makes it __exceedingly__ difficult to, first, give much credit to the idea that Rufus damages drive, and second, try to come up with a plausible scenario where damage could be incurred by Rufus. I already went through a description of how Rufus accesses flash drives, which, in case you didn't realize it, stands for a code review of trying to ascertain how Rufus "could" damage drives. And this code review hasn't yielded anything that could explain the alleged behaviour.

So, if you are annoyed that the only response you get from me is _"That simply cannot happen, because of X, Y and Z"_, you'll just have to do a bit better than reply _"It so can!"_. I provided some details about how Rufus actually accesses drives, and how it doesn't send any direct commands on the USB bus, or anything that could be construed as such through the Windows Hardware Abstraction Layer and the Mass Storage protocol. Thus, if you want to make this "issue" progress, you'll have to come up with technical feedback from experts, because I've already provided mine.

pbatard picture pbatard on 20 Sep 2017

How To Disable Write Protection from a USB Key 😄

Sopor picture Sopor on 20 Sep 2017

@Sopor- this works for me. Thanks. :)

Taihai picture Taihai on 13 Nov 2017

Some cheap USB sticks fail when their internal memory chips cannot be written. The internal controller chip switches to read-only mode so that you can rescue files that you had in the stick, and copy them to another drive.

Some cheap USB sticks fail when their internal controller chip cannot communicate with their internal memory chips. The internal controller chip reports no media. You cannot rescue your files unless you're the manufacturer or if you have special tools that the manufacturer is supposed to use for their own purposes.

Now, here's my guess about why Rufus and Etcher have a disproportionately large frequency of encountering these errors.

People use Rufus and Etcher to write several gigabytes in a short time.

I bet the internal electronics overheat in cheap USB sticks.

nxdiamond picture nxdiamond on 2 Sep 2018

...so plug the cheap USB stick into a short extension cable, put it in a plastic bag, and drop it into an ice bucket.

PhoebeAnn picture PhoebeAnn on 2 Sep 2018

I don't think an ice bucket would suffice. When the stick's outer case is made of plastic and there's an air gap between the chips and the case, I think they do a good job of insulating.

I have one USB stick whose outer case is made of metal. I don't know if that's enough to keep the internal electronics cool though. I haven't tried writing several gigabytes in a short time to it.

Maybe we can suggest that anyone who has a reason for using Rufus or Etcher should buy a new USB stick with a good warranty, and use the warranty when the stick dies. Don't put important files on the same USB stick as the OS.

Last night I figured out a possible workaround, but I have mixed feelings. Application software shouldn't have to cover hardware manufacturers' asses, but innocent bystanders would benefit if their USB sticks don't die. Maybe write chunks of 10MB at a time, and wait 2 seconds after each 10MB.

nxdiamond picture nxdiamond on 3 Sep 2018

I tried rufus with 2 of my USB drives. One was HP and another Sandisk, so not cheap really. I was writing an ISO of Ubuntu. Both of my drives ended up being readonly. They were both fine before. Now I am searching how to recover the drives and landed on this issue.

AbhishekTripathi picture AbhishekTripathi on 21 Nov 2018

0$417. Yesterday I had a 2-month-old USB stick start reporting "no media" so today I bought one of the non-cheap brands you mentioned.

If yours converted to readonly then you can copy your existing data off of it. I can't because mine reports "no media". Fortunately I was using mine as a backup and I still had another backup at hand so I could copy from my other backup onto my new backup.

By the way if your USB sticks are less than a year old you can probably return them under warranty. Please do.

nxdiamond picture nxdiamond on 21 Nov 2018

0$417. Yesterday I had a 2-month-old USB stick start reporting "no media" so today I bought one of the non-cheap brands you mentioned.

If yours converted to readonly then you can copy your existing data off of it. I can't because mine reports "no media". Fortunately I was using mine as a backup and I still had another backup at hand so I could copy from my other backup onto my new backup.

I had removed the files already from the drive. There is nothing to backup and no file is lost but the usbstick itself is rendered useless. Almost all different ways mentioned on internet has been applied but so far haven't been able to recover either of my sticks.

AbhishekTripathi picture AbhishekTripathi on 21 Nov 2018

Below is the log after 5 minutes. This can continue for another hour.

Rufus version: 3.3.1400 (Portable)
Windows version: Windows 10 64-bit (Build 17134)
Syslinux versions: 4.07/2013-07-25, 6.03/2014-10-06
Grub versions: 0.4.6a, 2.02
System locale ID: 0x0809
Will use default UI locale 0x0809
SetLGP: Successfully set NoDriveTypeAutorun policy to 0x0000009E
Localization set to 'en-US'
0 devices found
Found USB 2.0 device 'SanDisk Cruzer Edge USB Device' (0781:556B)
1 device found
Disk type: Removable, Disk size: 7.8GB, Sector size: 512 bytes
Cylinders: 943, Tracks per cylinder: 255, Sectors per track: 63
Partition type: MBR, NB Partitions: 1
Disk ID: 0x001608B7
Drive has a Rufus Master Boot Record
Partition 1:
  Type: NTFS (0x07)
  Size: 7.2 GB (7759986688 bytes)
  Start Sector: 2048, Boot: Yes
Drive has a Rufus Master Boot Record

Format operation started
Requesting disk access...
Opened \\.\PHYSICALDRIVE1 for exclusive write access
Requesting lock...
Will use 'F:' as volume mountpoint
I/O boundary checks disabled
Requesting lock...
Analyzing existing boot records...
Drive has a Rufus Master Boot Record
Volume has an unknown Partition Boot Record
Clearing MBR/PBR/GPT structures...
Erasing 128 sectors
write_sectors: Write error [0x00000079] The semaphore timeout period has expired.
  StartSector: 0x00000000, nSectors: 0x1, SectorSize: 0x200
Retrying in 5 seconds...
AbhishekTripathi picture AbhishekTripathi on 21 Nov 2018

I just used Rufus for the first time, and it seems to have worked fine. Nevertheless, I wound up reading this forum for some reason, and found it to be one of the most interesting, entertaining, and educational pieces of its type I've ever read. Thanks.

Same. It seems people fail to realize that transfering a rather large amount of data in a short time can brick their cheap usb devices. I am amazed at how logic and calm pbatard handles these issues, even though he is doing this all for the community and not getting paid for it.

Clausinho picture Clausinho on 14 Dec 2018

Looks like the issue did start from Rufus. I had both thumb drive write protected. Though I appreciate the free software but it causes more problems. The software should probably be taken down in order not to brick any more thumb drive.

elnoxvie picture elnoxvie on 15 Dec 2018

@elnoxvie, you do understand that what you report is what one can expect to happen when using fake drives (i.e. USB flash drives that have had their firmware modified to pretend they have more capacity than they really have).

Hundreds of millions of people, who aren't taking to the internet to demand that the software be taken down, are proving, day after day, that Rufus does not brick drives.

So I'm afraid a handful of reports, provided by people who, and if you want to dispute that assertion, I'll be very happy to have you post to demonstrate otherwise, don't seem to understand how writing to an USB works in Windows, and who haven't started to provide even the beginning of and explanation as to how Rufus could damage drives (whereas I have repeatedly tried to demonstrate, technically, how it cannot), are simply not going to cut it.

From now on, the __only__ replies I will accept on this thread are ones that contain some technical details. So, as I already __repeatedly__ asked folks who believe that Rufus has a bug that bricks drives to do, please get in touch with the manufacturer of the drive so that they replicate the issue, and then have them post technical findings that disprove the ones I provided earlier. Surely, if there is software that causes drives to be RMA'd, they should be more than happy to demonstrate that said software has a flaw so that they don't have to spend their money on RMA. But of course, the fact that, after years of _"But Rufus so has a bug that destroys drives"_ posts, there still hasn't been a single flash drive manufacturer out there who posted anything on this _allegedly_ blatant issue with the software is __clear evidence__ that, contrary to what some people here still want to believe, whatever caused some drives to be bricked had nothing to do with Rufus (such as, for instance, unknowingly having purchased a bunch of cheap "fake" drives, that __WILL__ get bricked as soon as you write more data on them than they actually can hold).

pbatard picture pbatard on 15 Dec 2018

Hey, if they are enough report, Why are you denying it so hard. When unetbootin or others don't generate such issues. It must be the method that you used is not safe. It is not like the incident happened on one memory card only but two. Maybe I got unlucky. Just trying to highlight to people the method you used in Rufus is unsafe and could trigger the write protected.

Given how many of such issues have been submitted, it should be at least a good indication that the software has bugs. As a developer myself, I am actually being polite here.

Sorry for my ranting but people please keep away from Rufus for now if you don't want your thumbdrive getting write protected and probably irreversible process.

elnoxvie picture elnoxvie on 16 Dec 2018

"you do understand that what you report is what one can expect to happen when using fake drives"

No, fake and modified drives are not this problem. Cheap design and inadequate testing by genuine manufacturers is the problem. Writing 2GB of data at USB3 speed can overheat the internal electronics of a poorly designed flash drive.

Mr. Batard it is not your fault. It happens to you a lot because your program writes 2GB of data at USB3 speed. Or if someone's writing a Windows ISO then your program writes 4GB of data at USB3 speed.

I've returned around 5 USB drives during the past 3 months. One time a store employee took photos of his PC's Windows screen reproducing the failure, and phoned the Japanese distributor of the USB sticks (the same distributor handles at least two internationally famous Taiwanese brands).

nxdiamond picture nxdiamond on 16 Dec 2018

@elnoxvie, I'm seeing a lot of issues with write protected drives that have nothing to do with Rufus on superuser. So clearly, as opposed to what you stated, __other applications and usage__ do generate these issues as well...

Also, as I've explained in earlier comments, your _"how many such issues have been submitted"_ is pretty much what I'd expect from __coincidental__ failures from a software that is downloaded more than 3 million times every month (which, I suspect, is likely to be a lot more than unetbootin). In fact, given the amount of fake drives that I know are being sold to unsuspecting users, as well as some known occurrences of flash drives (e.g. some PNY models) having firmware issues that will cause them to fail, I am pretty confident that the amount of "your software killed my drive" reports I am getting on this issue tracker or elsewhere, is actually quite low considering the amount of people who must be using Rufus with fake/low-quality/problematic drives, and __BELIEVE__ that because their hardware happened to fail while they were using it with Rufus, then Rufus must be the issue...

Also, since you're a developer, then please feel free to poke holes in my previous explanation that, no, even if it had a major bug, Rufus can absolutely not damage an USB drive, unless the Windows API and the Hardware Abstraction Layer also have a major bug. There's really no in-between here: Either my explanation is correct, and therefore there's __ZERO__ possibility that Rufus can send the alleged "self-destruct" command that a handful of very vocal people, who don't seem to understand how partitioning/formatting/file-copying onto an USB drive work, are desperately trying to put forward. Or, my explanation is wrong, in which case it should be exceedingly easy, for a developer with some knowledge of the Windows APIs as well as USB Mass Storage, to disprove it, even more so as the whole source code of Rufus is also easily accessible.

TL;DR: When there exist hundreds of millions of people using a software, then it is completely expected that a handful of people out of these millions users will experience coincidental failures, that have nothing to do with said software (yes, even on multiple drives, which can be explained by fake/low-quality/buggy-firmware, all of which are real hardware issues that there exist numerous examples of), and that they will be inclined, sometimes very vocally, to want to point the finger at the software. Yet, if that handful of user reports is all the "evidence" there exist, then, as much as the people who experience the failures would like to pretend otherwise, these reports are still dramatically inadequate to be accepted as "evidence", even more so if none of these reports are able to provide any detailed technical data that can disprove the "coincidental failure" factor.

pbatard picture pbatard on 16 Dec 2018

The Windows API and HAL (and, more importantly, drivers) can't damage a USB drive that way either. The drive damages itself because of poor design by manufacturers.

nxdiamond picture nxdiamond on 16 Dec 2018

@pbatard Well let me put it in this perspective.

Few days ago, i used the 4gb sand disk cruzer. (SDCZ36-004G) and create a bootable disk using etcher. It's works fine.

And just yesterday, i tried using rufus to create a bootable, gpt-uefi and it works. files are intact but not bootable, immediately i tried to reflash it another time and got the write protected issue.

Note: both memory card contains no bad sector after running a disk check.

on the same day, i used my sandisk microsdxc 16gb and format it with rufus, same thing happened. It got write protected. I understand they are other factors that could cause the drive to malfunction, such as usb driver in the OS or poor usb drive, usb electricity or fake usb drive.

so let's look at certain scenario.
1st. i believe both my memory card are from reputable company and bought from local reputable shop so this shouldn't be counted as the root cause.
2nd. etcher and rufus are both of the same nature but etcher didn't cause such issue to occur but rufus did. Presumably, there are certain codes in rufus aren't safe enough for certain drive to work coupled with multiple external factors, bad usb plug(PC drive), bad sectors etc either of these triggered such issues.
3rd. i also suspect the issue were caused partially by bad usb panels from those desktop cases. (yes i used a diy computer with cooler master cases) and drive were plugged in usb on the front panel during formatting. It may be caused by bad or cheap usb panel. If this is an issue, maybe there are room for improvement for rufus whereby it could imitate other software such as unetbootin or etcher as not to trigger such issue.

It would be good to provide an alternative way of writing the files to the usb. Presumably if the root cause were the codes that tried to achieve high speed transfer then maybe a safe method could be made available. ( just a speculation).

What i theorize is rufus achieved amazing speed with some low level api that may trigger such issues to happen. Of course, this is just my speculation and the issues here is beyond my knowledge to investigate.

anyway, i am grateful for the free software and I want rufus to success but the problem here is severe enough since this write protected seems to be irreversible process so it would be good to spend sometime to investigate on the issue.

if you need user's help, i believe we will more than willing to lend a hand to provide logs or os specs etc.

Thank you for listening.

elnoxvie picture elnoxvie on 16 Dec 2018

and got the write protected issue.

both memory card contains no bad sector after running a disk check.

Hold on. If you ran the bad block check __after__ you got the drive write protected, then clearly the drive is not write protected, since you can not validate that a drive is fine without writing each individual block (which is the whole idea behind a bad block check).

1st. i believe both my memory card are from reputable company and bought from local reputable shop so this shouldn't be counted as the root cause.

You'd be surprised at how far bad or flaky hardware manages to make it up the "reputable store" chain. At the end of the day, people who distribute flaky hardware always manage to undercut the pricing of people who distribute reputable one (since they don't have to care about quality), and obviously, since the retailer's goal is to maximize their profit, they tend to go with the cheapest bulk offer, especially as it's impossible for a retailer to validate the quality of all the products they resell.

In other words, if you want to theorize that your hardware was fine without having any means of providing concrete evidence (result of a bad block check ran __before__ you used the drive), don't be surprised if I theorize that your hardware wasn't that fine.

2nd. etcher and rufus are both of the same nature but etcher didn't cause such issue to occur but rufus did.

Etcher is a 'dd' writer. Rufus isn't. That's why for instance Etcher is hopeless for writing Windows ISOs. So you're wrong in your assumption that Etcher and Rufus are of the same nature. Also, __punctual__ evidence that Etcher worked where Rufus failed is hard to see as anything but coincidental occurrence, especially as one is copying blocks and the other is copying files. A much more meaningful test, if you want to assert that Rufus destroys drives where Etcher doesn't is make sure that you use the same image in both cases, and also make sure that, when Rufus prompts you, you select 'DD mode' and not the default 'ISO mode'. Then you will have software performing operations that are of the same nature. Also, make sure you do that from 2 different computers, as I could bring up flaky extension cables or bad connections as the reason for the failure when using Rufus, especially when working with USB 3.0 hardware, which is sensitive to bad connection and interferences.

Presumably, there are certain codes in rufus aren't safe enough for certain drive to work

Nope.

You know, I am starting to get a bit tired of people, who clearly haven't looked at the code, or who don't have the capacity to understand the code, __ASSUMING__ that Rufus is doing something very hackish when copying files. __THAT IS NOT THE CASE__

We're using CreateFile() and WriteFile(), just like File Explorer does. And we don't apply tricks like running multiple threads in parallel to try to speed things up. Heck, we're not even using OVERLAPPED to run these operations asynchronously. So, when you are accusing Rufus of doing something unsafe, then you are effectively accusing Microsoft of doing something unsafe in their OS, because CreateFile() and WriteFile() are the most basic and common file I/O operations Windows OS is expected to run.

If you believe that there exist ways to use those in a unsafe manner when simply writing files to a drive (which is what Rufus does), then please open an issue with Microsoft, because I'm pretty sure they will be very interested in hearing how these APIs have a major reliability bug, that has gone undetected for 30 years (since that's about how long these APIs, which again are the most basic ones you can use for File I/O, have existed).

3rd. i also suspect the issue were caused partially by bad usb panels from those desktop cases.

Interesting...

whereby it could imitate other software such as unetbootin or etcher as not to trigger such issue.

I believe I already said that elsewhere, but I have __zero__ interest in slowing down operations for everybody, on account of a handful of people using flaky/unreliable hardware. You use bad/flaky hardware, you pay the price. And if, as a result, you want to point the finger at the developer of some software that had nothing to do with it, I guess I'll have no choice but to continue handle that. But I'll also continue to point out that the issue could only have come from the hardware.

It would be good to provide an alternative way of writing the files to the usb.

Brilliant! Now you are effectively asking me to ditch the standard Windows APIs, to hack my own, with all the problems and reliability issues that will incur. Do you want me to write my own OS as well?

What i theorize is rufus achieved amazing speed with some low level api

<sigh>. Please get somebody who understands C and has some level of familiarity with Windows look at the Rufus source (Hint the copying of files is handled in either udf_extract_files() or iso_extract_files() in iso.c).

This _"Rufus must be using some hackish low level tricks"_, which can __EASILY__ be disproved by looking at the source (which again is completely public) has got to stop. Rufus does __NOT__ use any low level API to speed up the copying of files. Rufus does __NOT__ even write individual blocks or send USB commands on its own while copying files. Instead, __ALL__ Rufus does is tell Windows: "Create a file on drive X:" and then "Here, write this data to the file you just created", using the super standard CreateFile() and WriteFile() APIs (which are in effect so limited that you cannot even pass any options that could even be considered dangerous - but there again, feel free to look at the very official documentation and dispute my statement, if you believe that any of the super common options used by Rufus should be considered "unsafe").

since this write protected seems to be irreversible process

What does Linux say about that? I'd really like to see all the people who experience the issue try to recover the drive from another OS. For instance, I know that some ChromeOS images will make Windows go a bit berserk when attempting to repartition the drive (pure Windows bug, for which Rufus actually had to add a workaround), but you can easily recover such a drive from Linux.

if you need user's help, i believe we will more than willing to lend a hand to provide logs or os specs etc.

I __ALWAYS__ expect to see FULL logs from Rufus if you experience any issue. As a matter of fact, I am surprised on how much of the new entries for "Rufus write protected my flash drives" seem __NOT__ to want to provide a log. Surely, if you experienced a failure, and tried with another drive, the first thing you should be cautious to do if you experience a similar failure with that second drive, would be to save the full log, so that you can provide it to the developer of the software you __believe__ is causing the issue. Or maybe that's just me. Heck, almost none of the reports above even provide comprehensive data about the flash drive or memory card that was used (which the Rufus log would provide, especially the VID:PID). I made sure that Rufus could provide a very comprehensive log of its operation, which is also very accessible (just click the last small button left of _START_). Yet, everybody seems to come to this post on the false assumption that this is a super common issue (it isn't), and therefore that they don't need to provide ANY details on the very wrong assumption it should affect such a large number of people that the developer also should have no issue reproducing it.

So let me tell this for all the people who might want to add their own story to this issue: you shouldn't be _"willing to provide logs or specs"_. If you want to add any new data on this issue, then you should provide them from the get go. You should also provide the full details of where exactly you purchased your drive and when. If you are confident that Rufus __is__ the culprit, then you should have the confidence to post all the data required to try to prove it (so that we can isolate bad batches, disreputable stores, cheap drives and so on, which you definitely want to remove as possible factors if you are hell bent on pointing the finger at the software).

pbatard picture pbatard on 16 Dec 2018

Etcher destroyed two of my USB sticks, but it's not the fault of etcher, it's the fault of defecitve makers who don't design or test their USB sticks to prepare for the heat generated when writing 2GB or 4GB at USB3 speed. In the etcher forum I suggested that a favour could be done for victims who buy USB sticks from incompetent manufacturers. Maybe after writing each 100MB of data, pause for 30 seconds to let the USB stick's internal electronics cool down. The maker of etcher doesn't want to do that. Who could blame him? Stupid manufacturers are stupid manufacturers.

nxdiamond picture nxdiamond on 17 Dec 2018

nxdiamond might have something there. Add an optional config parameter to Rufus to add "cooling-off periods" when writing large amounts of data at USB3 speeds. Good luck determining how long and how often these periods should be.

PhoebeAnn picture PhoebeAnn on 17 Dec 2018

Add an optional config parameter to Rufus to add "cooling-off periods" when writing large amounts of data at USB3 speeds.

Nope. Not gonna happen.

First of all, this _"some drives might need cooling off"_ is __complete speculation__ and I don't apply fixes for speculative issues. I apply fixes for actual issues that are attached to complete verifiable technical explanations. Furthermore, even this speculation is assessing that the hypothetical "real" issue has to do with poorly engineered hardware, and not Rufus.

Again, considering that hundred of millions of people have been using Rufus with all sorts of drives and memory cards, including poor quality / overheating ones, and that, when looking at it objectively, one can only conclude that the __exceedingly small amount of users__ that are reporting flash media issues would be called _"statically expected noise"_ in any scientific experiment using the same sample size as the number of usages of Rufus, it is very hard to see any justification for adding a "cooling off" option.

Contrary to what the people who appear to have been affected with the "write only" issue have been trying to assert, this is not a widespread problem. It is the expected noise stemming from a bell curve where the vast majority of people do get drives that are reliable enough to sustain the kind of standard operations that Rufus and other software (including Windows File Explorer) require from the hardware, but a small amount at the low end of the curve don't. I therefore see no reason to try to make unreliable hardware, __that is going to fail one way or another anyway__, fail somewhat later. We're not pining for _"fail better"_ here.

pbatard picture pbatard on 17 Dec 2018

I think hundreds of millions of users is also very speculative. Can you send the data to back that up.

Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows 10

From: Pete Batard notifications@github.com
Sent: Sunday, December 16, 2018 7:47:54 PM
To: pbatard/rufus
Cc: johnheintz; Comment
Subject: Re: [pbatard/rufus] Rufus write-protected my USB drives! (#313)

Add an optional config parameter to Rufus to add "cooling-off periods" when writing large amounts of data at USB3 speeds.

Nope. Not gonna happen.

First of all, this "some drives might need cooling off" is complete speculation and I don't apply fixes for speculative issues. I apply fixes for actual issues that are attached to a complete verifiable technical explanations. Furthermore, even this speculation is assessing that the hypothetical "real" issue has to do with poorly engineered hardware, and not Rufus.

Again, considering that hundred of millions of people have been using Rufus with all sorts of drives and memory cards, including poor quality / overheating ones, and that, when looking at it objectively, one can only conclude that the exceedingly small amount of users that are reporting flash media issues would be called "statically expected noise" in any scientific experiment using the same sample size as the number of usages of Rufus, it is very hard to see any justification for adding a "cooling off" option.

Contrary to what the people who appear to have been affected with the "write only" issue have been trying to assert, this is not a widespread problem. It is the expected noise stemming from a bell curve where the vast majority of people do get drives that are reliable enough to sustain the kind of standard operations that Rufus and other software (including Windows File Explorer) require from the hardware, but a small amount at the low end of the curve don't. I therefore see no reason to try to make unreliable hardware, that is going to fail one way or another anyway, fail somewhat later. We're not pining for "fail better" herehttps://en.wikiquote.org/wiki/Samuel_Beckett#Worstward_Ho_(1983).

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/pbatard/rufus/issues/313#issuecomment-447706535, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AdoduUnFubcoYxr5x0sytg_Z7cpW1siNks5u5wXagaJpZM4Byyzu.

johnheintz picture johnheintz on 17 Dec 2018

I think hundreds of millions of users is also very speculative. Can you send the data to back that up.

Here are the current number of downloads for Rufus 3.4 (which was released 11 days ago):

Rufus-3.4.appx: 1078 downloads
rufus-3.4.exe: 688862 downloads
rufus-3.4p.exe: 255989 downloads
rufus-3.4_arm.exe: 776 downloads
rufus-3.4_arm64.exe: 2004 downloads

__ANYBODY__ can verify these stats, as github lets you see the number of downloads from any project that uses github releases (search for something like gdc), and not just only the owner of that project. This is actually a bit lower than usual due to the fact that the automated update check got broken between 3.3 and 3.4. But even if you don't believe me, with the people who choose to download older releases (not shown in the above) along with people downloading Rufus from unofficial mirrors, you should reasonably consider that Rufus sees at least 3 million downloads/month, or 36 million downloads a year.

Now, it is unlikely that all of these downloads are one time use, so there has to be some >1 factor when estimating the number of uses. And of course, Rufus has not always seen that high a number of downloads, but then again, it has been publicly available since 2012.

I therefore consider a realistic estimate that there has been at least 200 million uses of Rufus. Or hundreds of millions.

pbatard picture pbatard on 17 Dec 2018

@pbatard Well, My suggestion is to put up a list of thumb drives certified to work with rufus. This could prevent users from damaging their so called flaky thumb drive. Plus, it's not like every users know what thumb drive is A OK with rufus or not.

If users were to do a trial and error on their usb thumbdrive ( since the damage is irreversible) and guess what? rufus is to blame.
WHY?
because this only happened after they use rufus. Despite all the technical correctness or claimed by the author or whatsoever. People will look at it that way.

Therefore, a little warning or lists of thumbdrive certified to work would be good. Otherwise, they will risk damaging their little flaky thumb drive.

The certified USB list, could also act as a disclaimer here.

Brilliant! Now you are effectively asking me to ditch the standard Windows APIs, to hack my own, with all the problems and reliability issues that will incur. Do you want me to write my own OS as well?

Woah. hold your horses. I am not implying you to do so. I am just saying there could be a reason why after their formatting using rufus, the issue occur. So maybe, there are issues with methods that were used.

e.q. Rufus used copy files instead of DD and unetbootin using DD only. Thus, something can be implied from there. Maybe copying files at high speed damaged the flaky usb drive.

Anyway, i understand it's not easy to pinpoint the issue here. Maybe you could consider my suggestions above (regarding the usb list) as to avoid users from damaging their so called FLAKY thumb drive.

elnoxvie picture elnoxvie on 17 Dec 2018

@nxdiamond What thumbdrive are you currently using? can you recommend some that you think work well with rufus?

elnoxvie picture elnoxvie on 17 Dec 2018

Maybe copying files at high speed damaged the flaky usb drive.

In that case, you will need to tell people to __NOT__ use Windows File Explorer either, because Rufus does the exact same thing and (unless you have some evidence to demonstrate otherwise), Microsoft does not add "cool down" in File Explorer when detecting a specific set of USB 3.0 drives, or any other drive for that matter.

I am just saying there could be a reason why after their formatting using rufus, the issue occur.

And I have repeatedly tried to provide __evidence__, which nobody seems to want to look at (because God forbid someone backs up their claim with code) why what you assert about the Rufus code doing something "special" that may trigger a hardware failure is bullshit.

lists of thumbdrive certified to work would be good.

Feel free to create a web page with that information.

Or are you expecting the developer to go and buy every flash drive under the sun, and invest a lot of time maintaining the list you suggest. And how about you ask the same for the Etcher or Unetbootin people as well? After all, since we seem to (somewhat) agree that the issue must be tied to the hardware, there's certainly no logical reason not to ask the same from them (unless you want to dispute the earlier report that some people have their drives fail while using Etcher).

Anyway, i understand it's not easy to pinpoint the issue here.

That's because there's no software issue.

Anyone familiar with Windows APIs, the Windows Hardware Abstraction Layer, C, and who has spent a few minutes looking at the file copy code from Rufus __will__ be able to tell you that. But the problem, which seems to be a very general issue today and one that is not limited to only the computing world, is that, as soon as something requires placing some trust in somebody who has expertise you lack (and please understand I'm not talking about myself here - I'm talking about people who are able to validate or invalidate claims made by somebody from the same field), then, in this age of trying to make yourself look smart in a comments' section, it somehow seems to become fair play to consider that expert advice can be bypassed altogether, and that anyone's __non-expert assertion__ should be considered equally valid as the experts'.

When you are familiar with the fields I have mentioned above, it is actually very easy to pinpoint that, logically, the issue cannot be with the software, which, as the software developer, is all I require (as I have no interest in pursuing the matter if I can demonstrate that it has nothing to do with my code). But of course, as soon as you make that claim, you get bombarded with _"oh yeah, like we're going to trust a software developer not to have a vested interest in pretending that their software is not responsible"_. Quite frankly, since this is basically doubting my integrity as a software developer, without being able to bring a shred of evidence why it should be doubted, it is starting to get exceedingly tiresome.

If you want me to lock this thread and prevent anybody from posting any further (which, as you have perhaps failed to notice I have not done in the 4+ years this issue has been opened), as well as shut down any attempts to create a new one (and not give a damn about expected cries of "developer conspiracy" that will result), you are certainly doing a good job...

pbatard picture pbatard on 17 Dec 2018

Or are you expecting the developer to go and buy every flash drive under the sun, and invest a lot of time maintaining the list you suggest. And how about you ask the same for the Etcher or Unetbootin people as well? After all, since we seem to (somewhat) agree that the issue must be tied to the hardware, there's certainly no logical reason not to ask the same from them (unless you want to dispute the earlier report that some people have their drives fail while using Etcher).

Woah. why do you have to imply everything in a negative way? i am saying this can be done via crowd sourcing. Create a wiki page and let people chip in.

In that case, you will need to tell people to NOT use Windows File Explorer either, because Rufus does the exact same thing and (unless you have some evidence to demonstrate otherwise), Microsoft does not add "cool down" in File Explorer when detecting a specific set of USB 3.0 drives, or any other drive for that matter.

True enough but how is that copying via windows file explorer to thumbdrive doesn't cause such issue and only when using rufus, the issue occur. This left me baffled. Just saying.

elnoxvie picture elnoxvie on 17 Dec 2018
👍1

@pbatard Reading back on my previous comments. I kinda feel sorry. Sorry for my earlier remarks on taking down the software. Clearly, i was not thinking clearly and spout some nonsense there. guess, i wasn't thinking rationally as two of my thumb drives just got bricked.

Anyway, hopefully this is as you said the issue with the hardware. Will try rufus again, if i could get my hand on a new thumbdrive under warranty.

Thanks for taking your time to explain the issue.

elnoxvie picture elnoxvie on 17 Dec 2018

"What thumbdrive are you currently using? can you recommend some that you think work well with rufus?"

I don't think it would be fair for me to answer that. For example there is a famous Taiwanese brand that used to make USB 2 flash drives and I never had a problem, but their USB 3 flash drives failed and a retail store let me exchange for other brands. One other Taiwanese brand is less famous, and their USB 3 drives lasted a bit longer before failing, but still failed. The retail store let me exchange one for a third brand (a Japanese brand and I paid the difference in price), and they refunded my money for one because I'd already bought a fourth brand while travelling (a US brand but really made by a Japanese company). I do not know yet if the latest one is going to fail, but someone else reported a failure with the same brand.

I'm going to go out on a limb and speculate that one Japanese brand deliberately limits the speed of their USB 3 flash memories to be about half the speed of the competition, and this might be why they haven't failed on me.

There's another brand of USB 3 flash memory that I've been using for a few years now. This one has a case made of metal instead of plastic. It runs at full USB 3 speed and hasn't failed even after a few years.

So this is why I bet the failures are due to overheating of the internal electronics.

===

"In that case, you will need to tell people to NOT use Windows File Explorer either"

Yes indeed. Using Windows File Explorer in Windows 10, I could pause a copy operation. Every 30 seconds I tried to pause the writing of a bunch of files, wait 30 seconds, and resume. Windows 10 was slow responding to my clicks on the pause button. The USB stick died shortly after that.

nxdiamond picture nxdiamond on 17 Dec 2018

@nxdiamond thanks for the insight.

elnoxvie picture elnoxvie on 17 Dec 2018

Create a wiki page and let people chip in.

Sorry, when it comes to propping software or hardware, I want to provide information that I have verified myself. That's the reason why you don't see a wiki page on ISOs that are compatible with Rufus, because I am confident that, as soon as single person experiences some unrelated issue with an ISO, they will be tempted to make it their life crusade to have that ISO removed from the wiki, even if the issue they had was unrelated. And I'm sure we'd see exactly the same for flash drives (_"I've had a coincidental failure with this flash drive, therefore I feel that I am entitled to say that ALL flash drives of this make should be removed from the list_").

As a matter of fact, what I am highlighting above with __overgeneralization__ is exactly the problem I'd like people who want to post in this thread to be mindful of.

Nobody is denying that you may have seen repeated drive failures while using Rufus, and, of course, everybody understands why it would seem logical to want to point the finger at the software you were using while you experienced these failures (or, even if you agree that the software wasn't directly responsible for these failures, want the software to take into account the possibility of hardware failures occurring while it is writing data). However, you have to be exceedingly careful about trying to generalize an issue you have experienced and promote the idea that, because you have seen it once or twice, under conditions that can't help but have specific components related to your environment, then it can be concluded that it "must" be affecting a significant number of people.

Now, the following is really a rule that I wish everybody who opens an issue in this tracker or contacts me by e-mail would follow, because it doesn't just apply to what we're discussing here:

__Until proven otherwise, you should always assume that you are the ONLY person to experience the problem you report, and therefore ensure that you provide all manner of details, that are specific to your environment, the hardware you used, and the operations you conducted, to the person you report it to; as if the troubleshooting task was to find what, in your specific environment or usage, is the cause of the problem__.

Which brings me nicely to:

how is that copying via windows file explorer to thumbdrive doesn't cause such issue and only when using rufus, the issue occur.

This is the part where you are overgeneralizing and assuming that, because you have seen a problem while using Rufus and not while using File Explorer, there doesn't exist a similar or greater number of people, who aren't using Rufus, and who might have seen their drive fail in the same fashion while using File Explorer. The problem here is that you are not in effect providing a receivable proof that File Explorer is safe whereas Rufus isn't. All you have is punctual evidence that, in your environment, you happen to have seen drives fail while using Rufus, whereas you haven't seen the same while using File Explorer.

Now, if, out of the millions of users who are using Rufus on a daily monthly basis ([EDIT] sorry for the typo that makes it look like I am overgeneralizing myself — I actually meant to write monthly and it doesn't diminish the point I am making anyway), I was seeing a significant number of reports (most of which would be very public, on this issue tracker, or on public forums like superuser), that there exist a large number of drive failures during Rufus usage, then I would take what you highlight above as contributing to undeniable evidence that Rufus is indeed causing drive damage. But the problem is, I am not seeing that at all. In light of that, and in light of the statistical noise that is expected from an application that accesses flash drives of various reliability and that sees high volume usage, I therefore can't help but find your alleged evidence that Rufus is more inclined to cause drive failure than File Explorer, as well as the previous allegations from the 4+ years this issue has been opened, as exceedingly inconclusive. Even more so when I can vouch that the operations that are being conducted when Rufus is copying files have nothing susceptible of causing more drive failures than when using File Explorer.

Sorry for my earlier remarks on taking down the software.

I appreciate that. And please understand that, even though I feel it is my duty to try to dispel the idea that Rufus is causing drive damage, which a stance that some might consider intractable, I can totally understand where you are coming from. But there again, you (and others) need to be mindful of overgeneralizing an issue you have faced, unless you can back up, with concrete evidence, why it should indeed be considered a general problem (which is the precise reason why you'll see me request that people RMA the drives and get in touch with the manufacturer, so that, if the manufacturer has reason to believe the software had any part in the failure, they will be able to provide technical and detailed evidence of it, which will be a lot more receivable than overgeneralized punctual occurrences).

Will try rufus again, if i could get my hand on a new thumbdrive under warranty.

Great. Please make sure that, if you do that, and if you do experience another hardware failure, you do save the full log and provide it to me. Also, please make sure to run a complete bad blocks check on your drive. Note that Rufus can do that as part of its operations (and the nice thing is, if you do it from Rufus, then the result of the bad blocks check will appear in your log), but if you don't trust the bad blocks check from Rufus, you can also use an external application. You can select to run a bad blocks after you click _Show advanced format options_. Note that, if you want to run a comprehensive bad blocks check, you may have to find from the manufacturer of the drive/memory card if the flash memory used is of type MLC, TLC or SLC, so that you select the right option in Rufus. Also note however that a 4 pass bad block check may take a very long time...

pbatard picture pbatard on 17 Dec 2018

Balena destroyed my USB drive ! How to recover?
Etcher is corrupting SD and USB drives
Etcher destroyed 2 of my USB sticks, but I bet it's not etcher's fault
UNetBootin destroying USB drives
USB pen drive not recognized after using UNetbootin

Sopor picture Sopor on 17 Dec 2018

@Sopor- Yeah, for some reason people always jump to immediately blaming the software they were using, rather than their flaky / broken / fake hardware :-/

@pbatard From an ex-Etcher-developer, you have my sympathies!! See also https://github.com/raspberrypi/documentation/issues/1042

lurch picture lurch on 27 Dec 2018

@lurch, thanks for the support. And since you were involved in that project, let me just say that, from what I have seen of it, you guys did a very fine job with Etcher... 👍

And yeah, since it's gotten popular (for good reason) I am statistically expecting Etcher to run into the same kind of user reports that Rufus gets when it comes to people thinking that the application is responsible for whatever drive failure they experienced. So it does feel a bit less lonely to get confirmation that reports of _"Application X killed my drive!!"_ are far from being limited to Rufus.

I also hope that seeing this this will help temper people who are _absolutely certain_ that Rufus (or any other application that writes to flash memory based media for that matter), has the means to destroy their drives...

pbatard picture pbatard on 27 Dec 2018
❤1 👍1

https://github.com/pbatard/rufus/issues/313#issuecomment-322045700

Thanks a lot for your explanation @pbatard! My intention was never to complain about the bug (thought it was a bug from your end), but just to report it and possibly point out if there is a chance the issue is in Rufus and you overlooked it (which looks to be wrong). Looks like I am clearly wrong and sorry to have come off as the end user who just came to the project to complain about it. That was never my intention. Also looking back at the comment, I apologise if the language wasn't decent too!

I've used Rufus before this and after this incident (although to be frank, a bit cautiously after the incident. Which just means fingers-crossed and hope the USB won't get messed up :smile: ) and it has been reliable during the limited instances I've used it. But couldn't fix the broken USB though. Anyways, thanks a lot for your work on this project and I really appreciate it. :)

_If you're ever in Bangalore,India for a tech conference or something, a beer/coffee is on me!_ :beers: :coffee:

unsungNovelty picture unsungNovelty on 28 Dec 2018

Rufus also made useless my 64GB Stellar Flash drive! I didn't save the log and I will not redownload your nefarious software to make a new one. These are most certainly NOT isolated incidents, a simple Google search returns hundreds of results with people looking for help with this exact same scenario on multiple forums! Fix this issue or remove the software! It's that simple!

daddyslittleone picture daddyslittleone on 11 Jan 2019

These are most certainly NOT isolated incidents

As had been previously explained, these incidents fall in the range of __coincidental__ failures one would expect according to how widely software like Rufus and Etcher are used, as well as the prominence of "fake" USBs and so on...

Of course, you're free to reject this explanation. But if you think that there is some kind of major flaw in the software, that is entirely Open Source (and, to be honest, not that complex at all when it comes to writing data to a drive, since Windows severely limits what we can do there) and therefore one where it should be very easy for __any specialist or advanced user__ (such as USB flash drive manufacturers who of course should have a VERY REAL VESTED INTEREST in seeing software that destroys drives be put out of circulation) to point to such flaw, then, after the software developer has repeatedly debunked this possibility with facts, you should understand that, if you still choose to believe that there is a conspiracy to ignore a "widespread" issue, the burden of proof is on you. It's that simple!

pbatard picture pbatard on 11 Jan 2019

@daddyslittleone

Rufus also made useless my 64GB Stellar Flash drive! I didn't save the log and I will not redownload your nefarious software to make a new one.

That kind of attitude isn't very helpful. Even if there _was_ a problem (and I agree with @pbatard that there isn't), without co-operation from people like yourself who are experiencing problems, it's impossible to investigate further.

Unfortunately it seems that most people who are quite happy to complain and accuse Rufus or Etcher of "breaking their drives" are almost always unwilling to provide further assistance :disappointed:

lurch picture lurch on 11 Jan 2019

My 2 gb sd card just got Rufused :). Reporting in. Is there any UnrufusMySdCard.exe?
Probably some sdcard/usb drives don't like the process.

mrk310310 picture mrk310310 on 12 Jan 2019

I suggest you validate that your card really can't be used from a Linux host. You may also want to look what Device Manager / Disk Manager report in Windows.

For instance, I know that some Chromium images with tons of GPT partitions will completely throw Windows off balance (pure Windows bug) and __make it look like the card is inaccessible__, whereas if you repartition and reformat the card in Linux, you'll find that it works just fine, and you will be able to reuse it from a Windows host.

Now, if even Linux can't access the card, then you will have to RMA it to the card manufacturer.

Also, it __always__ help when people who want to report flash storage issues do provide the full information about their media (brand, complete type, when it was bought, from which store, etc.) as well as the VID:PID reported by Rufus in its log when accessing the media (which would be the VID:PID of the adapter when using an SD card). And of course you should also report the kind of image you were trying to write on it.

Else, it's pretty much akin to telling a car mechanic _"My car doesn't work"_, over the phone, without reporting the car model or its age or any other detail that can provide insight as to the reasons for the breakage, such as how exactly you were trying to use the car when you encountered the issue...

pbatard picture pbatard on 12 Jan 2019

@mrk310310 You can always try one of the suggested program i mentioned here

Sopor picture Sopor on 13 Jan 2019

I wasn't asking for help, just reporting.
The image was a 600mb Win10-live-usb thing, "burned" with GPT option, on Windows 7. The sd card was - Kingston 2gb microsd SD-C02G Japan, on the other side of the card were two lines - 0832 U59502Y.

Also I don't want the dev to feel bad because of this situation. Again, some memory chips probably just work weird.

mrk310310 picture mrk310310 on 13 Jan 2019

Is there any UnrufusMySdCard.exe?

@mrk310310 Isn't this to ask for help?

Sopor picture Sopor on 13 Jan 2019

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.

PhoebeAnn picture PhoebeAnn on 13 Jan 2019

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.

yodies picture yodies on 18 Feb 2019

One a 16GB SanDisk Cruzer Glide, the other a 16GB Sony thumbdrive.

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.

Two failures in a row is not a coincidence.

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 WriteFile() to write data to an USB Flash drive, and that only does so against the Physical or Logical drive that abstracts the device, to actually send some kind of "self-destruct" commands.

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:

  • I have never experienced a drive failure while I used Rufus, even as, as its developer, I have used very sketchy and versions that had major bugs, as happens during the course of software development. As a matter of fact, considering the life expectancy of most flash-based media, I am exceedingly surprised that I have yet to experience a coincidental failure while I using Rufus, since I'm using a testing the application on an almost daily basis. I've seen USB flash drive failures of course, but, as of today, never when using Rufus.
  • The amount of reports of "Rufus killed my flash drive(s)" I see is pretty much in ballpark of what I expect to see from coincidental failures, poor hardware, use of dodgy images (such as those FreeBSD/Chromium ones), fake drives and so on. Especially, I'm certainly not seeing the wave of angry reports that's to be expected from an application that's downloaded ~3 million times each month, if it really had a systemic issue with regards to destroying drives. Or, if you want to venture an alternate explanation for why, whereas people would be experiencing tons of failures, these reports would not appear in large number on very public web sites such as Superuser, Windows/Linux user forums, reddit or even this very issue tracker (of which I don't recall ever deleting a single issue report, or altering it in a way that would conceal the original issue being reported), I'd be interested to hear why you think reports appear to be withheld.
  • Again, none of the flash drive manufacturers, power users and (sometimes) large corporations that appear to use, rely on or recommend Rufus, and who definitely would have vested interest in investigating and demonstrating that there is an issue, if issue there was, have filled such a report.

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

pbatard picture pbatard on 18 Feb 2019
❤1 👍1

We also encountered the FreeBSD Windows-bug on Etcher https://github.com/balena-io/etcher/issues/1839

lurch picture lurch on 18 Feb 2019

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' dd and then plugging the drive in Windows.

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

pbatard picture pbatard on 18 Feb 2019

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:
"The Memstick image is smaller than the memstick and even though it places the secondary GPT at the end of the image, that is not necessarily the end of the disk. This seems to crash Windows."

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

lurch picture lurch on 18 Feb 2019
👍1

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 picture pbatard on 18 Feb 2019
👍1

@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 picture n30nwav on 8 May 2020

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

pbatard picture pbatard on 8 May 2020

I don't think it is an isolated incident.

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.

just now confirmed the end point was Rufus.

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:
_"But what if Rufus screws up the data it sends to the Hardware Abstraction Layer? Couldn't that somehow result in Windows sending bad USB commands to the flash drive?"_

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.
Also, and this is the most important point, you have to realize that these APIs are very limited. For instance, here is the ONLY API call that is ever used in Rufus to write to an USB flash drive (either directly or indirectly, but the indirect calls always translate to WriteFile() being issued in the end).
If you know a little bit about programming, you'll have to explain to me how it's possible to screw up parameters so bad that Windows will end up sending a "bad" USB command on the USB bus. If you use the wrong handle, you're not gonna be accessing the flash drive at all (unless Windows is super buggy) so we can eliminate that. And we never use Overlapped mode (which wouldn't screw us up in the first place anyway), so that leaves passing either a wrong buffer (but if you address is corrupt, you'll get a segmentation fault in the Windows application, not on the target device) or a buffer with bad data... knowing that there's nothing in the Mass Storage protocol that will make the USB bus choke on specific data content (because it's of course designed to be data agnostic, meaning that, as far as the Mass Storage USB protocol is concerned, any data you have in your buffer is just fine and there's no such thing as data that is "more valid" than other). In other words, you could write whatever random stuff you want in your buffer, it's never going to end up producing anything on the USB bus but a Mass Storage message that says "Here's some data for you, that you should write at address N". Especially, it's NEVER going to result in a non Mass Storage USB command (such as "vendor-internal: switch to read-only") being issued on the USB bus. Even if Rufus is buggy, all you'll ever get on the USB bus are regular "read sector N" or "write sector N" messages, that are the only messages Windows can produce in the way the application works, and that's it.

And with this we come nicely to "comeback" 3:
_"But what if you actually send garbage data for the USB controller to write, or tell it to write the data to some 'special sectors'? Surely if you do that, you may end up screwing up the drive!"_

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

  1. The idea that there exists "special sectors" on an USB flash drive, that can be accessed through standard USB commands (such as the "write sector N" we've seen above) is wrong. That's not to say that there might not exist special sectors that are being used to store the controller firmware, but, unless that controller is buggy, it should never let you access these sectors through the regular "write/read sector N" commands. Especially, the sector at address 0 should be the very first sector that the controller designates as accessible for storing user data (NB: this includes the MBR or any sector that belongs to a partition table, which, as far as the controller, Windows and Rufus are concerned ARE pure user data), and, unless it has a major bug, it should return an error whenever it receives a standard command that asks it to read a sector that is lower than 0 or higher than the total capacity the controller has reserved for user data.
    All this to say, even if you were to have a buggy application that somehow manages to get Windows to send a "write sector -1 with this data" command on the USB bus, the Flash drive controller will always validate that the sector it is being asked to write to belongs to the user data range, before it does anything, and will return an error if it doesn't (that is, unless your firmware is very buggy, but even then, I can tell you that Windows should have validated the sector range before the controller gets to do the same, so even if your firmware is buggy, it shouldn't actually matter). In other words, no matter how hard you try, you can not use Windows's WriteFile() (which, again, after device enumeration, is the only call that Rufus ever uses that translates into sending USB bus commands) to overwrite something like the memory area that is used by the firmware (the only exception I can see for this is if you are using a "fake" drive, but if you do, then you can't expect any application, including Windows, not to mess that drive up as soon as you write more data than to it than its actual "non-fake" capacity), let alone toggle a firmware-internal flag such as "read-only" mode.
  2. But what about partition table sectors? Surely the sectors that hold the partition table must be "special" and writing buggy data into them might be the reason why a drive could turn read-only?
    Unfortunately, that whole reasoning falls flat when you know that Windows (or any other OS for that matter) does not see the partition table sectors (or MBR, or VBR/PBR or whatever other set or sector you were told were "special" because if you overwrite them you could lose your data — but please don't conflate losing data with rendering a drive inoperable, since you can always reuse a drive after you lose the data it contained) as any different than any other sectors from your drive. If you can take a completely blank drive and repartition it/reformat it in Windows, or even a drive that has been secure-erased, then clearly, there's nothing that "special" about some sectors compared to other, and, even if you write garbage data on these, the worst thing you'll have to do is repartition/reformat the drive. Especially, you will NEVER end up in a situation where you actually can't recover the drive, no matter what amount of sectors were overwritten with garbage data. Therefore, it is not possible to screw up a drive simply by writing the "wrong" data to any of the sectors that Windows can access.

So, in summary, and as I have tried to establish:

  1. Contary to what you may believe, The Rufus code does not construct and send USB commands on the bus, so, even if there's a major bug, it just cannot inadvertently construct and send a "self destruct" command to a device. Instead it uses the Windows Hardware Abstraction Layer, that makes ALL disk devices (USB, SCSI, etc.) be accessed in the same abstracted manner, i.e. without any direct possibility of control over the USB bus.
  2. Even if Rufus somehow sent garbage/buggy data to the Windows Hardware Abstraction Layer (which pretty much means to WriteFile() since that's all it ever uses to write to a device), the only way it would be able to screw up a USB flash drive is if it were to write to the non-accessible firmware-internal flash drive memory, by attempting to write to a sector that is outside of the regular range for the device. Unfortunately, the only way that could ever happen is if both Windows and the flash drive controller are buggy, because both these entities are supposed to validate the range being accessed, and reject the request if the range is invalid. That's simply not realistic (but if you believe it is, then by all means you should complain to your hardware manufacturer first, because you have just acknowledged that they have done a very crappy job).
  3. And finally, with the knowledge that, even if it was buggy, the only thing Rufus can only ever realistically access are the actual user data sectors reported by the device, and that none of these sectors (partition table, etc.) are any special, and that any competent OS will always be able to rewrite them, no matter the garbage data they contain, we have pretty much demonstrated that it is simply not logically possible for an application like Rufus to render a USB flash drive read-only or make it fail, UNLESS THAT FLASH DRIVE ALREADY HAD A HARDWARE ISSUE IN THE FIRST PLACE (in which case, writing a large amount of data, which is what Rufus typically does, will produce the same issue, regardless of the application being used).

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

PS: I don't think the majority of the people know about Github in the first place

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:
"Hey, I bought a couple of drives from a reputable vendor (e.g. SanDisk, Adata, etc.), but when I used them with Rufus, these drives switched to read-only. So I RMA'd the drives to the vendor, describing what I did, to ask them if they could replicate the issue. They have now come back to me and confirmed that Rufus is the source of the problem because [insert explanation from people who actually have some expertise on the matter here]...".

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

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.

karan316 picture karan316 on 23 Jul 2020

However when I use the pendrive on Linux it works just fine.

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.

pbatard picture pbatard on 23 Jul 2020

However when I use the pendrive on Linux it works just fine.

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.

karan316 picture karan316 on 24 Jul 2020

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.

karan316 picture karan316 on 24 Jul 2020

Also if the BitLocker policy is enabled, how do I get around it?

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.

pbatard picture pbatard on 24 Jul 2020

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.

karan316 picture karan316 on 25 Jul 2020
😕1

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

lurch picture lurch on 25 Jul 2020

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

pbatard picture pbatard on 25 Jul 2020
👍1

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 picture nxdiamond on 25 Jul 2020
👍2

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.

nxdiamond picture nxdiamond on 25 Jul 2020

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.

lurch picture lurch on 25 Jul 2020

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?

karan316 picture karan316 on 26 Jul 2020

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 picture pbatard on 26 Jul 2020

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.

pbatard picture pbatard on 26 Jul 2020
Was this page helpful?
0 / 5 - 0 ratings

Related issues

saschanaz picture saschanaz  ·  4Comments
chazste picture chazste  ·  4Comments
djoris picture djoris  ·  6Comments
kq01526 picture kq01526  ·  9Comments
andriykrefer picture andriykrefer  ·  6Comments