![需要帮助跟踪 lsass.exe 内存泄漏](https://linux22.com/image/1363534/%E9%9C%80%E8%A6%81%E5%B8%AE%E5%8A%A9%E8%B7%9F%E8%B8%AA%20lsass.exe%20%E5%86%85%E5%AD%98%E6%B3%84%E6%BC%8F.png)
我正在尝试跟踪内存泄漏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 第三方相关服务,然后停止它们。希望这能引导您找到问题的原因。