You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 well, 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.
Analysis:
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.
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
WPA
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 windows.storage.dll 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.
Procmon
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 called 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.
Remediation:
After this File Explorer windows and Save and Open file dialog windows opened in a flash.
Case closed!
The text was updated successfully, but these errors were encountered:
Taken from my post https://www.chadschultz.com/2015/07/27/case-of-the-30-second-file-explorer/
Scenario:
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 well, 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.
Analysis:
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 ADK and SDK; https://docs.microsoft.com/en-us/windows-hardware/test/wpt/.
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
WPA
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 windows.storage.dll 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.
Procmon
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 called 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.
Remediation:
After this File Explorer windows and Save and Open file dialog windows opened in a flash.
Case closed!
The text was updated successfully, but these errors were encountered: