Tweedle IExplore and Tweedle DExplore

I feel like I just visited Alice in Wonderland in order to resolve the following iexplore.exe (Internet Explorer 6.0 for Windows XP Professional SP2) and dexplore.exe (MSDN Library – January 2005) issues:

  • MSDN Library viewer would not display any pages even after reinstalling the entire library contents locally and performing a complete repair operation.
  • IE would do nothing whenever View Source was chosen from any page’s context (right-click) menu.
  • Trying to execute a Find command in IE would result in an Error: 49 “Interface not registered” error dialog instead of a successful Find operation.

The good news is that I was able to fix all three issues, but the bad news is that, IMHO, it was much to difficult a resolution to come by. So, here are the steps I took in some detail in case I encounter any of these issues again.

MSDN Library resolution:

  • I found several links online that talked about cleaning up one’s temporary internet files (TIFs). Apparently certain functionality in IE becomes disabled when TIFs reach a certain total size.
  • These links were in the context of IE (e.g. http://support.microsoft.com/kb/306907/EN-US) and I’d already cleaned up my account’s TIFs including all offline content, too–to no avail.
  • However, I did notice that other user account TIFs were at a reasonable size (i.e. much larger than mine were). So, I logged into those accounts and cleaned them up.
  • Unfortunately, I took another step before I saw expected MSDN Library (i.e. offline viewer (dexplore.exe)) behavior: I moved-out-and-moved-back (logging off and logging back in after both moves) the location of my TIFs to the default folder for TIFs (i.e. %UserProfile%\Local Settings). That is, I don’t know specifically if only cleaning up TIFs in other Windows user accounts on the same machine did the trick to restore dexplore.exe, if only recycling the location of the TIFs areas did the trick to restore dexplore.exe, or if both actions solved my MSDN Library woes. But at this point, problem number one was solved!
  • Aside: I did notice that moving my TIFs folder back to the default location triggered to Microsoft AntiSpyware Beta 1 alert dialogs of note: (1) one dealing with wininet.dll and (2) dealing with the change in location of the TIFs folder. (Perhaps wininet.dll was at issue beforehand, too.)

IE View Source resolution:

  • I ran across this Microsoft Support article within one of my search results on this topic (i.e. view source being broken): http://support.microsoft.com/kb/811102/EN-US. It talked about mshtml.dll, which got me to thinking about some recent development I’d been doing in .NET using the Microsoft Web Browser Control–perhaps I’d unregistered this important DLL by accident or otherwise caused its registration with COM to be incomplete or corrupted.
  • I re-registered mshtml.dll with COM in the Windows Registry (RegDB) as follows in a Command Prompt window: regsvr32 %windir%\system32\mshtml.dll. Viola! View Source works again!

IE Find resolution:

  • The approach to solving View Source in IE got me to rethinking the Find issue. Perhaps this, too, was related to incomplete or corrupt registration of additional DLLs employed by Internet Explorer.
  • So I dispatched Process Explorer and from it launched Dependency Walker to isolate what DLLs were loaded by iexplore.exe.
  • In the meantime, I ran across this second Microsoft Support article: http://support.microsoft.com/kb/281679/EN-US. The heart of its problem resolution statement involves registrating DLLs with COM (i.e. regsvr32 %windir%\system32\__XYZ__.dll, where __XYZ__ was one of the following DLLs in the following list (i.e. registration one at a time through the whole list in the stated order): urlmon.dll, shdocvw.dll, msjava.dll (skipped since I’m using a Sun JVM instead of the MSJVM), actxprxy.dll, oleaut32.dll, mshtml.dll (skipped since I’d already done this to fix View Source), browseui.dll and shell32.dll).
  • IE Find behavior was restored after actxprxy.dll’s COM registration was restored. (That is, urlmon.dll and shdocvw.dll don’t seem to participate in IE Find.) Just to be safe, I continued all the way through the list with regsvr32.exe.

Before determining that the above steps were the keys to successful resolution of my particular issues, I tried the following advice to no avail–and it’s what’s typically recommended online!

  • regsvr32 %windir%\system32\ole32.dll
  • Start | Run… | “sfc /scannow” – Windows File Protection check, which requires your original Windows XP Professional media (i.e. CD disc)
  • I came close to doing the following, but fortunately solved my issues beforehand: Start | Run… | “rundll32.exe setupapi,InstallHinfSection DefaultInstall 132 %windir%\inf\ie.inf”

Hopefully this post will save others’ time, too.

-Craig
http://craigrandall.net/
@craigsmusings