Need help tracking lsass.exe memory leak

Question

I'm trying to track down a memory leak in lsass.exe, following guidelines from article1 and article2, among others. I've gotten through setting up gflags for lsass.exe, rebooted, and found it has process ID 804. Now I run the command line:

umdh -p:804 -f:mylog.txt

This immediately spits back the error:

Error: Failed to enumerate process modules.

And the log file has nothing useful:

// 
// UMDH: version 6.2.9200.16384: Logtime 2013-05-16 14:49 - Machine=SHAUL-WORK-LT - > PID=804
// 
// Debug privilege has been enabled.
// OS version 6.1 Service Pack 1
// Umdh OS version 6.2
// 
// Preparing to dump heap allocations.
// Only allocations for which the heap manager collected a stack are dumped. Allocations whithout stack are ignored.
// The stack trace for an allocation is dumped as a list of addresses. They will be resolved to function names at compare time.
// 
// Connecting to process 804 ...
// Process 804 opened handle=48.

Where do I go from here?

Answer 1

Low-level tools like UDMH tend to be closely coupled with the OS. Seems that your UDMH is from a different OS:

// OS version 6.1 Service Pack 1     <<<< 6.1 = Windows 7
// Umdh OS version 6.2               <<<< 6.2 = Windows 8

Try getting UDMH that match your Windows 7 (6.1.7600).

Answer 2

As far as I can see, lsass.exe in Windows 7 is not leaking memory.

The article you quotes relates to Windows Server 2003 / Vista, where lsass.exe and csrss.exe leaked memory like crazy and accessed the disk non-stop, so were some of the main reasons that Vista was such a failure (or a smaller success than Windows 7). These bugs were fixed in Windows 7 (but never in Vista - don't ask me why).

If your version of lsass.exe does leak memory on a large scale, I would verify your computer with several well-known antivirus products, as well as run sfc /scannow.

As regarding umdh (even if debugging lsass.exe and is not really necessary), ensure that you have installed the latest Windows SDK and Debugging Tools for Windows.

If umdh still doesn't work with this latest version (or as was remarked by @Jonathan with the Windows 7 version), and if you run it in a Command Prompt (cmd) that is "Run as Administrator" (required even if you are the administrator), then Microsoft may have blocked its capability of tracing system-essential processes such as lsass.

One last try may be to use another privileged user account with the help of DevxExec (download) :

devxexec.exe /user:TrustedInstaller "umdh -p:804 -f:mylog.txt"

Answer 3

If I were you, I would do the following:

Download process explorer from here http://technet.microsoft.com/en-gb/sysinternals/bb896653.aspx

Open it up and right click on lsass.exe and go to properties. Jump to the threads tab and see if there are any threads with consistent cpu usage and go to the services tab and see if there are any services you don't recognise or any third party non windows related services using lsass, and stop them. Hopefully that will lead you in the direction of the cause of the problem.