My website keeps crashing IE, can't debug

Question

I have a website that suddenly started to crash internet explorer.

The website loads and starts executing javascript but somewhere in there the machinery explodes. I don't even get a script error, it just crashes. I've tried to manually step through every single line of js with the built in debugger but then of course the problem doesn't occur.

If i choose to debug the application when it crashes i see the following message.

Unhandled exception at 0x6c5dedf5 in iexplore.exe: 0xC0000005: Access violation reading location 0x00000090.

The top 5 items in the call stack looks like this

VGX.dll!6c5dedf5()
[Frames below may be incorrect and/or missing, no symbols loaded for VGX.dll]
VGX.dll!6c594d70()
VGX.dll!6c594f63()
VGX.dll!6c595350()
VGX.dll!6c58f5e3()
mshtml.dll!6f88dd17()

VGX.dll seems to be part of the vml renderer and i am in fact using VML. I'm not suprised because i've had so many problems with vml, attributes has to be set in specific order, sometimes you cant set attributes when you have elements attached to the dom or vice versa (everything undocumented btw) but then the problems can usually be reproduced when debugging but not now :(

The problem also occurs in no plugin-mode.

Is there a better approach than trial and error to solve this?

Edit: Adding a console outputting every suspect modification to the DOM made the problem only occur sometimes. (the console is also implemented in javascript on the same page, i'm able to see the output even after a crash as the window is still visible) Apparently it seems to be some kind of race condition.

I managed to track it down even further, and it seems to occur when you remove an object from the DOM too quickly after it's just been added. (most likely only for vml-elements with some special attribute, didn't try further) And it can't be fixed by adding a dead loop in front of removeChild(pretty bad solution anyway), the page has to be rendered by the browser once after the addChild before you can call removeChild. sigh

Jumna

Just kidding - but, well, you might be able to craft an(other) exploit for IE from this. I mean you end up reading from some off memory location. Maybe you can get this to do something really bad. Also, a fully patched and up-to-date windows/IE should not crash from any website, no matter how wrong your code is. Maybe there is some place to report this? – Chick

Please send me a repro page or URL; I'm happy to have a look! (ericlaw @ microsoft). Thanks! – Suki

FYI, next time set your symbol server to the Microsoft Symbol Server to get a better call stack: msdn.microsoft.com/en-us/library/b8ttk8zy%28v=vs.80%29.aspx – Carnegie

Answer 1

(old question but important one)

I had a very similar problem - including lots of complex VML (from Raphael), and it looked near-impossible to debug.

Actually, it turned out the simplest low-tech approach was the best. It's an obvious approach: I'm writing here because sometimes when faced with an intimidating problem the obvious, simple solutions are the last a person thinks of.

So, simple old-school debugging: Lots of alert("1");, alert("2"); etc before and after every remotely demanding or complex call in my code, giving super-simple reliable breakpoints that don't rely on any features (e.g. developer tools) that might themselves crash out. Then, just see which number alert you get to before it crashes - the problem must arise between that alert and the next one.

Add more alerts until you narrow it down to the exact line. In my case, it was actually nothing to do with the complex VML - it was a for loop that, for some reason was continuing infinitely only on IE7.

Rupee

Yup. We get blinded by our fancy tools, yet very often the old techniques work better. – Grande

Answer 2

Stop using VML?

If you need stuff in IE that really can't be done by moving, scaling, cropping and replacing images, then consider using Flash, Silverlight or similar.

If your life depend on VML then read as much as possible about other peoples experience, that may ease the trial and error approach.

Orthopterous

Answer 3

Its a null pointer dereference non exploitable crash

Lauricelaurie

Answer 4

Make sure that your scripts are running after the DOMReady event occurs. IE is notorious for crashing when modifying the DOM before it is fully loaded.

In some instances IE might prematurely fire the DOMReady event. See more information on how to overcome this here and here.

Jewel

Don't think it's because of this because the problem can occur long after the page has been loaded and by user interaction. Will try to check this out more though as my onload initializer is a bit of a hack right now. – Jumna

Answer 5

Are you using JSONP in any form? Popular implementations like jQuery tend to try and clean up memory by deleting the script node from the DOM after it has run. I've seen that crash Internet Explorer in many cases. Never could figure out what other conditions needed to be around to cause that to crash. Too much stuff going on in my other pages.

Anyhow, if you're using jQuery.getJSON, check the following line in jquery source: (line 5556 on jquery 1.4.3):

 } else {
  // Garbage collect
  window[ jsonp ] = undefined;

  try {
   delete window[ jsonp ];
  } catch( jsonpError ) {}
 }

 if ( head ) {
  head.removeChild( script );
 }

You can safely remove that, or conditionalize it to only happen in non-IE browsers. Hopefully that helps.

Zygospore

Nope, not using JSONP or jQuery at all. – Jumna