The way PageHeap works is that when a program asks for memory, Windows will give it a whole page of memory marking the rest of the page as restricted. This makes it far more likely for buffer overflows and other issues corrupting the heap to get caught when they happen instead of causing trouble down the line.

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.