Get Internet Explorer and Google Desktop divorced and they will live happily ever after

  Every once in a while, you get these annoying application crashes for which you do not seem to find the reason. For these end-user applications, we may think of 3 distinct kinds of crashes from a timing perspective:

o An exit crash - aside from a dialog in which you are invited to terminate your application, usually these are innocuous, in the sense that you were already through with what you were doing and any data to persist was probable fully saved by that time;

o A startup crash - if it's a consistent crash, this means you won't be able to use your application at all. See the bright side of it, though: you won't be losing any work due to that application lack of stability;

o A usage crash - this is probably the most dangerous kind, in which you are bound to losing your time and work, if you have any unsaved data by the time the application crashes.

 

  Recently, I was glad to help someone whose Internet Explorer was crashing when loading every single web site. He needed his IE as he was using some Line of Business applications which wouldn't load on other browsers.

 

  As this was a pretty consistent crash scenario, it was extremely easy to get a memory dump for that crash. First, however, and as a problem solver (according to my job description), I needed to rule out as much variables as possible. Well, there weren't many variables, in fact I found just one: was IE crashing without any add-ons?

 

  How can one check that? Well, Windows gives you a link to a "plain" IE with no add-ons under Accessories, System Tools. It's not as plain as one would expect, though, as you'll see below.

 

Internet Explorer with no addons

  The cool thing about it was that IE would keep consistently crashing, even after taking add-ons out. So, the next step was to take a memory dump synchronously with whatever condition was causing it to crash.

 

  As it is a consistent crash on a single application, WinDbg can be used to open Internet Explorer and then, simply by browsing a web page, it would run into that crash condition. Here's how to do it.

  

WinDbg launching IE

  I'm using the -extoff argument, as I already know that it crashes with the add-ons disabled. After having launched the browser via the debugger, there were some modules being loaded and then a breakpoint was hit. This is fine, I just hit g or F5, as there are no further instructions needed in this case to ensure the condition is met.

 

  The following step was to navigate to some randomly chosen web site, such as www.google.com and *kaboom* , WinDbg was breaking into that access violation and gave me a chance to dump it. Great!! So as to ensure that every evidence is in that dump, I issued the following command:

  .dump /ma C:\temp\IE.dmp

 

  So, what was in that memory dump? Well, one of my favorite commands for looking at stack traces is kbn200 and with this single command, I was able to pinpoint a probable cause for the crash.

 

0:000> kbn200

# ChildEBP RetAddr Args to Child

00 0012e2c8 4369b64e 03ddf4e8 03ddf4b0 4365122f mshtml!CCalcInfo::Init+0x2f

01 0012e2d4 4365122f 00001abd 03ddf4b0 0012e468 mshtml!CCalcInfo::CCalcInfo+0x1d
02 0012e388 436474cf 00001ae4 ffffffff 00000000 mshtml!CDisplay::WaitForRecalc+0x24

03 0012e3c0 4369a45a 00000000 00000000 0012e468 mshtml!CFlowLayout::Notify+0x76f

04 0012e3d8 4369a4db 03def858 0012e468 001b8b70 mshtml!NotifyElement+0x45

05 0012e438 4368dc54 03def858 001b8c30 03def858 mshtml!CMarkup::SendNotification+0x4c

06 0012e454 4369a921 0012e468 03def858 001b8d48 mshtml!CMarkup::Notify+0xcc

07 0012e4a0 4363ba2f 0000000f 00000000 00000000 mshtml!CElement::SendNotification+0x3b

08 0012e4c0 43720148 00000001 438dc0c8 0012e55c mshtml!CElement::EnsureRecalcNotify+0x4a

09 0012e4e8 437200a9 0012e500 00000000 00000000 mshtml!CElement::GetBoundingSize+0x2a

0a 0012e50c 4100628d 03def858 0012e55c 00000000 mshtml!CElement::get_offsetHeight+0x61

WARNING: Stack unwind information not available. Following frames may be wrong.

0b 0012e590 41006219 00000000 00000000 00000000 GoogleDesktopIE!DllUnregisterServer+0x3114

0c 0012e5c4 41005789 00198ac0 00000000 0012e624 GoogleDesktopIE!DllUnregisterServer+0x30a0

0d 0012e628 41005165 00198ac0 00000000 00198ac0 GoogleDesktopIE!DllUnregisterServer+0x2610

0e 0012e678 41004f91 00192034 00000000 00198af4 GoogleDesktopIE!DllUnregisterServer+0x1fec

0f 0012e694 41003673 0008094c 00000113 0000000d GoogleDesktopIE!DllUnregisterServer+0x1e18

10 0012e6e0 7e418734 00198af4 00000113 0000000d GoogleDesktopIE!DllUnregisterServer+0x4fa

11 0012e70c 7e418816 001aba18 0008094c 00000113 user32!InternalCallWinProc+0x28

12 0012e774 7e4189cd 00000000 001aba18 0008094c user32!UserCallWinProcCheckWow+0x150

13 0012e7d4 7e418a10 0012e7fc 00000000 0012e818 user32!DispatchMessageWorker+0x306

14 0012e7e4 42f9ee7a 0012e7fc 0014d730 0014f980 user32!DispatchMessageW+0xf

15 0012e818 42f9ab4c 0014f358 0012e848 42f9bbbb ieframe!CBrowserFrame::FrameMessagePump+0x189

16 0012e824 42f9bbbb 00000000 00000000 0014d730 ieframe!BrowserThreadProc+0x3f

17 0012e848 42f9bb09 16c0000a 0014d730 00000000 ieframe!BrowserNewThreadProc+0x7b

18 0012f8b8 42f9b9b9 0014d730 77f648d4 00000000 ieframe!SHOpenFolderWindow+0x188

19 0012fae8 0040147c 00146a90 0000000a 00410070 ieframe!IEWinMain+0x2d9

1a 0012ff2c 00401317 00400000 00000000 00020a3c iexplore!wWinMain+0x2c1

1b 0012ffc0 7c817067 7c911440 01f3f55c 7ffde000 iexplore!__wmainCRTStartup+0x150

1c 0012fff0 00000000 00402e45 00000000 78746341 kernel32!BaseProcessStart+0x23

 

  Of course, I'm lacking the symbols for this module named GoogleDesktopIE, and that is why it seems to be calling DllUnregisterServer in a recursion-like fashion. As you can see from the offsets which are following those calls, they are extremely large for a single function, meaning this was the closest symbol found for that module, probably out of a few more in that DLL.

 

  This evidence was pretty good for me. Apparently, there was external code running within IE, even though the add-ons had been disabled when launching the browser. I quickly ran a command to describe the module, as follows:

 

0:000> lmvmGoogleDesktopIE

start end module name

41000000 4101f000 GoogleDesktopIE (export symbols) GoogleDesktopIE.dll

Loaded symbol image file: GoogleDesktopIE.dll

Image path: C:\Program Files\Google\Google Desktop Search\GoogleDesktopIE.dll

Image name: GoogleDesktopIE.dll

Timestamp: Fri Mar 03 08:14:13 2006 (4407FAD5)

CheckSum: 00022EFC

ImageSize: 0001F000

File version: 0.0.0.0

Product version: 0.0.0.0

File flags: 0 (Mask 0)

File OS: 0 Unknown Base

File type: 0.0 Unknown

File date: 00000000.00000000

Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0

 

  After having collected this information, I got back to the user with the suggestion to temporarily disable Google Desktop and by having done that, he was then able to successfully browse every website.

  What else could I do to wrap all of this up? Well, I can either suggest trying to update to a newer version of Google Desktop or point you out to Windows Search, what do you say? J

 

  See you soon,

 

      Manuel Oliveira