As browser users go, I’m pretty savvy. I’ve been on the IE team for nearly half a decade, and I’ve been writing browser extensions for twice as long. I read networking source code for entertainment, I spend my free time writing a web debugger, and I maintain an IE troubleshooting guide for folks who encounter common problems.
Earlier this week, IE8 started hanging on a regular basis (on every 3rd or so startup) on one of my computers. There was no obvious rhyme or reason to the hangs; they’d happen when I opened a new tab or a new window, whether I clicked on a link from Outlook or ran iexplore.exe directly.
Now, as some of you know, when folks complain about IE crashes, the first thing I do is tell them to try running in No Add-ons mode. However, forgetting my own advice (because I didn’t recall installing anything lately), I didn’t think to try that. Instead, I saved some WinDBG .dmp files to debug later, and just let my frustration build.
Luckily, however, I soon encountered a previously unseen dialog box:
This is a new dialog box, introduced in IE8 to help prevent “Search Hijacking”—when a piece of software stomps over an unwilling user’s preferences and sets itself as the search provider. (You can learn more about Search Provider Protection in Frank Olivier’s blog post on the IEBlog.)
In this case, the dialog indicates that my default Search Provider had been changed by overwriting registry keys rather than using the API to request a change to the search provider. In turn, this was a clue that some program I’d installed was making unwanted changes to my browser. I chose to “Keep” my existing search provider using this screen, but decided to investigate how my search default was being changed.
Unfortunately, while there’s no good way for this dialog to pin blame on the hijacker, I knew that it was being triggered by new software on my computer, because I hadn’t seen this prompt over the last 18 months. This prompted me to remember that I’d recently updated my copy of WebShots Desktop, a program which periodically cycles my desktop wallpaper among various high-quality landscape scenes. (While Windows 7 natively includes a wallpaper-rotation feature, I use WebShots on the Windows XP machine I use for downlevel testing).
I was almost positive that I’d opted-out of all of the browser integration features offered by the installer, but concluded that perhaps I missed one. I took a quick look inside IE’s Tools > Manage Add-ons dialog, and sure enough, I saw an unexpected add-on:
The new DLL in the list, AGCore.dll, was installed by the new version of the wallpaper-changing program. (Confusingly, the DLL has the same name as the core DLL in Microsoft Silverlight, although it has nothing to do with Silverlight). I used Manage Add-ons’ Disable button to turn off the agcore.AGUtils add-on, and restarted IE. Sure enough, the crashes and hangs went away.
Curious about why this add-on was causing such problems, I took a quick look at it. It turns out that agcore.dll is a .NET Assembly which is exposed as a COM object, registered as a Browser Helper Object in IE.
I strongly discourage use of .NET to build IE extensions (for anything other than prototyping purposes), because .NET is not suitable for this use, as briefly outlined over on Raymond Chen’s blog. Beyond the framework-versioning problems, .NET incurs a significant performance cost at startup, and users demand that IE and its tabs start instantly. Extensions written in .NET cannot meet the performance expectations of most users.
The whole experience was a painful reminder that even non-malicious code can ruin your day. If you encounter crashes, hangs, or other unexpected behavior in IE, your first stop should be the Manage Add-ons screen.