Troubleshooting Memory Leak on Domain Controller in Lsass.exe Process

What is a memory leak?
Application codes require that some amount of memory to be allocated, for storing values that will be worked with, and then deallocated when the code is finished working with them.

This is a concern to Active Directory administrator because we don’t always have full control over all of the code which runs in our environment. Sometimes some applications have the specific problem of not being able to deallocate their memory usage when running on or against a domain controller, resulting in a memory leak. There can be memory leaks in either kernel or user mode but application derived memory leaks are by nature user mode leaks.

In a memory leak situation more memory is allocated to new code executing over time but never resumed for reuse. So the amount of memory in use by a process is always increasing. Overt the time the amount of memory needed for further code execution exceeds the amount of memory available for further use, which results in the crash behavior that memory leaks often produce.

What are the methods to identifying whether something is a memory leak? 

There are multiple methods to track it down. Many of these tools require that you enable some tracking of resources in memory so that proper reporting of that memory usage can be done. Put very basically, once you know you have a problem with a particular process (this article assumes it is Lsass.exe) you need to find out what resource is leaking and/or what function(s) are doing it. To find out which resource is not being deallocated properly you will need to tag it, so to speak, so that those tags can be counted. Adding a tag in itself utilizes memory and other resources and as a result it’s not something that is enabled by default. Instead the Glfags.exe tool allows you to enable these tags to track the resource usage on “objects”. A better explanation than I can give is available at the above Gflags MSDN link above.

Let’s discuss some common tools and methods used followed by a new one that can give a nice readable report.

Two of the “traditional” methods are to use Performance Monitor (known as perfmon) or the User Mode Dump Heap (UMDH) tool to identify the leak. Memory usage in these tools is referred in bytes and typically tracked by seeing an increase in the number of private bytes used by a process.

The purposes of this troubleshooting discussion the process in question is Lsass.exe, which runs in Active Directory code. We won’t be going into step by step detail on how to use Perfmon or UMDH to troubleshoot a memory leak since the MSDN article does it well.

Another method is to use Poolmon. Poolmon is very useful, it can display outputs of Gflags.exe-enabled tagged memory and very often used for finding kernel mode memory leaks.We won’t be going into step by step detail on how to use Poolmon to troubleshoot a memory leak, however the MS artilcle explains it well.

Apart of above mentioned traditional tools that we use very often there is one more tool that provides a nice redable report. That tool is called the Debug Diagnostic Tool which can be downloaded from here. This tool is commonly referred to as DebugDiag . It is a great tool that we can occasionally use for troubleshooting Directory Services issues. In this scenario it is useful to use the tool to gather sequential memory dumps and then have DebugDiag generate a report from them which will tell you about any perceived leaks.

So, first we need to run it to gather the dumps of Lsass.exe while the issue is occurring. Make sure only do it when you are in need to track down a problem, because it is very persistent and can degrade the system performance. Here are the steps to follow:

1)      Startà Programsà IIS Diagnostics (32 bit)àDebug Diagnostics Tooà Debug Diagnostics Tool.

2)       Select Memory and Handle Leak Rule, and then click Next.

3)       Select LSASS.EXE in the Select Target dialog and then click Next.

4)       In Configure Leak Rule dialog you can specify a warm-up time. However, in most cases we should instead click the Configure button under “Userdump Generation”.

5)       In the Configure Userdumps for Leak Rule dialogue which appears make sure that the Auto-create a crash rule to get userdump on unexpected process click on the radio button for “Generate a userdump when private bytes reach” to select it.  The default is 800Mb.  Let’s change that to 1000Mb, and select to do additional dumps every 50Mb thereafter.

6)       Click Save & Close.

7)       Click “Auto-unload LeakTrack” to add a check mark there.

8)       Click Next, and Next again.

9)       Click Finish on the Select Dump Location And Rule Name windows. The Userdump Location can be changed here. Note The status is now active. The Userdump count will increase every time that a dump file is created. The default dump file location is C:\Program Files\IIS Resources\DebugDiag\Logs.

Next is to generate the report. To do that simply open DebugDiag, add the files you gathered with above steps, the Add Files button, choose “Memory Pressure Analyzers” and click the Start Analysis button. Once that analysis script is complete you will have a handy detailed report outlining what code appears to be leaking.

Above is discussed because if we see the DC’s performance steadily decrease over the time, followed most likely by their crashing, rebooting and starting the cycle all over again. The motto here is to provide details about the tools and to know how to understand and identify the issue to track it for the root cause and then you can fix it.