The image is either non-bootable lỗi rufus

I received the above error when creating a Ubuntu boot disk from the ISO using Rufus. The Rufus log file showed these entries:

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

Requesting disk access... Will use 'G:' as volume mountpoint Opened \.\PhysicalDrive2 for exclusive write access Analyzing existing boot records... Drive has a Zeroed Master Boot Record Clearing MBR/PBR/GPT structures... Erasing 128 sectors Write error [0x00000005] Access is denied. Retrying in 5 seconds... Write error [0x00000005] Access is denied. Retrying in 5 seconds... Write error [0x00000005] Access is denied. Retrying in 5 seconds... Write error [0x00000005] Access is denied. Could not reset partitions Re-mounted volume as G: after error

Cause

The error [0x00000005] Access is denied occurs if Microsoft Defender’s Controlled Folder Access feature is enabled and it has blocked Rufus from taking excluding write access to the drive.

If you’re not using Microsoft Defender, then check out the equivalent setting in the respective antivirus program.

Solution

To prevent this error from occurring, try disabling Microsoft Defender’s Controlled Folder Access feature temporarily.

Alternatively, you may try adding Rufus’s executable to the list of allowed programs. To allow an app, click “Allow an app through Controlled folder access” option in Windows Defender Security Center. For more information, see the section “Add (whitelist) apps for Controlled folder access” in the article .

Also, refer page of Rufus for additional information.

One small request: If you liked this post, please share this?

One "tiny" share from you would seriously help a lot with the growth of this blog. Some great suggestions:

• Pin it!
• Share it to your favorite blog + Facebook, Reddit
• Tweet it! So thank you so much for your support. It won't take more than 10 seconds of your time. The share buttons are right below. :)

Ramesh Srinivasan is passionate about Microsoft technologies and he has been a consecutive ten-time recipient of the Microsoft Most Valuable Professional award in the Windows Shell/Desktop Experience category, from 2003 to 2012. He loves to troubleshoot and write about Windows. Ramesh founded Winhelponline.com in 2005.

Not much that can be done when Rufus especially indicates that "The device is in use by another process". You will need to find what process is accessing the drive and prevent it to do so. It may be a security solution or one of the software listed at the .

Unfortunately, there's really not much I can do to help, as it's impossible to take a guess at what is causing the access issue. You may have some luck identifying what it is by going through every single running process in Process Hacker and seeing which one seems to keep a lock on your USB drive.

Try turning off Auto Play. In Windows 10 just search for it. Then reboot.

Its an old Post but .. i had the same problem with "the device is used by another process" ((I am using win 8.1 ))

So i easily managed to fix that problem ( by using Process Hacker) The process that was keeping my device busy was SkyDrive, so i just susspended it! And that problem was solved , didn't even needed a pc reboot.

Hope it was helpfull ! Regards

"The device is in use by another process. Please close any other process that may be accessing the device. " I had the same problem. Before using Rufus, I renamed the ISO file to "w7+sp1_x32.iso," resulting in the error message above. After I renamed the iso back to the manufacturer's name, "GSP1RMCHPFRER_EN_DVD.iso," Rufus worked normally. (PS: I also renamed the flash drive from a previous ISO name to 16Gig.)

I too tried many techniques but finally i followed hit and trial....i just copied the same iso file to other location i.e directory within the drive and launched rufus and after then picked up the iso image copied in the other directory,,Doing this everything worked like a charm!!!!

You have to just stop your windows defender because windows defender is accessing your device, after stopping windows defender it will work.

I was having the same problem in my new Win10 install and this solved it:

Windows Defender Security System -> Virus & Threat Protection Settings -> Controlled Folder Access (Manage Controlled Folder Access) -> Allow an App through Controlled Folder Access -> Add an Allowed App

In this case I added Rufus to my list. Alternatively you can disable Controlled Folder Access altogether. I think Microsoft increasing the security access level in general is good news for most customers but having settings buried in obscure menus is counterproductive to others, IMHO.

I hope this helps.

FYI, the latest version of Rufus will tell you if Controlled Folder Access is preventing access in the log. You will see a message like:

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

If you encounter an issue, please try to check the log, as it will give you more details about what the issue can be.

I was able to correct the problem by formatting my USB drive with ExFAT. Rufus displayed an message or two during the process of writing the ISO, but the USB was bootable with my software when finished.

I had the same problem but i didn't read the log, however, you can try clearing your USB label and try again, or format your USB as normal with windows, then use the rufus with out "quick format" checked.

Open Rufus Select ISO file then, Open Task Manager -> Details, find explorer Click on End task, Then on rufus click write ! after write done on task manager -> file -> run & type explorer & click ok :)

Just noticed that using Kaspersky (probably some kind of Controlled Folder Access option) causes this issue, too. Just disable that and you'll be fine to use Rufus.

Sophos Endpoint Protection causes the same issue, disable that and Rufus works fine again.

you could try this, but if you have to reboot, kind of a pain. i didn't want to boot so I just killed explorer.exe temporarily:

I ended up going to Task Manager (ctrl+alt+del) and killing explorer.exe

Then I went back to task manager, file, run new task and typed in explorer to bring the task bar back

if you want to adjust autoplay, here are the steps:

https://www.thewindowsclub.com/set-autoplay-defaults-windows-10

Windows 10 - go to settings, search for AutoPlay

I had to properly copy my iso file. Didn't notice it was incomplete

Deactivating AutoPlay + machine restart worked for me

Note that Rufus does include code to disable AutoPlay while it is running (NoDriveTypeAutorun which is ) so I'm a bit puzzled about these reports about AutoPlay also having be disabled manually. I'm more inclined to think that the reboot is what killed whatever process was accessing the drive...

I am facing the issue "The device is in use by another process" after format the device. Of course I can kill the process via Task manager but it would be much better if Rufus could just ignore the fact that the device is used by another process. If Rufus can format the device, why not to ignore another processes? Or why not to ask user "The device is in use, cancel or continue?" There are another pieces of SW which can detect using of another process, but they just ask weather force continue... In such case is user much less bothered by weird behavior of some processes... It is much better than being forced to change some settings on computer, restart computer etc.

If Rufus can format the device, why not to ignore another processes?

It can.

Or why not to ask user "The device is in use, cancel or continue?"

It already does.

Do this: Open a DOS prompt on your device and press START. This is what you'll get:

As you can see, Rufus already has code dedicated to check for conflicting processes (which we stole from Process Hacker, so we're pretty confident it is very comprehensive in terms of being able to enumerate the processes we seek) and you do get a prompt about other processes accessing the drive and asking you if you want to ignore them.

So, Rufus already does what you suggest.

Now, the problem is that, even as we are doing this, there are some processes and services that are accessing the drive that Windows doesn't always seem to report, and, since you mention that your issue occurs after you format the device (though you may want to clarify when exactly), we can of course not do anything about processes that are designed to monitor new volumes and access them.

For instance, as soon as you format a drive to FAT32 or NTFS, Windows will create a System Volume Information directory and add some files there. And security solutions may decide to scan the newly arrived device, therefore preventing you to access it. And of course there is all the poorly designed software listed at the that seems to open drives for write access.

In that case then you may get a device in use message before Rufus can copy its file, and there's not much we can do about this.

The one thing you may try is the Alt-, cheat mode, which disables the exclusive locking that Rufus tries to use, but otherwise, I will respectfully ask that you don't assume that Rufus is not already doing something you think it should do, and instead provide more details about your actual issue.

For instance, you don't mention at all the process that you can kill in Task Manager. You do realize that knowing what process or application appears to be causing your issue is the very first thing you should be disclosing here...

I am sorry, it is my fault that I had not noticed that Explorer++ i in the list of incompatible SW. Now my solution is to use LockHunter to unlock Explorer++ and get rid of the issue. Killing all instances of Explorer++ is not solution for me - I use a lot of them and kill all of them because some lock is not an acceptable solution.

But still - Truecrypt (for example) has the same problem, when it faces the same issue (folder/directory locked by Explorer++ and some system process) - and yes, Truecrypt just asks "Force dismount" and it is able to dismount volume - without necessity of any other software.

If you say that Rufus can ask (before format) whether it can continue anyway - why Rufus is not successful in other cases like after format? From user's point of view it looks like that Rufus tries to do something and it is not successful in all cases. If other software can do it, than it looks as if it was Rufus' fault. I agree that unnecessary locking of Explorer++ bad thing and Explorer++ should be fixed but stil - should not be Rufus fixed as well?

"Force dismount" is a different thing than what we need.

Dismount applies to volumes (which more or less equates a partition), and Rufus does request a force dismount, probably in the same way as like TrueCrypt (since there aren't that many APIs you can use to "force dismount" a volume) .

Now, if you look at the doc for FSCTL_DISMOUNT_VOLUME you'll see that is says:

The FSCTL_DISMOUNT_VOLUME control code will attempt to dismount a volume regardless of whether or not any other processes are using the volume, which can have unpredictable results for those processes if they do not hold a lock on the volume.

So, yeah, we're no even asking politely as TrueCrypt does, we just force things.

However, that's fine for volumes, but the main issue is you can have applications that hold a lock to the disk itself, and those are a lot trickier to control, even more so as, with its latest instance of disk virtualization (VDS) Microsoft has found nothing better than require that an application that wants to issue low level calls such as deleting or refreshing a partition layout first make sure that they don't have a handle open to the disk... which of course prevents us from keeping a lock on it, which in turn gives ample opportunity for poorly designed applications or even the OS to get their foot in the door before we get a chance to try to reacquire the lock.

Anyway, I'm always happy to accept fixes if you think Rufus can be improved. GitHub has a nice pull request feature, so, if you think Rufus is not doing enough with regards to keeping applications that are a bit too intrusive at bay, I sure wouldn't mind see you (or someone else) take a stab at improving that.

At least considering that I'm currently elbow deep into trying to get Windows to acknowledge a partition refresh without having to issue a USB port cycle (which is the only way I know that conistently works at telling everyone, including the OS, to keep their hands of the disk/volumes), so that we can have a standalone

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

0/

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

1 formatting option that doesn't only work half the time, it would provide me with some company with regards to commiserating on how poorly Windows seems to be designed when it comes to letting an application completely overhaul disks and volumes, without being faced with constant hurdles.

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.