7

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

Ninja rhino
  • 116
  • 1
  • 5
  • 1
    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? – zerm Oct 16 '10 at 14:37
  • 1
    Please send me a repro page or URL; I'm happy to have a look! (ericlaw @ microsoft). Thanks! – EricLaw Oct 18 '10 at 13:59
  • FYI, next time set your symbol server to the Microsoft Symbol Server to get a better call stack: http://msdn.microsoft.com/en-us/library/b8ttk8zy%28v=vs.80%29.aspx – Yuhong Bao May 20 '13 at 02:37

5 Answers5

4

(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.

user56reinstatemonica8
  • 32,576
  • 21
  • 101
  • 125
1

Its a null pointer dereference non exploitable crash

Sachin Shinde
  • 53
  • 1
  • 7
1

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.

aaaaaaaaaaaa
  • 3,630
  • 1
  • 24
  • 23
0

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.

sholsinger
  • 3,028
  • 2
  • 23
  • 40
  • 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. – Ninja rhino Nov 08 '10 at 16:40
0

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.

Mike Ruhlin
  • 3,546
  • 2
  • 21
  • 31