Jump to main navigation, main content

Archived entry | Matt Wilcox .net

IE6 random crash, error in mshtml.dll

As alluded to in the previous post, over the last week I’ve had a nightmare of an IE6 random crash bug to deal with at work, with IE6 reporting an error in mshtml.dll. For those of you that care about IE6 bugs, please read on. For those of you that may have further insight, please do comment. For those of you that aren’t web developers, you should skip this post. It’s all nerdy from here on. If you’d like to live the bug with me, continue reading. Alternatively you can skip to the technical details and video of the bug itself right now.

The nightmare begins

Sticking with me? Excellent. Pull up a chair and help yourself to a coffee. *offers some coffee*

I had recently implemented a new CSS driven drop-down menu for a client, and in order to get the menu working on IE6 (which does not support the :hover pseudo-class on non-anchor elements) I had used the tried and tested csshover.htc file to get IE6 to behave like any modern browser in that regard. I tested the menu, as normal, in our browser suite and found that it worked well everywhere we tested. We put the change onto our staging server and got client approval to make the new functionality live. We launched the site live to the public.

Some time later we got a support request alerting us that someone using IE6 could not use the website in question because it was crashing their browser. A crashing browser is the worst thing you can have on a client site - it causes big problems, it’s not like having a display glitch, a crash means potential for lost revenue and annoyed customers. You don’t get a worse problem short of a disaster server-side. “A crash is impossible,” I thought, “we’ve tested it in IE6 already and it doesn’t crash”. So I loaded up Virtual PC, fired up IE6, and set about navigating the live site. All was well. I clicked around for a few minutes. The browser crashed. S***.

First things first when bug hunting - find out what triggers the bug. From there you can figure out what causes it, and then fix it with a work-around. Oh but it wasn’t going to be that easy. There was no set way to trigger the crash. It wasn’t a certain page, it wasn’t a certain image, it wasn’t a certain behaviour, menu item, or sequence of clicks. It was simply a case of “navigate around the site long enough, and eventually IE6 will crash”. It would crash on a page that had worked ten times immediately before. It crashed if you clicked really fast between pages, it crashed if you patiently waited for each page to load. It crashed on page load, it crashed on page exit. It even crashed when following a link to a plain-jane .jpg image - no XHTML/JS/CSS at all! But it would not crash predictably.

Being utterly unable to find a reproducible trigger, that left me with no option but to strip back the latest modifications piece by piece until the crash behaviour stopped. At that point I’d know what was triggering the crash. So I started stripping things out. As luck had it removing the .htc file was one of the first things I tried as it was the most obvious change. It stopped the crash, so as a quick fix we removed the file from the live site. The live site now had a fancy drop-down menu in all modern browsers, and defaulted to the old behaviour of loading a category page listing sub-categories on IE6. Thank god for graceful degradation, I thought. Crisis averted, live site ‘fixed’ in under four hours, now to restore the enhanced menu in IE6…

Here’s where it gets a bit crazy

With the client’s live site patched up to avoid crashes, and the trigger for the bug apparently discovered and eliminated, I set about using an alternative method to regain the drop-down menu for IE6 on our development server. I used the Son of Suckerfish method and got it working wonderfully. I tested the site for a while … and IE6 crashed. S***.

By this point I was well and truly sick of clicking around, and it was taking a long time to get the browser to crash, so I downloaded a lovely little add-on for IE6 called iMacro (there’s a version for Firefox), recorded a series of clicks as I navigated the site, and saved the Macro. From this point on I stopped manually clicking around and just set the macro to run sixty times through. The macro consisted of navigating through 18 pages. 60x18 = 1080 clicks. Crashes were a lot less common without the htc file, but they still happened. It took anywhere from 7 clicks up to 702 clicks before a crash occurred.

So I played around some more. I disabled the JavaScript. The site in question was using Resolution Dependent Style Switching to automatically alternate between an 800x600 layout and a 1024x768 layout. It was using conditional comments to fix layout bugs in both IE6 and IE7 for both versions. The high res inherited the low res styles through an @import to save on file size. And it had other JavaScript doing various things too. The potential for trouble seemed massive considering all the files loading other files and such, but these were all things that had worked flawlessly for nearly two years. I figured it had to be a JS issue causing some weird loading problem.

No luck, with JS disabled, it still crashed.

I removed all the JS files just to be double sure, and still it crashed. OK, it was not the JavaScript, and also could not have been the .htc file, considering that the crash was still happening (but far less frequently) even without the .htc file.

Must be the new CSS I put in for the menu - not too surprising given IE6’s failings with CSS in general. I removed the new CSS. It still crashed. I reverted to the old CSS files entirely. It still crashed. Incredulous, I loaded up a back-up version of the site prior to our latest modifications and ran that through the test macro. The old site, sans new menu and other changes, crashed. Oh s***.

It is fair to say that the old site was even harder to crash, but crash it assuredly did. It’s also fair to say that with the traffic that site gets there is no way that a crash in IE6 could have gone undetected and unreported for the almost two years that site has been live. It couldn’t have for even a week, the numbers going through it were simply too great - someone would have seen it and reported it. So something somewhere had changed either with the server or with a Windows Update client-side. We suspect the Windows Update option considering only the day before all our PCs at work had been hit with a batch of updates, and our server has had no settings change in the time of the site changes.

Having ruled out any of the new features, functions, or styles as being the cause it left me with stripping back the site architecture until crashes stopped. At that point I’d know where the problem was. JS had already been removed, so I removed the CSS. 1080 clicks - no crash. Ah HA!

I disabled CSS block by block, until I ended up with a screen.css (the main CSS file) consisting of absolutely nothing but commented out CSS and an @import at the top. It still crashed.

Must be something in the imported file. I looked at the imported file. It was essentially blank, a hold-over from a template, it had no actual CSS in it. I emptied the file anyway, and saved it. screen.css now was importing a totally blank file, and otherwise contained no CSS at all. It still crashed.

My jaw hit the floor.

It had to be HTML. It can’t be JS because there isn’t any being loaded. It can’t be the CSS because there’s no CSS being applied. I started stripping HTML out in huge chunks. Still it crashed. Until I ended up with what follows in the test case:

Making IE6 crash (randomly) with three one-line CSS files and two identical 9 line HTML files. All validated.

There appear to be two (perhaps three, I’ll get to that) elements required to get IE6 to randomly crash simply by navigating around a website for long enough. Take a look at the test case where, if you click the two links (essentially loading a new version of exactly the same page), IE6 will crash with an error in mshtml.dll

After much re-arranging and general fiddling it seems two things are required to trigger the crash:

  • the print media stylesheet must precede the screen media stylesheet in the head section
  • there must be an @import directive in the screen.css file (you can place it anywhere, it just has to be there. Doesn’t even need to load a real file)

Stopping the random IE6 crash

  • Don’t use @import in the CSS files
  • Move the print link to after the screen link

Option one worked but meant in my case duplicating huge swaths of CSS into another file (I’d been using the @import to load the normal ‘low resolution’ screen.css into the ‘high resolution’ screen_high.css - then over-riding rules where needed, thus keeping file sizes and load times down).

Option two was the least painful and it works all on it’s own too.

The mysterious third factor

Although I can reproduce the crash every single time on my VM’d IE6 at work - with the same VM and the same IE6 on my laptop, it does not crash. There are no differences between the Virtual Machines, and they both load the same website, the only difference is the hardware. My laptop is considerably faster than the work PC. So the “possible third factor” is either a slow PC being required to exhibit the crash, or a slow internet connection. The slow PC angle would seem to logically hold-up, other people have experienced the crash (as indicated by the initial support request from our client), and the PCs visitors are likely to be using on that site, when studying the demographics and audience, are likely to be old and slow.

Here’s a video of the crash in action using the tiny test code mentioned, and here’s a link to the actual code itself, so you can see the code and have a go.

Technical details and notes

The crash is known to happen in IE6 v 6.0.2900.2180.xpsp_sp2_gdr.070227-2254; Update Versions:; SP2;

It could not be replicated on an older IE6 running on a (slow) Win2000 machine with SP1.

In order to be certain it wasn’t a weird standards type problem I also stripped out the DOCTYPE, it still crashed. The missing DOCTYPE causes validation failure, but rest assured it still crashes with one in.


skip to comment form
  1. Rachael posted 8 days, 21hrs, 59mins after the entry and said:

    Ouch! Random bugs do seem the hardest to fix. I'm glad you sorted it out in the end, though it does seem like you went a little bit insane in the process! *hugs*

  2. Matt Wilcox posted 10 days, 20hrs, 0mins after the entry and said:

    hehe, thanks for the hug.

  3. Matthijs posted 17 days, 3hrs, 11mins after the entry and said:

    Wow, I feel your pain! That must have been a hellish time. Thanks for writing it down. Hopefully I remember it.

  4. Burt posted 317 days, 23hrs, 52mins after the entry and said:

    I almost had the same problem. I’m very glad I found your post. Otherwise this probably would have get me killed, because I don’t think I’d be able to come up with this crazy bug-fix. Thank you so much smiley icon: smile

  5. heidit posted 1 years, 91 days, 21hrs after the entry and said:

    we just stumbled across this *exact* problem last week, after moving our client to CSS driven drop-down menu. however we have the print css link after the screen link and IE6 still crash. do you know if the version of mshtml.dll matters? i am using 6.0.2900.5764. my IE6 is updated with SP3. the client will NOT move to newer version of IE or FF. *sign*

  6. Stuart Rutter posted 1 years, 152 days, 0hrs after the entry and said:

    Great post!! I have just had a similar issue testing for cross browser compatibility on a site. I thought initially that it was due to an unstable installation of the standalone version of IE (http://tredosoft.com/Multiple_IE). I am running Vista and the Tredsoft install only works on XP and previous OS versions. So to test in XP and IE 6 I am running Virtual PC with a Windows XP IE 6.0 image the random bug persisted till I removed the @import ref from and static call to a linked CSS. Thank you so much for the post.

  7. fantasmo posted 1 years, 183 days, 13hrs after the entry and said:

    I put skip-links into my page, which take the user to "content" and "footer".

    Strange is:
    IE crashes when I hit the tab-button to activate the skip-links (but SOMETIMES it works… for example: I do some other changes in the CSS, save it, change it back, save it… then it works and IE doesn't crash… then 5 minutes later I open my website again, and it doesn't work and crashes. But actually I didn't change anything, I just changed & changed back the CSS).

    It seems like it happens only in IE6.
    CSS and HTML is valid.

    Does anybody know this problem and can help?

    –my head-section and the css-files are in this order:
    basic.css - screen
    conditional comment for ie.css (

  8. Wes Groleau posted 1 years, 289 days, 2hrs after the entry and said:

    I have spent about a day on some similar behavior. Irritatingly, it is an application on the outside tht crashes for us but not for the vendor. I think it is a DIFFERENT problem from yours, but it is the same version of IE, so just in case, here's the one that is biting us:


  9. enjoy posted 2 years, 168 days, 18hrs after the entry and said:

    Thanks Matt!!! I have had a similiar issue. I tested the page under Virtual WinXP IE6 with installed Developer Toolbar. Each time i loaded the site, browser crashed. I uninstalled IE Developer Toolbar and all was ok.
    Then i removed all @import and make static links to css files. Then i installed IE Dev. Toolbar back on and no problem was there…

Associated media


From the archives

Other enteries filed under:

Web Development

Site information

Built with valid XHTML and CSS, designed with web standards and accessibility in mind. Best viewed in a modern browser [Firefox, Safari, Opera]

This domain and all content is a copy of my old website, for historical purposes only.