Take On Memory Corruption And Win

Debugging is one of the most difficult tasks developers face--even more difficult, some would argue, than writing code. And of the many different bugs developers encounter, heap corruptions can be the hardest to track down. These problems are caused by misbehaving code that modifies the part of memory where variables are stored or managed. They don't always show up right away and, as a result, are sometimes written off as so infrequent that they're not worth fixing. This can be a serious mistake.

After painstakingly analyzing crash dump data submitted to its Watson online error reporting service, Microsoft concluded that heap corruptions are one of the most common problems developers encounter, and so it came up with a Windows 7 service called the Fault Tolerant Heap.

At a high level, FTH monitors process crashes that result from heap corruptions. Once a process is identified as faulty, FTH puts a "shim" of additional bytes into that process. The shim pads the heap allocations--memory that's dynamically set aside at runtime--so the next time the process overwrites one of them, there's enough padding to avoid a crash. (See diagram at right.)

FTH's monitoring capabilities are implemented as a plug-in to the Windows Diagnostics Service wdi.dll (the dynamic linked library that provides support for analysis reports), which is hosted in the SVCHOST.EXE shared-service host. The plug-in monitors the Windows Event Log for entries related to application crashes and analyzes them to make decisions about how and how often an application is failing. The application-crash entries are written by the Windows Error Reporting infrastructure.

Once an application is known to be faulty because of a heap corruption, the fault-tolerant client is loaded into the process address space the next time it starts. The next time the allocation overwrites the heap block, the extra bytes ensure that the application survives the heap corruption.

An interceptor is used in each faulty process, so there are some performance implications when using FTH. But from a code perspective, the impact is minimal because the interceptor does little besides padding the allocation request size. The real expense comes from the additional memory that's being requested to mitigate the heap corruption.

The criteria the server uses to decide when to tag a process as faulty is configurable and stored in the registry under the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\FTH

FTH, by default, flags processes as faulty if they crash three times an hour. Once every seven days, it resets all monitoring and starts over to see if any applications have been fixed.

The final piece of information under the configuration registry key is the subkey State. This key exists only if the FTH has tagged at least one application as faulty. A new registry value is created and named after the full path of the application. The actual registry value is of type binary and therefore not directly interpretable, but this key can yield some insights into which applications have been misbehaving on any given system.

Take Heap Corruptions Seriously

So if FTH magically tracks heap corruptions, why bother investigating and fixing the code? If you suspect a heap corruption in your application, you must debug it rather than rely on the FTH to save your application. Here's why:

>> FTH doesn't fix all types of heap corruptions. Don't assume it will automatically fix yours.

>> Faults mitigated by the FTH are reported using the standard error-reporting channels.

>> Faulty applications use more memory because of FTH padding and negatively affect performance.

>> Tagging faulty apps leads to periodic resets and poor user experiences.

>> In certain environments, users may disable the FTH, and your application will showcase heap corruptions in all of their glory.

Properly managing the memory that the heap manager carefully parcels out can make the difference between an application being highly successful and a complete disaster. The net effects of heap corruptions can range from application crashes and random behavior to serious security problems.

Microsoft's FTH provides a safety net around applications that suffer from certain types of corruption at the cost of the additional memory. However, FTH doesn't protect against all types of heap corruptions, only those it determines are safe to mitigate. Based on this fact alone, developers shouldn't rely on FTH to handle their bugs. Instead, treat it as an additional step that will lead to better end-user experiences.

Mario Hewardt is the author of Advanced .NET Debugging. Write to us at [email protected].