Case of the 30 second File Explorer

I have been having issues with my new Windows 10 gaming/research rig. I upgraded to a 4K TV for a monitor and was running Windows 8.1. This was working good, but I thought that there might be some better DPI scaling in Windows 10 so I decided to give it a try. I downloaded and installed the Windows 10 Insider Preview; found the correct Nvidia driver for the GeForce 980Ti.

There are surely issues with the video driver and TV combination, but mostly it is working. One thing though that was not working though is File Explorer. Every time I clicked on File Explorer or This PC or programs opened an Explorer window there was a huge delay.

At first I thought it might be just the new Quick Access feature in Windows 10, so I disabled opening to Quick Access in the Options of a File Explorer window.

Still the issue occurred.

I ejected the DVD from my BluRay player, sometimes if there is a scratched disk in the drive File Explorer can take more time to open.

I tracked the time it took to open the window, about 30 seconds or so. Anytime you track a timeout of a nice round number it indicative of a hard-coded timeout in the OS.

Time to take a trace.

I started with a WPRUI trace of the issue. This is part of the Windows 10 SDK;

I Installed the Windows Performance Toolkit, plus all of the other tools, they were not needed though.

I ran c:\program files\Windows kits\10\Windows Performance Toolkit\wprui.exe to take a Windows Performance Recorder trace.

I selected the following:

I closed all of the programs and opened File Explorer windows and clicked Start on Windows Performance Recorder.

I opened File Explorer from the Taskbar and it took a long time to open.

I stopped the performance recorder and saved the file. After saving, Windows Performance Recorder will ask if you want to open the trace in Windows Performance Analyzer(WPA), yes please.

To troubleshoot a hang, we need to open the Computation->CPU Usage (Precise) graph.

Now time to configure symbols.

SymCache is also important as cached symbol files will be copied there and I do not want my system drive to fill up with symbols. There seems to be an issue with the version of WPA I am using 10.0.10075 that it does not save the symcache location. I kept on defaulting back to c:\symcache, so I created a symbolic link to the path I want.

mklink /D c:\symcache z:\symcache

Drag the CPU Usage (Precise) to an analysis tab on the right hand side of WPA.exe and setup columns like the following:

The Waits (µs)Max is sorted descending so I see the highest on top, not that it matters, I know the File Explorer is part of the Explorer process so I just filtered on Explorer process. Knowing your Windows Internals is useful sometimes.

Under the Explorer process I expanded the thread with the highest Waits (µs)Max until I started to find some interesting. Looks like when I open File Explorer is called and that calls linkinfo.dll, possibly enumerating some links, shortcuts or favorites. Then on the mpr.dll and ntlanman.dll, so File Explorer is going to the network. Davclnt.dll also gets called as a part of this which is WebDAV, so again calling the network looking for a resource from a shortcut.

I couldn't get the location of what resource was getting called from the .etl trace, so I decided to try a Process Monitor trace. I filtered by PID 3032 and excluded the SUCCESS results. There were some NAME NOT FOUND results pointing to a machine I just decommissioned HTPC. Offline Files(CSC) was trying to read the location.

At this point I had enough information to verify my hypothesis, that a pin, or favorite in File Explorer was present from my old machine, there was and I removed it by right-clicking and unpinning from Quick Access.

After this File Explorer windows and Save and Open file dialog windows opened in a flash.

Case closed!

Want more Windows Performance Toolkit (WPT) posts? Let me know in the comments.

Comments (2)

  1. Nick B (SNS) says:

    Hi Chad,

    Great post. Always useful to see worked examples of real world SysAdmin problems solved with WPT and SysInternals tools.

    Something occurs to me in this particular case: I thought all this blocking the UI on network access had been solved in Vista/7 with the substantial reworking of the redirector, Client Side Cache and shell32.dll? This strikes me as a possible regression bug.

    I can see many many frustrated users hitting this behaviour in the near future, and it taking a great deal of time before the 2nd/3rd corporate support teams get to the bottom of it!

    Anyway, keep up the posts, tips and tricks, they are great to cascade into my teams arsenal of problem solving techniques.



    P.S. Here are some references to similar problems in XP and earlier, but I can’t source where I got the impression this was actually fixed other than real-world experience with 7 and that the age of these articles does suggest the problem was not present (or
    substantially mitigated) from Vista onwards.

  2. Anonymous says:

    Recent Releases and Announcements

    SQL 2016 CTP 2.3 has been released

Skip to main content