Rufus *very* slow to open (does recognize drive, write speed is fine)

[taconomix]

Checklist

• I looked at https://github.com/pbatard/rufus/wiki/FAQ to see if my question has already been answered.
• I performed a search in the issue tracker for similar issues using keywords relevant to my problem, such as the error message I got from the log.
• I clicked the 'Log' button or pressed Ctrl-L in Rufus, and copy/pasted the log into the line that says <FULL LOG> below.
• 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):

• [na] I ran a bad blocks check, by clicking Show advanced format options then Check device for bad blocks, and confirmed that my USB is not defective.
• I also tried one or more of the following:
  • Using a different USB drive.
  • Plugging the USB into a different port.
  • Running Rufus on a different computer.
• If using an image, I clicked on the (✓) 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

I recently had to reinstall Windows10 on my Alienware 17r5. I had used Rufus several times with no problem. Since reinstalling, however, Rufus is taking an INCREDIBLY long time to start up. I'm talking 5+ minutes. At first I was using the rufus-3.11p.exe file I had backed up, but then when I ran into the issue I deleted and re-downloaded. Same issue: It immediately opens as a background process (seen in my windows task manager), but the actual program interface doesn't pop up (and doesn't show as open on the taskbar) for over 5 minutes. This happened multiple times. When the program actually opens, it works fine and writes the iso in about the same amount of time it used to. I have also tried downloading different versions (3.11 non-portable, 3.10, 3.5) with the same issue. It's obviously something about my settings and not Rufus, but I can't for the life of me figure out what is causing this. Other programs don't seem to have any issues anything like this, but this is the only program I've used that runs directly from a downloaded .exe file (rather than running an installer to install the program).

Log

Rufus x86 v3.11.1678
Windows version: Windows 10 64-bit (Build 18363.418)
Syslinux versions: 4.07/2013-07-25, 6.04/pre1
Grub versions: 0.4.6a, 2.04
System locale ID: 0x0409 (en-US)
Will use default UI locale 0x0409
SetLGP: Successfully set NoDriveTypeAutorun policy to 0x0000009E
Localization set to 'en-US'
Found USB 2.0 device 'VendorCo ProductCode USB Device' (FFFF:5678)
1 device found
Disk type: Removable, Disk size: 8 GB, Sector size: 512 bytes
Cylinders: 979, Tracks per cylinder: 255, Sectors per track: 63
Partition type: MBR, NB Partitions: 1
Disk ID: 0x00354C0D
Drive has a DOS/NT/95A (F2) Master Boot Record
Partition 1:
  Type: FAT32 (0x0b)
  Size: 7.5 GB (8053030912 bytes)
  Start Sector: 64, Boot: Yes

[pbatard]

1. What happens when you start without your VendorCo ProductCode USB Device (FFFF:5678) plugged in?
   I'm asking this because 0xFFFF is an invalid device manufacturer ID, and we obviously want to eliminate the enumeration process of that specific device as the issue
2. Please enable enumeration debug in Rufus with Alt-.
3. Please make sure you have DebugView running while you launch Rufus, as Rufus also sends its log data there, and you will therefore get a precise idea of where it gets stuck. You can download and install DebugView from https://docs.microsoft.com/en-us/sysinternals/downloads/debugview. Or, even better (if you can) is to install Visual Studio 2019 (the Community Edition is completely free to install and run) on the computer where you are seeing the problem, then clone this GitHub project and recompile/run Rufus from source in Debug mode. From there:
   • Pause the execution when Rufus appears to get stuck (0 in the screenshot below).
   • Open the the "Call stack" tab at the bottom (1 in the screenshot below).
   • In the call stack, click on the highest line (that still pertains to the application) and it will tell exactly where in the code Rufus is stuck (2 in the screenshot below).

Considering that this is an issue that I can't replicate, any help you can provide is appreciated, as it will be exceedingly difficult to troubleshoot otherwise

[taconomix]

I can't believe I didn't try this before posting here, but when I have no USB flash drive plugged in, Rufus starts instantly. I also tried with a Samsung 64GB drive that I had, and ran into the same issue. Also, when I start Rufus with no drive plugged in and it starts instantly, it then freezes for a long time (although less so than it takes to start with USB plugged in). It has the same issue no matter which USB port is used on my computer or dock. I have not been able to replicate this issue on a different Alienware computer (the guy who sits next to me at work), even using the same flash drives.

I am installing Visual Studio now, and will report back when I am able to test as you instructed.

[pbatard]

Thanks. If you install Visual Studio, make sure you have a look at the "Output" tab (it's in the same section as the one where you find "Call stack") and run Rufus with debug enumeration enabled (Alt-.) as Rufus' log output gets sent there, and therefore you should be able to report what are the few last log messages you see before Rufus gets stuck...

At any rate, thanks a lot for being willing to install Visual Studio to test this. I've had a few sporadic reports of issues similar to yours (Rufus is running but the UI doesn't appear or takes a long time to do so), but I never got those users to report back.

Oh, and since you are going to run Rufus from Visual Studio, let me guide you a bit further on how you should proceed:

1. When installing Visual Studio, you'll need to make sure that you select the Desktop development with C++ component
2. When you start Visual Studio, select Clone a repository and enter https://github.com/pbatard/rufus.git as the URL
3. After the Rufus source has been downloaded and the project created, make sure you select Debug and x64 (or x86 if your machine is 32-bit only) as per the screenshot below:
   
4. Click Local Windows Debugger to build and debug Rufus. Visual Studio will prompt you to restart as administrator when it first launches Rufus, since it's an elevated app, so let it do that (and click Local Windows Debugger again once it has done so).

From there you should be able to perform the steps I detailed previously.

[taconomix]

Thank you for getting back to me so quickly. This was my first time using Visual Studio, so I appreciate the detailed instructions. Attached are two screenshots of the paused-state that you requested. I also included a screencap with the full table of the Call Stack tab, in case that is helpful.

I paused a few different times to see if it was the same process getting stuck, or if it would change. It was always the same, Line 162. I also ran the program multiple times to make sure the result was the same. Pausing still brought me to line 162 each time.

I also think you should know that while it did still take quite a while to open (3:11 the first time, 3:40 the second time, 4:12 the third time), that is significantly faster than when I simply ran the rufus-3.11.exe file that I downloaded, which I haven't timed, but I would estimate takes ~10 minutes.

Just wanted to add that I'm a huge fan of Rufus, it's helped me out with a bunch of projects, so thank you for making it!

[pbatard]

Any update on this? I'm still very interested in identifying why the application appears to freeze on startup on your system.

[taconomix]

Seems to still be doing the same thing. Is there anything else I can do to help you identify the issue besides those screenshots from Visual Studio? I'm not a developer but I know the basics, so I will do everything I can.

[pbatard]

My bad. I completely missed your reply with the screenshots from 10 days ago. This is very helpful, as it tells us that the underlying issue is that Windows appears to be very slow to open some disk devices on your system (which is not something Rufus can do much about, as Microsoft doesn't really let applications tell system calls to "Hurry up!")

I guess one solution would be to have a timeout on trying to open these handles, but even there, Windows is a pain in the ass, as the CreateFile() API is designed to wait forever, so we'd have to do some gymnastic, and this may just shift the problem elsewhere... I think I might start with tweaking the enumeration code a little bit to see if that helps.

One thing I'd very interested to find out though is what specific device of yours is creating the holdup, so can I please ask you to run a test with the following:

1. In dev.c add the following line right before drive_number = GetDriveNumber(hDrive, devint_detail_data->DevicePath); (around line 845 in the file:

uprintf("TRYING: '%s", devint_detail_data->DevicePath);

2. Run the same test you did, and look at the Ouput tab at the bottom when it freezes, as you should see a TRYING: (...) line in there (basically the code I made you add above). If you could copy/paste that output I would appreciate it. And while you're at it, if you could enable enumeration debug with Alt-. before running this test (i.e. once you get Rufus to eventually show its UI) and copy paste the full log you see, that may give me some more insight.

At any rate, I appreciate your testing (sorry for missing your previous reply!). Hopefully this will help me come up with something to avoid these weird freezouts on start.

[taconomix]

I will do that. The weirdest part to me is that I'm using the exact same hardware as before. I had a Windows update the broke my keyboard and mouse for some reason, and had to reinstall Windows. Before the reinstall, I had no issues, and as far as I know, all software and settings are the same as before.

[pbatard]

Still hoping you can run the test I asked above and report your results.
Another thing I'd like to know is whether diskpart has the same issue, as I am seeing reports that, on platforms that experience this issue with Rufus, diskpart will also be very slow to launch, if it launches at all. So can you try opening an elevated command prompt on the machine where Rufus is slow to launch, then launch diskpart and see what happens?

[taconomix]

Sorry I haven't been able to get to this. Been a really busy month. I will try to get all of these tests done this week.

[pbatard]

Have you had a chance to test with Rufus 3.12? I made some small improvements in that version, that may change things a little bit. Otherwise, I'd still like to have the ouput from the test I requested. Thanks.

[ghost]

I'm getting the same issue too on my work machine. I never have any problems with Rufus until i updated Windows 10 to 1909 build 18363.592 deployed via PXE boot, means clean install with custom image. Cloudready USB maker seems to have same issue too. Unetbootin worked fine for me

I must assume @taconomix is on the same version too because his build version is Build 18363.418 but a bit older

My home computer is 2004 which is 19041.572. Didn't tried Rufus yet

I'm not sure if I should try VS2019 or not. Would be quite waste of time, but i would like to help too and figure out why. 1909 must be the buggy version i think

I have sophos anti-virus but I can't disable it due to admin lock. I don't think it's anti-virus issue because Rufus worked on 1809 even Sophos enabled

[taconomix]

I am sorry I thought I had replied this 2 weeks ago, but apparently it did not submit. I have run diskpart with elevated privileges as requested on 9/16, and it ran with no delayI did a little experiment this morning. I took a different laptop (Windows Surface Pro 3 8GB RAM) and did a fresh install. I downloaded Rufus 3.11 and it opened in about 10 seconds. I then installed all the software that our office IT department installs on all company computers (like the laptop I was having issues with), which include Sophos anti-virus, team-viewer, and MS Office. Suddenly the surface pro 3 was having the same issue as the other laptop (with a USB Stick inserted, it still opens instantly with no USB drives attached). I am thinking either Sophos or Team-viewer might be affecting the startup time for Rufus? @Toshiba1127 I am thinking that this might actually be a Sophos issue, possibly some other system software.

Version 3.12 does open much, much faster. It opens instantaneously when no USB drive is inserted (as 3.11 did), but v3.12 opens in under a minute with a USB drive inserted (tested 5 times, results: 37s, 34s, 40s, 48s, 41s) While it still doesn't open instantly, I consider this issue resolved. Even when it took 5 min to open, it was still faster and more reliable than BalenaEtcher. A mere 40 second wait is not even an inconvenience. Thank you so much for fixing this for me and for creating and maintaining this excellent tool, @pbatard. You rock.

[pbatard]

@taconomix, thanks a lot for the report. I was hoping the small changes I applied in Rufus 3.12 might make a difference, so I'm glad to hear it did.

I think the still relatively slow open times are probably system related (i.e. not something that Rufus might be able to fix), as, depending on the hardware, enumeration can be as time-consuming process. For instance, I regularly see Microsoft's Disk Management seemingly taking its sweet time refreshing disks on Windows 10 for no particular reason, so I would say that, as long as you get a refresh not too long after the 30 seconds mark, it's probably good enough...

I will consider this issue closed then. Thanks again for your willingness to help with all this — much appreciated!

[ghost]

Hmm yeah Sophos possibly caused the problems because it make some weird problems on Windows in the past.
After a while, Windows stopped recognize any USB for no reason, but it works flawlessly on my Linux system on same hardware. No problem formatting and burning

I will try out more alternatives see if they have problem, and maybe disable Sophos via linux since they won't give me the admin password.

[ghost]

Guys, when I booted into safe mode, Rufus works like a charm again and it opens instanly while USB connected. I tested with 3.12 and 3.13 BETA

After that, I followed this excellent guide to disable Sophos https://support.sophos.com/support/s/article/KB-000036125?language=en_US and delete remaining files manually. Rufus still works on normal mode. I'm so happy right now that all the weird issues i have that happened for months, disappeared for good. No needed to use an alternative anymore

[pbatard]

Thanks for the report. I already had Sophos feature prominently in the list of Software that is incompatible with Rufus, and I have now added a mention that it may produce very slow startup times for Rufus.

[github-actions]

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.