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.
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.
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,
Comments
Anonymous
October 13, 2008
Yes Google Desktop is a part of the stack, but actual crash happen in CSS code of IE: mshtml!CCalcInfo::Init Was GDS a reason of the problem or it just uncovered problem in CSS handling - we don't know....Anonymous
October 16, 2008
tarasul, I totally agree with you that the crash happens there. Usually, crashes happen at the lowest "leaf" levels of any stack, but that doesn't mean that the upper levels of that stack were making proper usage of that functionality, right? :-) The crude proof of that was that by removing GDS from the mix, we did get a healthy IE... I hope you agree with me on that :-)