Windows Explored

The initial issue I was asked to look at started with Internet Explorer failing to gracefully exit. Instead, it would just hang and required manual intervention via the Task Manager to kill the iexplore.exe process. I connected remotely to the workstation and ran Process Explorer so I could examine IE’s threads for anything out of the ordinary. Sure enough, I saw the presence of a .tmp file:

This seems odd, because normally you don’t expect to find temp file trying to execute code in IE (or at least I have never noticed temp files running as threads in IE). Curious, I dump iexplore.exe from Process Explorer by right-clicking it and select Create Dump. I opt for a small dump so I can quickly copy it to my workstation and open it with WinDbg from the Windows Debugging Tools. I run !analyze –v –hang and confirm 64.tmp is the culprit:

I use lmvm to get some details on the file:

The file resides in the Temp directory (redirected to a unique folder in our case via the TEMP environmental variable). I go here and remove it, open Internet Explorer, and am able to close it without it hanging. Issue resolved.

Well, not exactly. When troubleshooting IE problems, I often turn to the About Internet Explorer to verify the version installed, but notice that the IE logo cannot be displayed, instead there is a red X:

I need to find out what else is amiss here. I examine the 64.tmp file for some printable strings. You can do this with any number of utilities, like Strings:

This temp file looks like a DLL itself, specifically the Microsoft Internet Account Manager Resources module (acctres.dll). Maybe I can get some more info on it by looking at it with another utility. I try out DLL Export Viewer hoping some of the functions may allude to its purpose and notice something that hints to why the IE logo is not displaying in About Internet Explorer:

Pngfilt is a DLL in C:\Windows\System32, otherwise known as the IE PNG plugin image decoder, which allows for the display of portable network graphics images, which is the type of image that the IE logo is. The png image decoder was probably relying on the now dysfunctional 64.tmp, and I should be able to locate its registration in the Windows registry. To find the registration, I can use Process Monitor to watch Internet Explorer as it starts up and then look for a registry operation that points to 64.tmp using find:

It finds a guid of {A3CCEDF7-2DE2-11D0-86F4-00A0C913F750} in HKU. Right-clicking the operation, I can jump directly to the registry key:

Think of HKU\SID_Classes\CLSID as containing the authoritative value for this guid for the currently logged on user¹. To find it’s default values, I can look in HKLM\Software\Classes\CLSID for {A3CCEDF7-2DE2-11D0-86F4-00A0C913F750}:


Looking at the default value or InProcServer for this guid tells us it is the CoPNGFilter Class\pngflt.dll, which explains why the IE PNG plugin image decoder component was not working. In fact, visiting any web page with png images, not just the IE logo in About Internet Explorer, would produce a red X:

Resolving both the hang and the missing PNG images was a simple matter of deleting {A3CCEDF7-2DE2-11D0-86F4-00A0C913F750} in HKU, HKCU, or HKCR and it should be restored from the default in HKLM^2.

As to how this all came about, I can’t say. I can only guess that something went wrong during some application install or update. Examining the temp folder revealed three other tmp files with the same modify\create date, so perhaps something related Java:

Since encountering this issue, I have seen it a few more times, almost always with the same jar_cache files left behind and a randomly named .tmp file (64, 65,, 77). Maybe some Java process was involved here and using some functions in the acctres.dll to do its thing and failed to clean up after itself. I also found the presence of java_install_reg.log file in the temp folder that had an identical time stamp of the .tmp files and jar_cache files. Examining the log files shows some “JNI” calls like:

One of my co-workers noticed the Java update icon in the system tray when this was happening in one of the cases he investigated, so perhaps after UpdateCheck kicks off and begins (or tries to begin) the process of updating, but fails, leading to the problem encountered in IE.

¹ This guid and its data would also exist under HKCU\Software\Classes\CLSID, which is a link to HKU\SID_Classes\CLSID. Additionally, HKCR is a merge of HKLM\Software\Classes\CLSID and HKCU\Software\Classes\CLSID, so HKU, HKCU, and HKCR would have precedence over HKLM.

² Since running into this a few times, I have encountered two cases where HKCR was not modified with a registration pointing to the .tmp files. Only HKU\SID_Classes\CLSID had been modified and curiously HKCU and HKCR were not (and so resolving in those cases involved only deleting {A3CCEDF7-2DE2-11D0-86F4-00A0C913F750} in HKU\SID_Classes\CLSID. This may be because some of the affected users were not administrators on their workstations and the process involved was running in the context of the limited user account (and thus the changes could not be made in HKCR until logoff?).