WIndows 10 consuming large amount of CPU with explorer.exe

Question

I'm at a loss as to why my Windows 10 laptop is consuming so much CPU from explorer.exe instances. I've attached two screenshots showing five explorer instances using about 15% CPU each. I have absolutely no idea what they are doing and if I kill them, nothing happens.

The explorer instances are not always there consuming tons of CPU. I haven't been able to really determine a pattern as to when they start consuming all the CPU. The thing that triggers me to look is when my fan kicks in. Once the cooling fan kicks in I know that the CPU is getting railed by these explorer instances. I'm not sure where to go look for information pertaining to these processes and what resources they might be accessing that causes this.

My CPU usage will go up to 95% with these processes and I'm trying to figure what could be causing it.

I've used Process Explorer to try and get more info. If I explore the threads running on the explorer instances they all seem to have this one thread that is consuming the CPU:

ntdll.dll!RtlReleaseSRWLockExclusive+0x50

Any help is greatly appreciated.

Edit:

No viruses detected on any scans. The explorer instances will appear even if I am not looking at any files or folders. As for the type of files and folders I am browsing...? Just regular files. The issue is happening as I'm typing this and I have no folder browsing instances of windows explorer open (the processes are still there of course).

Software open on my computer while it's occurring:

• Google Chrome
• Visual Studio 2017
• Outlook 2013
• Tableau
• Paint
• Task Manager

Upon closing them all (except Task Manager) the processes still persist.

Edit 26-Feb-2019:

I currently have two explorer.exe threads using 15% CPU each. If I look at the disk activity in Resource Monitor I see nothing being used by either.

Windows 10 Build: Version 1809 (OS Build 17763.316)

---

Edit 20-Nov-2019:

After continuing to experience this issue further, it seems to be related to zipfldr.dll. After disabling the built in .zip functionality in Windows, I've yet to experience these CPU spikes. To confirm you have the same issue, run procexp.exe and view the Stack of the explorer.exe process, if you see a bunch of zipfldr.dll instances, you're likely suffering from the same fate.

Relevant links:

Explorer.exe high CPU - accessing zips on a network share

https://www.thewindowsclub.com/disable-windows-built-in-zip

In case the links die: Create a .reg file with these exact contents, run it and this will disable the default .zip handling of Windows 10. Keep in mind that this comes with the caveat that you cannot click into a .zip file like a folder. Always back up your registry before doing something like this, or even better create a system restore point.

Windows Registry Editor Version 5.00
;———————————————
; Disable .ZIP folders
;———————————————
[-HKEY_CLASSES_ROOTSystemFileAssociations.zipCLSID]
[-HKEY_CLASSES_ROOTCompressedFolderShellExStorageHandler]
[-HKEY_CLASSES_ROOTCompressedFolderCLSID]
[-HKEY_LOCAL_MACHINESOFTWAREClassesSystemFileAssociations.zipCLSID]
[-HKEY_LOCAL_MACHINESOFTWAREClassesCompressedFolderShellExStorageHandler]
[-HKEY_LOCAL_MACHINESOFTWAREClassesCompressedFolderCLSID]
;———————————————
; Disable .CAB folders
;———————————————
[-HKEY_CLASSES_ROOTSystemFileAssociations.cabCLSID]
[-HKEY_CLASSES_ROOTCABFolderCLSID]
[-HKEY_LOCAL_MACHINESOFTWAREClassesSystemFileAssociations.cabCLSID]
[-HKEY_LOCAL_MACHINESOFTWAREClassesCABFolderCLSID]
; End of DisableZipFolders.reg

Answer 1

From what I can tell, the thing causing this issue was actually the Show all folders navigation pane option in Windows Explorer. If I disable this option, I don't see any obscene CPU usage. If I turn it back on, and open a new Windows Explorer instance, it will immediately start consuming about 15-20% CPU and doesn't seem to stop. Maybe this has to do with the folders that are shown in the navigation, however, I've disabled it for now and will update this answer if anything should change.

Your mileage may vary. This worked for me, I'll attempt to investigate why. If I were to hazard a quick guess, it may be due to Network/Shared Folders.