我正在尝试跟踪内存泄漏lsass.exe，遵循以下指导原则第1条和文章2等等。我已经设置了 gflags lsass.exe，重新启动后，发现它的进程 ID 为 804。现在我运行命令行：
umdh-p:804-f:mylog.txt
这立即吐出错误：
错误：无法枚举进程模块。
日志文件没有任何有用的东西：
//
// 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.
我接下来要去哪里？
答案1
像 UDMH 这样的低级工具往往与操作系统紧密结合。看来您的 UDMH 来自不同的操作系统：
// OS version 6.1 Service Pack 1 <<<< 6.1 = Windows 7
// Umdh OS version 6.2 <<<< 6.2 = Windows 8
尝试获取与您的 Windows 7 (6.1.7600) 匹配的 UDMH。
答案2
据我所知，Windows 7 中的 lsass.exe 没有泄漏内存。
您引用的文章与 Windows Server 2003 / Vista 有关，其中 lsass.exe 和 csrss.exe 疯狂泄漏内存并不停地访问磁盘，这也是 Vista 如此失败（或比 Windows 7 成功程度小）的主要原因。这些错误在 Windows 7 中得到了修复（但从未在 Vista 中修复 - 不要问我为什么）。
如果你的 lsass.exe 版本确实存在大规模内存泄漏，我会使用几款知名的防病毒产品验证你的计算机，并运行证监会/扫描。
至于 umdh（即使调试 lsass.exe 并不是真正必要的），请确保您已经安装了最新的适用于 Windows 的 Windows SDK 和调试工具。
如果 umdh 仍然无法与此最新版本一起使用（或如 @Jonathan 所说，无法与 Windows 7 版本一起使用），并且如果您在“以管理员身份运行”的命令提示符（cmd）中运行它（即使您是管理员也需要），那么 Microsoft 可能已经阻止了其跟踪系统必需进程（如 lsass）的能力。
最后一次尝试可能是在执行DevxExec （下载）：
devxexec.exe /user:TrustedInstaller "umdh -p:804 -f:mylog.txt"
答案3
如果我是你，我会做以下事情：
从此处下载进程资源管理器http://technet.microsoft.com/en-gb/sysinternals/bb896653.aspx
打开它并右键单击 lsass.exe，然后转到属性。跳转到线程选项卡，查看是否有任何线程具有一致的 CPU 使用率，然后转到服务选项卡，查看是否有任何您不认识的服务或任何使用 lsass 的非 Windows 第三方相关服务，然后停止它们。希望这能引导您找到问题的原因。