Windows – Load Dialog disk access slowdown on Windows 10

hard driveperformancessdwindows 10windows 7

TL;DR my hard drive combination is causing load dialogs to take ~6 seconds to load, which is also confirmed via code, and I can't find any relief.

I had Windows 7 for a long time, ignoring 8 entirely. So long as I was on 7, I had to endure a very long startup time, but otherwise was satisfied with performance on everything.

Right before Windows 10 was released, I bit the bullet and got it installed so I could at least attempt to keep up with the times. At the same time I got a new SSD to install it on to alleviate my startup woes. Everything installed much more smoothly than I had hoped, and I was back up to speed in no time. The growing pains were all but nonexistent, except for a single thorn in my side: occasionally, when I pulled up a load dialog, it would take ~5-10 seconds before even appearing.

(Before you jump up and say "power profile", that not it, it's set to never spin down the hard drives.) I only say "occasionally" because it took me a while to figure out which programs were doing it–at first I think it was everything, but Chrome and others seem to have had the behaviour patched out of it. The big one that still produces the behaviour every time is Gimp 2.8; no matter what I do, if I save a new file or go to load, I have to wait 5-10 seconds for the dialog to pop up.

At first I thought it was a bug in Windows 10 itself, but then as Chrome et al got better, I figured it must just be something with Gimp, which wouldn't be the first oddity I've run into with that program. But then I was brought a bit closer to the hardware and I discovered it was not Gimp's fault.

I do Unity game programming, and I'm currently working on a general purpose save/load dialog using C# (and outdated Mono libraries). When I first got the file browser to work, it was slow as molasses–I chalked this up to a poor method on my part, but as I got to optimizing it, I discovered that the vast majority of the wait time was caused by a single line of code:

string[] drives = System.IO.Directory.getLogicalDrives();

After measuring it, this delay was equivalent to Gimp's slowdown: 5.5 seconds, all for Windows to say "you have a C:, D:, E:, and F: drive". I hacked a modification to my load dialog so it would display this drive info delay, and confirmed that every single time the program is run, I have a ~5-6 second delay. Just to hear back from a System API call to get a list of hard drive paths.

To put into perspective just how bad that is, I ran this same program linked above on my wife's laptop, my brother's laptop, my father's desktop (all three on Windows 10), and my mother's mac mini (after recompiling for a MacOS target). On each and every one of them, the delay is in the 10s of milliseconds, exactly what I would expect. The mac mini took about 20 seconds just to load the damn program, but once it was running, boom, less than a tenth of a second to load the hard drives from that single line of code.

So now I'm at a loss. The power profile is set to not ever power down the drives; my BIOS is set to AHCI for the SSD; I have set the page file to not be dynamic; I've disabled indexing and the Windows Search service; everything is defragmented. I even booted back up into Windows 7 to see the state of things; none of the programs had any kind of load dialog lag, but when I ran my little load tool, it consistently showed 5.5 seconds to load the drives.

I should note that during those 5 seconds, there is no huge spike of CPU/memory or disk access; here's a screenshot of the program moments after running, with task manager there in the background: imgur link.

Here is a screenshot of disk management: imgur link. Disk 0 is the SSD, Disk 1 a recent 1 TB drive, Disk 2 an older Caviar Black 1 TB drive, and Disk 3 a Caviar Green 2 TB drive (never again; it has built-in 20-minute disk shutoff. I'm reasonably sure it's not the cause of this, as repeated tests all still each have a 5 second delay).

Does anyone have any insight for anything else I can try? I'm basically reduced to booting with some of the drives disconnected to see if any individual drive is somehow causing problems (though I tried setting all but disks 0 and 1 offline in disk management, to no avail). Any help would be most appreciated.

EDIT: Some further findings: After disconnecting all HDDs (including my blu ray drive, leaving me with only the one SSD), the problem persists. After completely disconnecting the internet, and disabling network discovery, the problem persists.

In addition, the 5.5 second mark seems to be a rock solid number. The "Disk Walk" time of my tool (which is how long it takes for the first level of directories of each disk to be read) varies wildly, while the Disk read time is always in the 5.550-5.580 range. This seems to indicate some sort of 5.5 second timeout is happening somewhere.

EDIT 2: I booted into Windows 7 with just the 2 1TB drives connected. Load time is still slaved to the 5.5 second wait, even without the SSD involved, which kills my leading theory on the root cause. This suggests to me that perhaps there is an issue with the motherboard's input drivers, maybe?

My hardware, just in case it ends up being pertinent:

  • Processor: AMD Phenom II X4 965-Black
  • Motherboard: Gigabyte GA-790XTA-UD4
  • Video: AMD HD 5770
  • SSD: OCZ ARC 100 240GB
  • HDD: WD Black 1TB (2013)
  • HDD: WD Green 2TB (2011)
  • HDD: WD Black 1TB (2010)

Best Answer

Gorram son of a businessman.

It was the nonexistent floppy drive. No-one ever expects the drive they don't have!

My motherboard has a floppy controller on it, which apparently as a technology hails from the era where checking to see if anything is connected was considered a waste of clock cycles. Each and every time I ran System.IO.Directory.GetLogicalDrives(), it was waiting for the ghostly drive to timeout.

I opened up my BIOS and found a setting to disable the floppy altogether, which has caused the problem to completely evaporate. Gimp now loads flawlessly, too.

I'm such a fracking good detective.

Related Question