How You Help Us Improve IE’s Reliability

Over the past year, the
structured feedback
you provided while using the IE9 Platform Previews,

, and
Release Candidate
has been invaluable to helping us build the most reliable
version of IE ever. The error reports that you send us via
Windows Error Reporting
and other methods help us fix the most impactful
issues experienced by users. Your real-world browsing enables us to identify reliability
problems in ways that cannot be matched by internal testing.

In this post, we take you through our process of engineering IE9 reliability.
We describe the various channels you’ve used to send us feedback. We describe
how we categorize and prioritize the data to address the most impactful issues first.
We conclude by sharing data of our own that show how IE9 reliability has improved
since IE8.

We encourage you to keep sending feedback through our telemetry systems as you use
the final IE9 release. Ongoing error reporting allows us to continue to deliver
reliability improvements to IE9 through
future Cumulative Updates

Reporting the Crash through Windows Error Reporting

If you encounter
es in IE, features such as
Automatic Crash Recovery
help mitigate the impact of these crashes,
but we want to eliminate their occurrences in the first place. We use several different
mechanisms to gather information about the crashes. One of these mechanisms is Windows
Error Reporting.

For users who opt-into
Windows Error Reporting
, IE collects information about the state of the
browser when the crash occurs and packages the information into an error report.
This information helps developers debug the root cause and fix the crash. Internet
Explorer can also send error reports if you encounter hangs while browsing. We’ll
cover the topic of hangs in a future post.

Keep in mind that Microsoft
protects your privacy
when submitting error reports. IE asks for your permission
before securely transmitting error reports back to Microsoft.

Screen shot of "Internet Explorer has stopped working" alert
Windows Error Reporting dialog

Throughout IE9 Beta and RC, we used additional mechanisms such as the Send Feedback
Tool and Microsoft Connect to listen
to your feedback on IE’s reliability. These mechanisms may end up reporting duplicate
issues back to us but we internally de-duplicate reported issues. Your reports help
build a large and statistically significant volume of data that allows us to determine
the reliability issues that are meaningful to address.

Understanding How IE Crashes

Once we aggregate a full sample of crashes, we categorize the data based on the
source of the crashes. This helps us generally understand what areas are affecting
IE’s reliability more than others. We devote resources to driving improvements in
each category.

Pie chart showing distribution of crashes by category

The following categories contributed to reliability problems during IE9 Beta:

IE Code Bugs

Faults in IE code contribute to a sizable portion of the overall crash volume. The
ratio of IE crashes to third party crashes is higher in pre-release versions (Beta
and Release Candidate) due to the amount of new code introduced.


While add-ons are a
core part of IE’s browsing experience
, they are also the
primary cause
of reliability problems in IE. Add-on related crashes
typically occur upon opening a new tab or upon IE startup. Some add-ons
are incompatible
with newer versions of IE and may cause crashes.

ActiveX Controls

Many of today’s Web sites use
ActiveX Controls
like Flash, Silverlight, and QuickTime to display interactive
content and video. Since ActiveX controls are essentially Windows applications that
run in the browser, poorly-written controls can cause the browser tab to crash or

Graphics Drivers

transition to hardware accelerated graphics
is highly dependent on the quality
of the graphics card drivers in the ecosystem. We found that graphics card drivers
caused 41% of the crash reports we received from the Send Feedback Tool during IE9
Beta. These crashes manifest in similar scenarios as add-on crashes so they have
a very noticeable impact on regular browsing.

Other Third Party Software

A wide range of software programs, such as antivirus tools and custom download managers,
can affect IE’s reliability.

Drawing the “Failure Curve”

The next step is to organize the data from each category in such a way that we can
systematically investigate the crashes. We prioritize the issues using “failure
,” which are bar charts where each bar represents a unique crash and
the crashes are ordered from most frequently encountered to least.

After we construct the failure curve, we investigate each unique issue starting
with the most frequently occurring issues at the top of the curve. The issues in
the tail end of the curve are generally encountered in specific hardware and software
configurations. They may also be important to fix, but we start with the top issues
to ensure that we maximize the impact of our efforts.

Column chart showing occurrences of unique crashes

The above failure curve example shows how we’ve successfully addressed the top 50
crashes in IE code from since IE9 Beta.

Ensuring Reliable Experiences

Through the work we do on the IE team and with third party developers, we
continue to improve the reliability of browsing experiences by addressing a majority of reported crashes. This section describes how we
make the final push for each category:

Internal Reliability Issues

We log bugs for the most frequent crashes in IE code from the Beta and Release Candidate.
We address them as we continue to monitor the volume of data for new issues.

We also combine the various sources of telemetry to good effect. We use your Send
Feedback reports to help us reproduce the issues that we investigate via Windows
Error Reporting. A successful recreation of the crash helps developers zero in on
the root cause and helps testers verify that the crash is fixed.

The failure curve chart from above paints an accurate picture of the progress we’ve
made fixing IE issues. In total, we’ve fixed the top 85% of crashes in IE
code reported since IE9 Beta, and we’ll continue to combat the long tail in cumulative

The improvements in quality and reliability in IE9 are substantial. The results of
Stress and Longhaul tests
continuously running on the final IE9 release run 6-7 times longer than

Third Party Bugs

We work with vendors from around the world to address the top third
party reliability issues from the IE9 Beta and beyond. We use the
WinQual program
to share the error reporting information with vendors. We
ensure that they only have access to error reports relating to their own products.

Faulty add-ons or graphics drivers are known to cause IE to repeatedly crash in
important usage scenarios. There are two built-in mechanisms in IE that help us
work around these problems:

  • Add-ons: We use the
    Upgrade Advisor
    to disable any known incompatible add-ons so that you can launch
    IE successfully if you previously had one of these add-ons installed. When the Upgrade
    Advisor blocks an add-on upon startup, IE notifies you of the action and gives you
    an option to check for an update to the add-on.
  • Graphics Drivers: IE9 includes a “software fallback list” of known incompatible
    graphics drivers, compiled from error reports and from internal testing. If you
    use one of these drivers, IE will use software rendering instead of GPU rendering
    for accelerated graphics. Running in this mode prevents the drivers from crashing
    the browser.

So far, the error reports that you’ve submitted helped third party vendors address
some of the top crashes from IE9 Beta. We updated the software fallback list for
IE9 RC and streamlined the Upgrade Advisor experience (details to come in an upcoming

Your Feedback Matters Every Day

We followed the approach described in this post to address the top crashes across
IE and various third party components from IE9 Beta and IE9 RC, thanks to the error
reports and other types of feedback you contributed to us. The result is a high-quality
IE9 release as indicated by the record scores in Stress and Longhaul reliability.

Reliability engineering is a closed feedback loop. After the final release we will
use the feedback from an even larger group of users to continue improving reliability.
As the Web and the software ecosystem evolve, we’ll work to build an increasingly
reliable experience by shipping fixes to top problems through Cumulative Updates.

Thanks again for using IE9 Platform Previews, Beta, and Release Candidate and submitting
feedback in all its forms. Your contributions help make IE more reliable every day.

—Herman Ng, Program Manager, Internet Explorer

Comments (32)

  1. gtoeddie says:

    I just installed Explorer 9 on 2 HP computers I have with Windows 7 64-bit. PC 1 HP m9350f, PC-2 HP a4311f. Both PC were just reprogramed 2 weeks ago whit HP OEM Disc and working great. Last night installed expolrer 9. Open internet to Went to, Message at bottom of page said not responding, clicked reload page took about one minute to load. Then clicked another link and a new page opened and got a message stopped responding again. Clicked reload page and it SHUT THE COMPUTER DOWN. Restarted PC and showed Windows Shut Down Unexpectedly. Clicked Start Windows and Opened Explorer and went to norton website again. Same thing happened and it SHUT MY COMPUTER DOWN AGAIN. Turned on my other computer and opened Expolrer 9 for the first time clicked several links, stopped respoing just like the first PC and shut my PC down.  Uninstalled Explorer 9 from both HP Computers and everything works great again. I have been repairing computers for over 15 years. If a program can cause enough conflict to shut down your computer it can damaged the motherboard. I say don't install Explorer 9 it could cost you your computer

  2. anon says:

    gtoeddie, judging by your candor, spelling, conclusions and overall thought process. i think the problem may exist on the other side of the keyboard

  3. sukru says:

    Keep up the good work. Considering this, yesterday's post on auto-recover functionality makes more sense. While Microsoft is not the author of these 3rd party extensions, it is still held responsible for those.

    Btw comment is a spam…

  4. @gtoeddie:

    I don't understand how your situation has just gotten unnecessarily more complex than it should or could. Are you sure IE9 is the root cause of your issue? Or perhaps other related issues, such as graphic card drivers for example, could contribute to the situation you experienced.

  5. Herman [MSFT] says:

    @gtoeddie: Your problems may be caused by an incompatible graphics driver. See if you can find a newer version to update to. You can run IE9 in software rendering mode if the problems still occur. Refer to Frank's post for more information:…/getting-the-most-from-ie9-and-your-gpu.aspx

  6. Anonymous says:


    If the computer restarted suddenly, that is an indication a kernel panic occured. Since IE9 never runs in kernel mode, it is impossible for it to be directly responsible. The restart was could have been caused by your graphics driver failing which does run in kernel mode. Well, either that or your computer had some other issue and running IE9 was just a coincidence.

  7. Vaibhav Garg says:

    I have been using the IE9 beta ever since it came out as my primary browser. I was eagerly waiting for the opportunity to use the RC/RTM as well, but unfortunately, I have not been able to install the same on my desktop. I am running windows 7 x64. When I try to run the 64 bit ie setup, it prompts a restart and starts configuring updates. Then the screen says " failed to configure updates" and "reverts changes" . This happens about 2 or three times in a loop and then it quits. I am stuck with IE9 Beta. The double whammy is that now I cant roll back to IE8 as well with the only recourse left being reimaging the OS which I want to avoid.

    How can I send feedback on the same. I have seen the issue on other computers as well.

  8. @Vaibhav Garg: are you using IE9 RTM web installer (with around 3 MB in size) or standalone installer (with around 17-34 MB in size)? I suggest to use standalone installer and disconnect internet connection while updating IE9.

  9. hAl says:

    @Herman Ng

    Wil you be persuading some of the major laptop vendors to update their graphics drivers if they have laptops that do not have compatible drivers.

    I have noted that for instance a fully updated Dell and a fully updated Toshiba laptop did not have compatible graphics  drivers even though newer chipset drivers from Intel were available and after installing those drivers it was possible to swtich from software to hardware accellerated graphics.

  10. Mikeal says:

    To all blog readers that are annoyed and frustrated by the "Windows is checking for a solution to the problem" that interferes with your actual use of the computer here is how you correctly setup Windows to report the error but not waste any time searching for a solution that you know full well it won't find.


    Start Button > Type in the box: "choose how to check" (without the quotes) > Enter > In the dialog that opens be sure to set the last radio button: "Never check for solutions"


    I'm sure that if we all save this setting we can save thousands of countless hours of combined wasted time on this useless feature.


  11. alvatrus says:

    Thanks, Mikael. <insert sigh of relief here>

  12. I fear there is a "black hole" mostly invisible for developers:  Some IE9 help links do not work on my German windows 7 SP1 box, the help box opens with an "unknown topic for this platform" (or similar, I forgot the details) message.  I used "send feedback" in IE9 RC once for this problem, but obviously too late for the final IE9.

  13. Marcos Silva says:

    i dont have any incompatible drivers or viruses or third party apps i use vmware view for about 30 desktops and they all crash using ie9 i've downgraded to ie8 problem solved!!!

  14. Jobzky says:

    Poor Microsoft Developers! You just released you're IE9 without undergoing QA and testing! The browser crashed and usually hangs and does not respond. The worst thing we encounter  is when we are developing ASP.NET MVC web applications using Visual Studio 2010 and debug the applications using IE9 as default browser. IE9 hangs and does not respond after a minute of debugging. We have noticed that the solution explorer during debugging lists all javascript functions are listed. The IE9 is not productive for software developers. We have no choice but to revert back to IE8 which is pretty better than IE9 when developing web applications. Now it's a big question for us whether we are going to support IE9 with our sites knowing that this version is unstable. How we wish Microsoft underwent QA and testing IE9 before releasing the RTM.

  15. Herman [MSFT] says:

    @Mikeal: If you select the option "Never check for solutions", Windows does not report the error at all. What you really want to do is hide the dialog that shows up when the crash occurs. The reporting will still take place, you just won't see the dialog. Look for the DontShowUI registry value in the WER settings and set it  to 1 to not show any UI. You can learn more about WER settings here:…/bb513638(v=vs.85).aspx

    Sometimes Microsoft will ask you to send additional information about the error. If you want to send the additional information automatically, you can choose the  "Automatically check for solutions and  send additional report data, if needed" option from that dialog you launched.

  16. Talon says:

    @herman [MSFT] the window in question clearly indicates that WHEN reporting a crash, choose the option to CHECK for a resolution.  If the wording does not match the actual behavior please contact the Windows team and have them change the wording ASAP as it is SEVERELY misleading.

    That said if you are telling us that the only way to make windows crash reporting usable is to set a REGISTRY setting then there is something TERRIBLY WRONG with the crash reporting implementation in Windows.

    Since the method described by @Mikeal is exactly what every single user of Windows desires it seems highly appropriate that the interface should be designed this way by default – and that the current implementation is about as undesirable as one could possibly get.

    Until there is an update to Windows, I think we'll all be going with @Mikeal's solution.

  17. mike d says:

    I uninstalled IE9 because I had to use compatibility mode for it to work. I told my parents DO NOT install IE9. . ried Firefox and bingo website up in 30 secons. Uninstalled  IE9 and went back to IE8 no problems.

    I shouldn't have to use compatiblitiy mode to run IE9.

  18. Jobzky says:

    @Mike You are correct rolling back to IE8 is the best solution rather than waiting for Microsoft to release another build for IE9. IE9 sucks for both internet surfer and web developers. For us after rolling back to IE8, debugging Visual Studio 2010 web  applications make us easier. We hope that this will not happen again I mean Microsoft should undergo QA and intensive testing on its IE version both for debugging and surfing purposes.

  19. Vaibhav Garg says:

    @ Maximilian Haru Raditya

    I am using the 35MB or so installer. If not connected to the internet, the progress bar just stays put at about 20% point. Doesn't proceed at all even after 30 minutes of trying.

  20. @Vaibhav Garg: Then I have no idea what's going wrong, perhaps Windows issue. That's usually what I do when installing IE since IE8 and I never have any problem ever since.

  21. vic 123 says:

    When are you going to fix "gdpi.dll_unloaded" error which crashes my laptop very often and was hoping some sort of update will fix it.

  22. EricLaw [MSFT] says:

    @hmdmblahblahblah: Click the "Offline help" button at the bottom of the help window, and from the flyout menu, choose "Get online help".

    @miked: What outdated site did you find that required Compatibility View to work properly?

    @jobzky: As noted in this blog, IE9 owes its tremendous reliability to broad testing, thanks in part to beta feedback from millions of beta testers.

    @Vaibhav: That's an interesting finding. If you run Fiddler ( while the installer is running, do you see any failed downloads for a CAB File coming from a Microsoft server?

    @Talon: The "Never check for solutions" options is how you disable error reporting altogether.

    @vic123: gdpi.dll isn't part of Windows or Internet Explorer. It may belong to an outdated browser add-on. You should consider disabling unwanted addons using the Tools > Manage Add-ons screen.

  23. Jobzky says:

    @EricLaw [MSFT] broad testing? is that what you call broad testing? You haven't even tested developing web applications using visual studio 2010 that's why you don't know have bad is IE9 for developers

  24. @Jobzky: All of our test drive demos are developed using Visual Studio 2010. This blog's post contents are edit using Visual Studio 2010. Many internal Microsoft sites are developed using Visual Studio 2010. We most certainly know that IE9 works with Visual Studio 2010. We do not know what the problem is with your particular configuration but it's not a general experience.

  25. stan says:

    @EricLaw[MSFT] if the "never check for solutions" option completely disables error reporting which is the option that DOES do full error reporting but DOES NOT waste user time searching for a solution that won't be found? (without hacking the registry!)

    If the answer is "there is no option for that" then the question is, when will this be fixed to not only be available but to preferably be the default option?

    Windows 7: Action CenterProblem Reporting Settings <– in the REPORTING SECTION SETTINGS

    Subtitle: "Choose when to check for solutions to problem reports" <– mentions absolutely nothing about NOT sending in the report

    Selected Option: "Never check for solutions (not recommended)"  <– incredibly odd that the desired setting for maximum user usability is to go AGAINST the recommendation

    So as others have noted — if the dialog is incorrectly worded based on what it is actually doing — FIX THE DIALOG — do not attempt to tell us to hack the registry or live with an annoying dialog popup every time an app crashes because Microsoft designed it badly/incorrectly.

    Since we now know how to turn off the annoying dialog that makes us wait for no reason we're all certainly going to turn that "feature" off.  As a result it sounds like there will be no error reporting being sent to Microsoft.  I realize this is not the best scenario for Microsoft and 3rd party vendors awaiting crash details but we absolutely refuse to compromise our user experience due to a badly designed reporting system — I seriously hope this gets addressed in the next Windows 7 patch (both clarity in the dialog, and the option to REPORT, but NOT WAIT for a search response of ANY KIND)


  26. phoenix love says:

    hello dear team i'm just learn about cp i don't know well about english i'm learnmore im sorry i try to high to fixing by myself without  information you forgiveme & anytime if i got problem internet explorer please can you helpme or pls giveme content //ie,s reliability-ieblog thank you all of your team  /my  email nur

  27. Herman [MSFT] says:

    Thanks everyone for giving feedback on the error reporting user experience. We'll make sure this feedback is heard by the right people. Let me also further describe the error reporting process to explain the nuances.

    First, you can't only disable "checking for solutions"  because it's part of the error reporting process. The error report that you send to Microsoft contains information about the crash, the faulting application and its version. Using this information, Microsoft determines whether it is a known crash and whether a solution or workaround is available. If so, Microsoft sends the solution details back to you.

    The dialog's wording implies that most of the time is spent checking for a solution, even though it includes the time needed to package up the crash data and send it. However, even if you choose to hide the dialog, the application remains unresponsive because Windows needs to capture the crashing state of the application before it reports the error. If that's undesirable behavior,  then disabling error reporting completely is a reasonable decision. As @stan mentioned, it's not the best scenario for Microsoft and 3rd party vendors since this ultimately affects our ability to find and fix the crashes that you experience.


  28. mayres says:

    Hi Guys have loaded IE9 on to vsery weak laptop Medion Running Vista 32bit with1.5Gb Ram 1.4celeron processor everything on this laptop is Intel based except the wireless card no probs except with Graphics card which windows updated itself when IE9 was loaded

  29. Jobzky says:

    @Ted Johnson [MSFT] I dont know what kind of debugging you have made to your application and beside 99% of developers express the same sentiments how worst IE9 for developers. It's our final decision "Our sites and applications will not support IE9" .

  30. @Jobzky:

    > 99% of developers express the same sentiments how worst IE9 for developers

    It's such an interesting data you've presented. I never know if such exists. I wonder where did you get it? Are you sure the data source reliable enough to justify your claim?

  31. Dave says:

    @Herman [MSFT] – Re: 'First, you can't only disable "checking for solutions"  because it's part of the error reporting process.'

    There in lies the problem.  There is no reason why the 2 items should be tied together and that is what frustrates users to no end.

    I typically send at least 1 crash report to MSFT a week, yet never have I once wanted to "wait for a solution" especially when experience has shown me that there will never be one forthcoming.

    I would like to send in crash reports in the hopes that something does get fixed but I have no interest or intention of waiting for a search to come back (Even if there was a result!!!! (this is the KEY!))

    My apps all have an auto-update feature or I can go search for updates when I care about them.

    Unfortunately all we can do for now is completely disable the error reporting process in order to avoid the "checking slowly for zero solutions" dialog. 🙁

  32. Ooh says:

    @Dave: As Herman pointed out above, there is no separate "Checking for solutions" step. The error reporting is generally done in 2 steps: 1) Upload a minidump and analyze it on MSFT servers. 2) (Optionally, if determined necessary) Upload a fulldump to MSFT servers. The solution checking just happens in step 1, because it has to be done in order to determine whether step 2 is necessary or not.

    So probably the wording is technically inaccurate, but I can't think of better text for non-technical users. One question: how long does it take for you? For me it usually only takes a few seconds (~3s), so I really don't have a problem with it.

Skip to main content