有时我们会遇到这样一个场景：一个进程正在使用大量内存，而此时我们能够获得的唯一数据就是用户转储。通常，来自umdh或xperf等工具的数据会更好，因为它们提供一段时间内的内存使用数据，并且可以包括调用堆栈信息。但是，umdh需要重新启动进程（这会丢失高内存使用率的状态），xperf需要安装Windows Performance Toolkit，这可能并不总是一个立即的选项。
当我们有这样一个转储时，我们可能无法明确指出是哪段代码产生了高内存使用率，但我们可以将故障排除的范围缩小到特定的dll。我们需要做的第一件事是确定什么类型的内存使用了大部分地址空间。调试器命令!address -summary允许我们执行以下操作：

0:000> !address -summary

--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal

Free                                    489      7fe`6ff5a000 (   7.994 Tb)           99.92%

Heap                                   9094        1`75ed1000 (   5.843 Gb)  93.47%    0.07%

<unknown>                               275        0`12e41000 ( 302.254 Mb)  4.72%    0.00%

Image                                   937        0`05a6a000 (  90.414 Mb)  1.41%    0.00%

Stack                                   138        0`01700000 (  23.000 Mb)  0.36%    0.00%

Other                                    14        0`001bd000 (   1.738 Mb)  0.03%    0.00%

TEB                                      46        0`0005c000 ( 368.000 kb)   0.01%   0.00%

PEB                                       1        0`00001000 (   4.000 kb)  0.00%    0.00%

从这个例子中我们可以看到大部分内存被堆使用。一个进程通常有多个堆，每个堆都是通过调用HeapCreate创建的。我们可以检查这些堆的大小!heap -s：

0:000> !heap -s

LFH Key                   : 0x0000006c1104d280

Termination on corruption : ENABLED

          Heap     Flags  Reserv  Commit  Virt  Free  List   UCR Virt  Lock  Fast

                            (k)     (k)   (k)     (k) length      blocks cont. heap

-------------------------------------------------------------------------------------

0000000000100000 00000002  16384  12824  16384  1180   254     5   0      3   LFH

0000000000010000 00008000     64      4     64     1     1     1   0      0     

00000000003d0000 00001002   1088    708   1088   121    20     2   0      0   LFH

0000000003080000 00001002   1536    700   1536     4     4     2   0      0   LFH

00000000033a0000 00001002 5229696 1377584 5229696 414244  4039  3059   0     2c   LFH

    External fragmentation  30 % (4039 free blocks)

    Virtual address fragmentation  73 % (3059 uncommited ranges)

0000000003380000 00001002     64      8     64     3     1     1   0      0     

0000000003600000 00001002    512     56    512     3     1     1   0      0     

0000000003c20000 00001002    512      8    512     3     1     1   0      0     

0000000003220000 00001002    512      8    512     3     1     1   0      0     

0000000003e50000 00001002    512      8    512     3     1     1   0      0     

0000000003d00000 00001002    512    148    512     5     3     1   0      0   LFH

从上面的输出中我们可以看到大部分内存被堆00000000033a0000占用。在这一点上，我们需要尝试确定这个堆的用途。执行此操作的一种强力方法是使用“s”命令搜索内存。

0:000> s -q 0 l?7fffffffffffffff 00000000033a0000

....

000007fe`f21810a0  00000000`033a0000 00000000`00000001

什么是std::__non_rtti_object异常？

不是一个RTTI对象异常

继承关系：

__non_rtti_object : public bad_typeid

备注

当指针指向的是一个无效的对象，引发此异常。例如，它是一个错误的指针，或者代码不是用/GR编译的

您看到的是一个非托管异常，它在CLR中引发。它是非常通用的，用于在深入本机代码时发出错误条件的信号。名称的“消息”部分是为Microsoft测试人员设计的。只需等待这个异常变成一个托管异常。如果是良性的话就被吞下去。
或者取消选中Project+Properties，Debugging，Enable unmanaged code Debugging复选框，这样你就看不到它了。或者使用Debug+Exceptions并取消选中Win32异常的抛出复选框，这样调试器就不会在这类异常上停止。

我发现一个很棒的工具，可以很好地显示进程中的内存使用情况。

这个示例工具将为您提供虚拟内存空间的直观概述（从内存转储），显示您的分配存在于何处以及您拥有的分配类型。例如，在下面的屏幕截图中，您可以看到在内存空间的开始，我们有大量的虚拟分配（深绿色-已提交，浅绿色-保留），然后我们有大量的可用空间（白色），在内存空间的末尾，我们可以看到我们的DLL分散开来（深红色）。


在底部屏幕中，我们可以看到GC（.NET）堆。换句话说，我们在顶部屏幕上看到的大多数虚拟分配实际上是GC堆。有一点需要注意的是，对于GC堆，它不显示为GC堆保留的内容，只显示提交的内容，即我们实际使用的内容。


我把它们分开，这样你就可以在非.net应用程序中使用这个工具了。


研究这样的东西的目的是为了弄清楚我们有多少碎片，我们有多少保留内存和提交内存等等。如果我们确实有很多碎片，我们应该从哪里开始寻找以减少碎片。

原来的工具有点复杂，因为它可以读取内存转储等，并允许您放大不同的区域以获得更多的细节，但在大多数情况下，上面看到的已经足够了。

要使用示例工具，请执行以下步骤：

1、在windbg中打开内存转储并正确设置符号

2、运行!address ，然后拷贝输出到一个文本文件

3、Load sos

4、运行!eeheap –gc ，然后拷贝输出到另一个文本文件

5、打开工具，点击加载