Tracking Down Memory Corruption

For some time now, Internet Explorer has crashed for me in sometimes random scenarios. Before you get to bashing Internet Explorer, the main culprit behind Internet Explorer crashing is some sort of plugin or add-on. Therefore, with each crash, I use WinDbg to attach to the crash and do an analysis to determine a most likely cause. With the guidance of what it reports, I instructed Adobe┬áReader to not open in the browser, removed the Upromise Turbosaver for now, and removed the Skype plugin for Internet Explorer. With those changes alone, the Internet Explorer stability seems to have improved. There’s still something more happening though.

One issue that comes up frequently in the debugging analyses is memory corruption. This means that something running within the Internet Explorer process overwrote memory it did not allocate. That nature of this issue is that by the time Internet Explorer crashes, it is long after the problem causing the crash occured so either the debugging analysis cannot find a likely culprit or if it does, it is misleading.

The first step I’ve taken is to run the memory diagnostic tool in Windows to go a good way in ruling out random memory corruption due to hardware issues. That tool seems to indicate that my memory is working correctly. The next thing I’ve done is to use PageHeap on the 32-bit iexplore.exe process. Basically, this will make Windows allocate memory to Internet Explorer (and any of its extensions) in whole page increments. This will give each allocation plenty of padding so that corruption can be detected far sooner. Hopefully this will help figure out these random memory corruption issues I still experience with Internet Explorer.

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.