The Case Of The Hanging Explorer
This is an old case from XP days, back in 2011. And a perfect example of David Soloman’s saying “Check Process Explorer AND Process Monitor”. It’s possible the cause will show in one but not the other as happened in this incident.
We had several users that would try to access network shares and then Explorer would hang for minutes. Eventually populating all the files that were on the share and giving the user access. This wasn’t always happening so when it did, instead of giving me time to troubleshoot I was ordered “Just rebuild the machine”.
Annoying. That isn’t fixing the issue, it’s just delaying it until it happens again. It was deemed quicker than finding out what was causing the issue. I disagreed. Having kit sat on the shelf waiting to be swapped out was all fine and good, but it still wasted their time. As they had to login to a new machine, set other settings up, wait for updates if the standby machine hadn’t been update recently etc.
The only troubleshooting I’d been given time to do was using Process Explorer. I could see Explorer running at 50% every time the issue happened. But why?
FINALLY, the day came where my manager had the issue and she was going on leave for 2 weeks. “Alright, use my laptop to see what you can find”.
Did you read that? Laptop, that was a key, all the users affected were on laptops. Hmm.
So when a process starts its made up of threads and stacks. So although it looks like “Explorer” is running at 50% and Task Manager showed this, Task Manager won’t show you the threads of stacks. I was able to reliably recreate the issue, finally so ran Process Monitor. Nothing. Just filtering Explorer at the time didn’t show anything obvious.
So I turned back to Process Explorer. Let’s look at the threads. Bingo.
A .dll that isn’t explorer.exe is running within the thread and it’s actually that .dll that is running at 50% NOT explorer.exe as crappy Task Manager shows. This is why Task Manager, even in Windows 10, is pretty useless.
PGP. That is familiar. That’s are encryption software we use on the laptops. We see this by clicking Module which takes you to the .dll’s properties.
So is this .dll important? We can’t not encrypt the laptops. Maybe there’s a patch. Despite it showing as PGP Corporation, Symantec had already bought them out at that point. So I did a Google search. And we find this
https://support.symantec.com/en_US/article.TECH149635.html
It states there are rare issues where this .dll can cause an issue and the work around is to unregister the .dll
Is that safe? Yes, all the thing did was search network drives for files that had been encrypted with PGP so it can then change the icon to show it’s encrypted. Pointless!
So any user that then ran into the issue I’d connect to their machine, run CMD as admin, then run the unregister command
regsvr32 /u PGPfsshl.dll
And that’s it. Explorer would no longer hang for minutes and the user could carrying on with their work. All within 5mins. 5mins compared to swapping out their laptop with a replacement. And that is why it is helpful to give your engineers time to find the cause of a problem and then a solution or work around. As most often, that can be a quicker fix that just a rebuild.
