Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
is your command prompt running with elevated privledges? – Frank Thomas May 16 '13 at 12:11
@FrankThomas - makes no difference whether elevated or not. – Shaul Behr May 16 '13 at 12:32

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).

share|improve this answer
If that's the reason, then this link might be it. – harrymc May 20 '13 at 20:35

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"
share|improve this answer
I still have my memory leak, but the bounty is running out, and on the basis that you gave the most useful information of all other answers, I'll give you the bounty. :) – Shaul Behr May 26 '13 at 6:41

If I were you, I would do the following:

Download process explorer from here

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.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .