Rufus: Error while partitioning drive

[hamzaabdullah90]

Checklist

• [x] I looked at https://github.com/pbatard/rufus/wiki/FAQ to
  see if my question has already been answered.
• [x] I performed a search in the issue tracker for similar issues, using keywords relevant to my problem.
• [x] I clicked the Log button in Rufus and copy/pasted the log into the line that says <FULL LOG> below.
• [x] The log I am copying is the FULL log, starting with the line Rufus version: x.y.z - I have NOT removed any part of it.

Additionally (if applicable):

• [x] I ran a bad blocks check, by clicking the "bad blocks" check box in Rufus, and confirmed that my USB is not defective
• [x] I also tried one or more of the following:
• [x] Using a different USB drive
• [x] Plugging the USB into a different port
• [ ] Running Rufus on a different computer
• [x] Running Rufus as an administrator
• [x] If using an ISO image, I clicked on the # button (at the bottom of the Rufus interface), to compute the MD5, SHA1 and SHA256 checksums, which are therefore present in the log I copied. I confirmed, by performing an internet search, that these values match the ones from the official image.

Issue description

I cannot make a bootable drive with
Kali Linux: SHA1: 25cc6d53a8bd8886fcb468eb4fbb4cdfac895c65,
on Windows 10: 64-bit (Build 14393),
using a SanDisk Cruzer Blade USB Device 14.5GB "16GB".
I encounter the following error:
"Error: Error while partitioning drive".

Log

Rufus version: 2.11.995
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~beta3
System locale ID: 0x0409
Will use default UI locale 0x0409
Found USB 2.0 device 'SanDisk Cruzer Blade USB Device' (0781:5567)
1 device found
Disk type: Removable, Sector Size: 512 bytes
Cylinders: 1900, TracksPerCylinder: 255, SectorsPerTrack: 63
Partition type: MBR, NB Partitions: 1
Disk ID: 0x013C0AFB
Drive has a Rufus Master Boot Record
Partition 1:
  Type: NTFS (0x07)
  Size: 14.6 GB (15630073856 bytes)
  Start Sector: 2048, Boot: Yes
Checking for Rufus updates...
Checking release channel...
No new release version found.
Found USB 2.0 device 'SanDisk Cruzer Blade USB Device' (0781:5567)
1 device found
Disk type: Removable, Sector Size: 512 bytes
Cylinders: 1900, TracksPerCylinder: 255, SectorsPerTrack: 63
Partition type: MBR, NB Partitions: 1
Disk ID: 0x013C0AFB
Drive has a Rufus Master Boot Record
Partition 1:
  Type: NTFS (0x07)
  Size: 14.6 GB (15630073856 bytes)
  Start Sector: 2048, Boot: Yes
Found USB 2.0 device 'SanDisk Cruzer Blade USB Device' (0781:5567)
1 device found
Disk type: Removable, Sector Size: 512 bytes
Cylinders: 1900, TracksPerCylinder: 255, SectorsPerTrack: 63
Partition type: MBR, NB Partitions: 1
Disk ID: 0x013C0AFB
Drive has a Rufus Master Boot Record
Partition 1:
  Type: NTFS (0x07)
  Size: 14.6 GB (15630073856 bytes)
  Start Sector: 2048, Boot: Yes
Processing Hub 1:
  Hub[1] = '\\?\usb#root_hub20#4&38cab459&0#{f18a0e88-c30c-11d0-8815-00a0c906bed8}'
  Found ID[241]: USB\VID_8087&PID_0024\5&C1D2972&0&1
Processing Hub 2:
Processing Hub 3:
  Hub[2] = '\\?\usb#root_hub20#4&f58704c&0#{f18a0e88-c30c-11d0-8815-00a0c906bed8}'
  Found ID[161]: USB\VID_8087&PID_0024\5&CAE62A5&0&1
Processing Hub 4:
  Hub[3] = '\\?\usb#root_hub30#4&319fc005&0&0#{f18a0e88-c30c-11d0-8815-00a0c906bed8}'
  Found ID[121]: USB\VID_0781&PID_5567\20042103301890725D41
Processing Hub 5:
  Hub[4] = '\\?\usb#vid_8087&pid_0024#5&cae62a5&0&1#{f18a0e88-c30c-11d0-8815-00a0c906bed8}'
  Found ID[100]: USB\VID_04CA&PID_2007\B00594FE8548
  Found ID[187]: USB\VID_138A&PID_0011\BF2CAA0219B0
  Found ID[004]: USB\VID_5986&PID_0397\6&116246E3&0&6
  Found ID[041]: USB\VID_093A&PID_2510\6&116246E3&0&2
Processing IDs belonging to 'USBSTOR':
  USB\VID_0781&PID_5567\20042103301890725D41
Processing 'USBSTOR' device:
  Hardware ID: 'USBSTOR\DiskSanDisk_Cruzer_Blade____1.27'
  Matched with ID[121]: USB\VID_0781&PID_5567\20042103301890725D41
  Matched with Hub[3]: '\\?\usb#root_hub30#4&319fc005&0&0#{f18a0e88-c30c-11d0-8815-00a0c906bed8}'
Found USB 2.0 device 'SanDisk Cruzer Blade USB Device' (0781:5567)
Processing 'IDE' device:
  Disabled by policy
1 device found
Disk type: Removable, Sector Size: 512 bytes
Cylinders: 1900, TracksPerCylinder: 255, SectorsPerTrack: 63
Partition type: MBR, NB Partitions: 1
Disk ID: 0x013C0AFB
Drive has a Rufus Master Boot Record
Partition 1:
  Type: NTFS (0x07)
  Size: 14.6 GB (15630073856 bytes)
  Start Sector: 2048, Boot: Yes
Scanning image...
ISO analysis:
  Image is an ISO9660 image
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
libcdio: from_733: broken byte order
  Will use '/isolinux/isolinux.cfg' for Syslinux
  Detected Syslinux version: 6.03/20160618 (from '/isolinux/isolinux.bin')
Disk image analysis:
  Image has an unknown Master Boot Record
  Image is a bootable disk image
ISO label: 'Kali Live'
  Size: 3076767744 bytes
  Has a >64 chars filename
  Uses: Syslinux/Isolinux v6.03
  Note: This ISO uses symbolic links, which will not be replicated due to file system limitations.
  Because of this, some features from this image may not work...
Using image: kali-linux-2016.2-amd64.iso
Will reuse 'ldlinux.sys' and 'ldlinux.bss' from './rufus_files/rufus_files/syslinux-6.03/20160618/' for Syslinux installation

Format operation started
Requesting disk access...
Opened drive \\.\PHYSICALDRIVE1 for write access
Will use 'G:' as volume mountpoint
I/O boundary checks disabled
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 [0x00000005] Access is denied.
  StartSector: 0x00000000, nSectors: 0x1, SectorSize: 0x200
Could not reset partitions
Re-mounted volume as 'G:' after error

Processing Hub 1:
  Hub[1] = '\\?\usb#root_hub20#4&38cab459&0#{f18a0e88-c30c-11d0-8815-00a0c906bed8}'
  Found ID[241]: USB\VID_8087&PID_0024\5&C1D2972&0&1
Processing Hub 2:
Processing Hub 3:
  Hub[2] = '\\?\usb#root_hub20#4&f58704c&0#{f18a0e88-c30c-11d0-8815-00a0c906bed8}'
  Found ID[161]: USB\VID_8087&PID_0024\5&CAE62A5&0&1
Processing Hub 4:
  Hub[3] = '\\?\usb#root_hub30#4&319fc005&0&0#{f18a0e88-c30c-11d0-8815-00a0c906bed8}'
  Found ID[121]: USB\VID_0781&PID_5567\20042103301890725D41
Processing Hub 5:
  Hub[4] = '\\?\usb#vid_8087&pid_0024#5&cae62a5&0&1#{f18a0e88-c30c-11d0-8815-00a0c906bed8}'
  Found ID[100]: USB\VID_04CA&PID_2007\B00594FE8548
  Found ID[187]: USB\VID_138A&PID_0011\BF2CAA0219B0
  Found ID[004]: USB\VID_5986&PID_0397\6&116246E3&0&6
  Found ID[041]: USB\VID_093A&PID_2510\6&116246E3&0&2
Processing IDs belonging to 'USBSTOR':
  USB\VID_0781&PID_5567\20042103301890725D41
Processing 'USBSTOR' device:
  Hardware ID: 'USBSTOR\DiskSanDisk_Cruzer_Blade____1.27'
  Matched with ID[121]: USB\VID_0781&PID_5567\20042103301890725D41
  Matched with Hub[3]: '\\?\usb#root_hub30#4&319fc005&0&0#{f18a0e88-c30c-11d0-8815-00a0c906bed8}'
Found USB 2.0 device 'SanDisk Cruzer Blade USB Device' (0781:5567)
Processing 'IDE' device:
  Disabled by policy
1 device found
Disk type: Removable, Sector Size: 512 bytes
Cylinders: 1900, TracksPerCylinder: 255, SectorsPerTrack: 63
Partition type: MBR, NB Partitions: 1
Disk ID: 0x013C0AFB
Drive has a Rufus Master Boot Record
Partition 1:
  Type: NTFS (0x07)
  Size: 14.6 GB (15630073856 bytes)
  Start Sector: 2048, Boot: Yes

[hamzaabdullah90]

Mr. @pbatard and Mr. @bovirus Please help, it is really urgent!!?

[pbatard]

Did you __actually__ run the bad blocks check? And did you try with a different USB drive? Please don't check boxes __unless__ you have actually performed the task.

Also, if you look at the FAQ, you will see that there is an entry about the Access is denied error that you see in your log.
At first glance it looks like either your USB is damaged (which is why it is important to try with a different drive if you can - if you don't have another drive, then you should leave the checkbox blank so that I know that your issue only occurred with a single drive) or something on your computer is preventing access to the drive, which you will need to figure out, as it's next to impossible for anyone that is not sitting in front of your computer to tell. You may also take a look at the end of the FAQ for the list of software that is incompatible with Rufus, in case you're using one of these.

[hamzaabdullah90]

Dear @pbatard,
Yes, I did check for bad blocks, and I already did try with four different thumb drives one of them was a sd card.
I am very sorry I did check earlier the Running Rufus on a different computer check box which I did not really.
and finally, how can I send the screenshots??!
My Best.

[pbatard]

Yes, I did check for bad blocks, and I already did try with four different thumb drives one of them was a sd card.

Then , as I mentioned earlier, this is an issue with __other__ software on your computer preventing access to the drive. It could be a security solution, it could be something else. Have you had a look at the end of the FAQ?

At any rate, I'm afraid that your issue is external to Rufus. There's not much I can do in Rufus if an external application is preventing access. One thing you may try is the Alt-, cheat mode that is mentioned in the FAQ, to see if that's help. But if that doesn't work, you're on your own until you've identified what is the application that is preventing access.

[hamzaabdullah90]

Dear @pbatard,
I will gladly try and report back, maybe it is Bitdefender or Malwarebytes.
Best regards.

[hamzaabdullah90]

Dear @pbatard,
I have disabled every antivirus even windows defender, but the problem still exists.
I used lockhunter and I have uploaded some of the screenshots if they can help!
Thank you.
screenshots.zip

[pbatard]

I have disabled every antivirus even windows defender, but the problem still exists.

Then it is something else. As I said earlier, the only person who can figure out what application is preventing access is __you__, and there is not much anyone can do to help. I also assume that you tried the Alt-, cheat mode and it didn't work, right?

One thing that may help you identify what application is preventing access is Process Explorer.

If you run it as Administrator, and then select _View_ → _Show Lower Pane_, then you should be able to see a list of files and devices being accessed by each process. Then you can try to locate the one that is accessing your USB (Which will usually appear as \Device\Harddisk#...) as per the screenshot below:

But you'll have to figure out which disk number is your USB. And you'll also have to go through each process one by one.

[hamzaabdullah90]

Yes, I did try the cheat mode.

[pbatard]

Considering that this issue has to do with something that is external to Rufus, I will close it.

[hamzaabdullah90]

By the way, I forgot to tell you that when I reboot into safe mode it worked seamlessly, therefore I think you are right it must be something external, I wish you could make Rufus takes an absolute control over USB thumb or anything if it is not too much to ask! @pbatard

[pbatard]

I wish you could make Rufus takes an absolute control over USB thumb or anything

I'm very much trying to do all of that. Rufus is requesting exclusive locks to the physical drive as well as the volumes, before it attempts to write anything, but Windows is a weird beast (for instance, you can be granted an exclusive lock on a physical disk but still be unable to write on the volumes that belong to this disk unless you do some extra stuff), and one actually has to relinquish those locks at some stage to keep Windows happy.

I have however recently added an improvement [2f81e4f177a3603f6a29b11e3f8b7721728e232c] to avoid the use of FILE_SHARE_WRITE, which may help. It will be part of the next version of Rufus, which will be released _whenever_ (the date of that release is subject to a varied set of circumstances, so at this stage I cannot even say whether it will be in one month... or one year).

I would still encourage you to spend some time with Process Explorer, as advised above, to try to identify the culprit application. If you can find which one it is, I will add it to the FAQ, which may help others in the same situation as you.

[hamzaabdullah90]

Windows is a weird beast

You got that right and I promise you I will do the checking using Process Explorer at the closest opportunity.

[pseudolobster]

Sorry to jump into a dead thread like this, but this is the top google result for this error. In my case, rufus was throwing this error and refusing to touch the drive because of the existing data on the drive.

I had formatted it using gparted on linux, and it worked fine, passed all chkdsk's, but rufus refused to partition it. I even tried creating a new partition table using gparted and tried formatting as both fat32 and ntfs, but nothing.

What fixed it was using the "dd" command to write zeros to the usb key like so: dd if=/dev/zero of=/dev/sdc where sdc was my usb drive.

Whatever the real problem is, rufus seems to be really unaggressive when partitioning, and I've encountered this error message a lot on various drives.

[paddockn8]

I solved this issue by temporarily turning off "Controlled Folder Access" from within the Windows Security Center. It is a feature under Virus & Threat / Ransomware Protection. This is a fairly new feature of Windows 10.

[abhijeet-roy]

well although this thread is closed but its the 1st one appearing in the google search with similar kind of problem.

as said by paddockn8 the simple fix is to go to the windows defender-> then virus and threat protection settings -> scroll down until u find controlled folder access and just add your usb drive in the exclusion. it will work fine then

[pbatard]

You will also find that the latest version of Rufus will tell you if Controlled Access Folder is enabled when you encounter an error, with the following message in the log:

WARNING: 'Controlled Folder Access' appears to be enabled on this system
You may need to disable this feature, or add an exception, for Rufus to to work...

Therefore, and I CANNOT STRESS THIS ENOUGH, if you encounter an issue, ALWAYS check the log!

[avcko]

You also have to remember to start rufus in administrator mode. It did not work for me even when I added the exception to the "Controlled Folder Access".

[gjdgjd]

The "writing zeros" comment above is correct and solves almost all such issues. Strangely it seems to be an issue with more modern drives - maybe they are low(ish) level protected in some way. I have old Integral 8GB; no problem at all; new integral 8GB; error:error (was making a Windows 10 boot disk for a friend so it is not my drive). If you are a Windows person and you want completely to wipe a usb disk then download the free version of EaseUS partition manager and use the "wipe" option. This writes zeros (and it takes a while). The resulting wiped disk then works perfectly with Rufus. Just FYI the EaseUS programme is quite brilliant; does all sorts of useful things (cloning OS onto bigger drives for example) - but it does have a bit of a learning curve and if you are careless I think you could do some serious damage with it - gently does it! I am really looking after my three old Integral 8GBs......

[pbatard]

You do know that you can zero a drive in Rufus through the Alt-Z cheat mode, do you? No need to use an external application or Linux.

With recent versions, you can even cycle (reset) an USB port with Alt-C.

If you encounter the issue above, these are the first 2 things you should try.

[gjdgjd]

I had read a bit about Alt-Z but it was new to me (and a few people had reported that it didn't help them) and I didn't know what hitting Alt-Z might do in addition. I have always, (for more years than I care to remember), tended to stick with one successful way of doing things (I have entire programmes on my PC for a single function - so I am never suprised by something!) and what I knew was EaseUS would do it with no side effects. Interestingly you only have to zero the drive once and Rufus seems to have no issues with it after that - it will overwrite existing data with no problems. Seems to suggest that these modern drives have low level data/flags set in sectors which are not touched by the normal higher level format/partition utilities but once they are zeroed they are zeroed forever. Useful programme this Rufus - Thanks for it.

[JonnyTech]

Seems to suggest that these modern drives have low level data/flags set in sectors which are not touched by the normal higher level format/partition utilities but once they are zeroed they are zeroed forever.

I reached a similar conclusion myself, although dd'ing certain images requires a further partial zeroing (first 64 blocks is usually adequate), as such I always zero new drives.

[gjdgjd]

Interesting - I think I will also zero everything before I start - I am just a bit nervous that if I zero everything I might actually brick the thing. I have not had your issue yet but my images are confined to Windows (XP, Vista, 7 and 10), Linux Mint (v19) and a couple of DOS boots (from Windows 98 and Windows Me - don't ask!). Which ones need/needed the extra zeroing?

[ArNice]

Open disk management and delete that removable volume, then format it with rufus

[PNjinu]

Just download another rufus version...

[Senay-Gebre]

it worked for me after i disabled my windows defender

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.