A Windows 7 environment with Internet Explorer suddenly had a widespread IE8 failure. Clicking the IE icon did absolutely nothing. First thought was an Internet Explorer Add-ons, but running Internet Explorer in No add-ins mode still demonstrated the issue.
You might also think “Repair IE8” but unfortunately the Microsoft KB article on how to perform this only has how to reset IE8 settings in Windows 7; which requires ability to start IE in the first place http://support.microsoft.com/kb/318378
What’s going on!
So of course first I turn to Process Monitor (http://live.sysinternals.com/ProcMon.exe) and filter by process iexplore.exe
Woah! So many events and so many say SUCCESS!
The first key to successful ProcMon’ing is good filtering …
There first thing I notice is a lot of name not found events. So I filter to include only those events. Now I see some DLL files that are “name not found”
However these are not an issue as they are later found in the C:\windows\system32 directory. This is important to remember when looking at DLL files and Registry keys that show as “not found”
Typically DLL files are searched for in the same directory as the executable; followed by c:\windows\system32 or C:\windows\syswow64 (for 32-bit process on x64 Windows) So usually only DLLs that do not get found in system32 or syswow64 folder are truly missing.
What I do notice missing though are many HKCR\CLSID registry entries. For COM based applications such as Internet Explorer or Microsoft Office if a critical HKCR\CLSID key is missing it can be seriously bad news.
So I add a filter Path begins with HKCR\CLSID. Now these class root ID keys often have many subkeys that are unnecessary – so I am only looking for ones where the root key itself is missing:
On a non-broken machine I check this registry key. OK ieproxy.dll looks like a critical Internet Explorer file registration is missing!
OK so adding this key back in and now Internet Explorer is back in business…
But why did this key suddenly disappear in 1,000s of machines at once?
The Windows Application Log, Event ID 1034 offers a nice clue…A WebClient product got uninstalled… We also could have used the Reliability Monitor in Windows 7 to see all products/devices installed/uninstalled over a period of time…
Further testing proved uninstalling this product broke IE.
But it was now fixed…or so I thought…until I came across some sites failing…
Launching pop-up Windows resulted in blank page being displayed; or in some cases nothing happening at all:
While running ProcMon and launching this page I found a missing TypeLib key referring to Microsoft Internet Controls
And IServiceProvider registration key
So the final solution included adding the following keys back:
Windows Registry Editor Version 5.00
@=”Microsoft Internet Controls”
@=”C:\\Program Files\\Internet Explorer\\ieproxy.dll”
This can also be achieved by running the following commands from Administrative command prompt
regsvr32 “C:\Program Files\Internet Explorer\ieproxy.dll”
(This last one will throw an error; don’t worry about it)
If on x64 bit you may also need to include
regsvr32 “C:\program files (X86)\internet explorer\ieproxy.dll”
…and voila pop-up Windows are back in business…
Moral of the story:
Uninstallers please don’t mess with HKCR keys you are not responsible for. If created captured installs of MSIs pay particular attention to these keys if they get added in your package.
In this case a captured install detected a setup.exe changing these keys. i.e. the application added PSFactoryBuffer to this existing key
Then during the uninstall rather than just removing that value; the captured package removed the entire key.
Finally even better virtualize your apps with App-V or ThinApp or your favourite virtualization technology then your app will never touch IE in the first place!