Category: Tips

The Problem

I have a service which processes files sent in by suppliers and stores them in a folder structure which starts with the supplier’s Id in the system.

I wanted to have an extra column in explorer to show the name of the supplier so that I wouldn’t have to waste time looking it up every time I needed it. So I found a really simple way to make explorer show the information I wanted.

The solution

Inside each folder create a file called desktop.ini, with the following contents. To change the title use prop2 and change “Folder Title” with the actual title. To change the tags use prop5 and change “Folder Tags” with the tags:

You might want to make it hidden and system so you don’t see it. To do that navigate to the folder in the command prompt and type attrib +h +s desktop.ini. Also it says here the folder itself should be read-only, although on my system (Windows 10) it was not necessary.

Now in the root folder, right click the column headers and choose Title or Tags. You will get something like this:

See Filtering Well-Known Properties for other properties you can change.

If you are here than you probably have the same problem that I had. The same problem that some of my colleagues had. You upgraded a Windows 7 or 8 installation to Windows 10, and now every few seconds Explorer freezes up for about a minute and then restarts.

Like I said, I have seen a few computers with this problem, and after a lot of searching was able to get them all working. Usually it was some incompatible component, and the solution (or workaround) was simply to rename it. But the thing is, each one was crashing because of a different component. Each time it was a different file I had to rename. Sometimes looking in Event Viewer can give the answer. You should give it a look before trying the procedure below. But sometimes Event Viewer yields nothing. It only reports a crash in Explorer.exe, which doesn’t help much. So how can we identify what component is causing the issue?

Process Monitor

Process monitor is a really useful tool which shows file system, registry and network activity for processes in real-time. In one of the cases, I used it to get a hint as to which component was causing the exception. If you don’t already have it you can download it from the link above. After downloading and running it, if not already in the filters screen, click on the funnel icon or choose Filter -> Filter (Ctrl-L), to open the filters dialog.

We want to see only activity from Explorer.exe. To do that, choose Process Name, is, type Explorer.exe, choose include and click Add.

Now you should see a lot of activity from Explorer.exe, all with the same PID. The next time it crashes though, you will also see activity from a new PID, until the first one ends up dying. You can already click on the magnifying glass to stop capturing more activity.

Now scroll up until before all the Thread Exit calls, if you see an event Create Process for C:\WINDOWS\system32\WerFault.exe you can ignore it, and before that there should be some activity related to the exception handling. That’s not the exception itself though, so you still haven’t found the problem.

Double click one of the events. In my case it was one of the registry queries. Click on stack, to confirm this is related to exception handling. You should see something like this:

If you see near the top of the stack (bottom of the screen) UnhandledExceptionFilter + some hex number great, you are almost done. If you see KERNELBASE.dll + some number instead, it means the symbols aren’t being loaded. It’s still possible to continue, but it will be harder. If you already see the symbols or if you want to proceed without them you can skip the following section.

Setting up symbols loading

If you want to see the symbols but they aren’t being loaded, you need to find a copy of dbghelp.dll and, according to this post, symsvr.dll. You might have them in you computer already, or you can download Debugging Tools from Microsoft. You can try looking in C:\Program Files (x86)\Microsoft Visual Studio {version}\Common7\IDE or C:\Program Files\Windows Defender, or install Debugging Tools from here, which will install the dlls to C:\Program Files\Windows Kits\10\Debuggers\x86 or C:\Program Files (x86)\Windows Kits\10\Debuggers\x64. Once you found these dlls go to Options->Configure Symbols then on DbgHelp.dll path enter the path of both dlls. They should be in the same folder. Symbol paths should already have srv*http://msdl.microsoft.com/download/symbols. Now when you go to the stack trace screen you should see Loading Symbols near the bottom and the function names should appear next to the Module.

Identifying the misbehaving file

The last events before the process terminates are related to the exception handling, and not to what actually caused the exception. You have to search up the events, looking at their stack, until you find one that’s not related to exception handling. In my case there were a lot of similar events all of which were still under UnhandledExceptionFilter (or KERNELBASE.dll + 0xF540F if you don’t have symbols) until I reached an event which wasn’t.

All the events which still had UnhandledExceptionFilter in the stack trace are highlighted in blue. The first event before that is highlighted in yellow and in my case was unrelated to the problem. The one before that gave a hint where the exception might have occurred. Let’s see the stack:

Looking at the stack trace we can see that the system was probably loading ODBCCP32.CPL right before the exception occurred which is a strong indicator of where the problem was. To confirm my suspicion I renamed the file to ODBCCP32.CPL.BAK and finally the freezing stopped.

Using this procedure you can find the offending component, and you can look for specific solutions for it, such as updating it to it’s latest version. Or, you can just rename it “temporarily”, and your system will be usable.

Leave a comment if this helped you (or if it didn’t), and which was the component. It might save others some time!