问题标签 [umdh]

为了调查我的应用程序中的内存构建（Windows平台上的本机代码），我做了以下

1) 在迭代中运行测试用例

2) 在每次迭代后转储 UMDH，然后在某些迭代之间进行比较，以查看调用堆栈中的内存模式。我需要一些关于以下数据的帮助，我需要解释这些数据

a) 在 diff 日志的最后，我发现类似这样的总增加 == 86928 请求 + 38080 开销 = 125008 这里到底是什么开销？如果我将所有分配加起来并扣除解除分配，我会得到一个接近 #requested 数量的数字。我无法计算间接费用数字。

b）需要的另一个帮助是下面的调用堆栈是调用堆栈的一部分的快照

该抵消的意义是什么？我没有找到任何解释这一点的文件。

c) 在该时间间隔内，perfmon 捕获的私有字节中的增量如何与调用堆栈中的增量相关？

我正在尝试隔离 Windows 上本机代码中的内存泄漏。

我运行了测试用例的多次迭代并将 DebugDiag 附加到进程以收集有关可疑泄漏的信息（通过 PerfMon 中的多次运行确认内存泄漏）。

DebugDiag 指出了可疑的调用堆栈，例如

我已经正确配置了符号，现在我想知道如何从调用堆栈中提取更多信息。

1. UMDH 日志在其差异日志中也有行号（带有文件名）。但是在 DebugDiag 报告中，我没有找到这些函数的任何行号。如果函数真的很长，那么仅通过查看调用堆栈而没有行号就很难描述上下文。有什么方法可以从 DebugDiag 日志中提取函数（文件）的行号？

2. 我想知道的另一件事是module!function调用堆栈中每个条目的十六进制偏移量的重要性。

3. 调用堆栈中的分配大小是多少？是每次执行此调用堆栈时尚未释放（因此泄漏）的分配内存吗？

4. 有关 DebugDiag 功能的综合文档的任何指针？

我正在尝试学习如何使用 umdh.exe 解决内存泄漏问题。为了做到这一点，我编写了一个示例应用程序：

编译（发布），配置好umdh.exe：

1. 设置 _NT_SYMBOL_PATH= http://msdl.microsoft.com/symbols/download;C :\TestProjects\HelloWorld\x64\Release;
2. gflags.exe /i HelloWorld.exe +ust

然后做了实验：

1. HelloWorld.exe 10000 1000
2. 等到它停止@first getchar
3. umdh.exe -pn:helloworld.exe -f:c:\first.log
4. 继续执行，等到它停止@第二个 getchar
5. umdh.exe -pn:helloworld.exe -f:c:\second.log

我注意到无论我调用哪个参数，无论是 100 个分配还是 1000 个分配，first.log 和 second.log 看起来都非常相似（针对不同的实验）。

6. umdh.exe -dc:\first.log c:\second.log -f:c:\result.log

然后我得到唯一只有17 个分配的堆栈（而不是预期的1000）：

更新：TaskProcess 显示私有字节和提交大小都在预期值上增长。

UPDATED2：DebugDiag 正确显示了 10000 个分配和一些指向正确位置的采样调用堆栈的泄漏。

知道我做错了什么吗？

谢谢！

我正在调查用 C# 和 C++ 编写的应用程序的内存泄漏。一旦我使用 PerfMon 日志和 WinDbg/SOS 调试将它隔离到几个 C++ 组件，我尝试使用 UMDH（使用 +ust 启用 gflags）来比较快照并找出哪些堆分配正在泄漏内存。

最后，通过手动审查代码发现了泄漏。下面的示例代码片段。

我想知道为什么 UMDH 没有抓住这个？UMDH 从未在比较日志中将此作为问题报告。WinDbg 堆命令会帮助指出泄漏吗？

我有一项服务随着时间的推移间歇性地开始吞噬服务器内存，需要重新启动才能释放它。我用 gflags 转为 +ust，重新启动服务，并开始拍摄预定的 UMDH 快照。当问题再次发生时，资源管理器在工作集和私有字节下报告了多个 GB，但 UMDH 快照仅占进程堆中的几个 MB 分配。

在 UMDH 快照文件的顶部，它提到“仅转储堆管理器收集堆栈的分配”。
当指定 +ust 标志时，进程中的分配怎么会没有痕迹？

如何找出这些 GB 的分配位置/方式？

我正在使用 UMDH(x64) 来测试内存泄漏。我的代码既没有经过 FPO 优化，也没有使用定制的分配器。它只使用“新”运算符。

在 Gflags(x64) 中为正在测试的图像启用了“创建用户模式堆栈跟踪数据库”。

我在非泄漏情况和泄漏情况下都使用 UMDH 跟踪了我的应用程序，并在这两种情况下都获得了日志。

并将日志与 UMDH 进行比较。从顶部的注释行可以看出，它选择了正确的 pdb。

问题：

调用堆栈不显示我的代码堆栈。它只是跟踪通用 Windows 函数名称。我在 x64 中尝试过调试和发布版本。我错过了什么吗？

获得的代码和差异跟踪如下：

我正在研究在 32 位 Win 7 上运行的应用程序的内存，该应用程序使用混合模式（VC++ 和 C#.net）构建

我已经通过以下步骤尝试分析泄漏的原因：

1. 在 GFlags 中启用用户模式堆栈跟踪数据库

2. 通过使用 UMDH.exe，我运行了 2 个快照之间的差异，我看到最高的内存分配是

   它只包含一行，没有任何调用堆栈。这让我很困惑。

使用 Windbg 进一步分析：

1. 在 Windbg 中，键入以下命令：（!heap -stat -h 02150000其中 2150000 是发生泄漏的堆的地址） 在比较多个转储后，我看到大小为 1 的内存块随着时间的推移而增加，并且可能是泄漏的内存。

2. 输入以下命令：!heap -flt s 1给出这些分配的 UserPtr，最后：

3. !heap -p -a address在其中一些地址上键入总是显示以下分配调用堆栈：

   这与 UMDH 分析相匹配。在这里，我也看不到调用堆栈。

谁能帮我在这里指个方向？

我正在使用最新的 Windows 调试工具包中的 UMDH 6.1.7659。我想尝试生成一个可以在 WINDBG 中查看的 dmp 文件，以调查非托管 64 位 C++ EXE 中的内存泄漏：

当我尝试在 WinDbg（版本 1607）中打开 DMP 文件时，我看到：

同一个 DMP 文件上的 DUMPCHK 给了我相同的结果。

UMDH 不再与 WINDBG 兼容了吗？

我在通过 GFLAGS 和 UMDH 发现内存泄漏方面取得了巨大成功。但是，我刚刚发现 UMDH 不知何故在 64 位应用程序中看不到 BSTR-Leaks。有谁知道这是为什么？这是 UMDH 中的错误吗？堆管理器如何为 x64 应用程序工作的变化？我什至可以在哪里向 Microsoft 报告此类问题？

我用一个像这样的小型测试可执行文件调查了这个问题：

这是 x86 测试可执行文件的 UMDH 输出。泄漏是可见的！

这是 x64 测试可执行文件的 UMDH 输出。如您所见，BSTR 分配不可见。