pbatard
commented
2 years ago so I don't know why wasn't it fixed yet.
Because it's not explorer but another process that you need to identify yourself.
Rufus tries to provide a list of processes that are accessing the drive when it detects that it's unable to write to it because another application has taken a lock, but there's only so many processes Windows allows Rufus to list.
Explorer is usually always listed as a process, because the Windows file explorer will obviously be displaying the drive, but you will usually see it flagged as r which means read-only, and therefore it is not the culprit. But we do list it for completion. The problem is that, unlike what is the case on Linux and other OSes, Windows allows some processes to operate at the system level and not be listed, so you end up in the situation where, when an application like Rufus tries to help its users try to find out what application is preventing Rufus from writing to a drive, the reality is as follows:
explorer.exe (r)→ The WIndows File Explorer application, which only has the drive as read-only and is NOT an issue"? ? ?" (rw)→ The ACTUAL application responsible for locking the drive, that operates as the system/kernel level and that Windows will not provide the name of when attempting to list processes.
The result: Users like yourselves think that Rufus is complaining about explorer.exe accessing the drive, whereas all Rufus does is give you a NON EXHAUSTIVE list of the processes it can list that are accessing the drive to try to help you the one that is the culprit, it case it can help.
Considering that you chose not to attach a log, I'm going to assert that you ran into this in which case you probably want to check this, paying attention, there again, to the fact that the list provided is NOT AN EXHAUSTIVE ONE instead of jumping to the conclusion that Rufus is doing a bad job.
There's only so much I can do to try to help you when an external application is preventing access to a USB drive, which is what I do when I am trying to list all the processes that have read or write access to the drive (which at least explorer.exe almost always has), so, before pointing the finger at the application, you need to understand that there may be more that needs to be interpreted from what is being reported to you, especially when Microsoft has decided that even applications running with elevated privileges should not have the ability to identify all the processes that are running on a computer and that are accessing a drive.
Oh, and especially if you want to complain, the log is NOT optional.
Windows10User2
Checklist
<FULL LOG>below.Rufus version: x.y.z- I have NOT removed any part of it.Additionally (if applicable):
(✓)button 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
Every time I try to write ISO files (in this case, Windows 11's installers) to USB flash drives in +3.9 Rufus versions, a window opens during the process stating explorer.exe is being used and Rufus is unable to finish writing to the USB flash drives. Many users complain about this problem in the internet affecting the latest versions of Rufus so I don't know why wasn't it fixed yet.
Log