利用Windbg分析Magicodes.IE一次错误编写导致内存剧增

由于这近一年时间一直忙于写书和工作，一直没有水文，但是近期有几位朋友使用我们的Magicodes.IE反馈在导出过程中内存暴涨...好吧，不管怎样，不能苦了我们朋友，接下来我们通过windbg来看一下什么原因导致的。

接下来我们先通过address -summary来看一下当前应用内存占用量。

MEM_COMMIT占用了4.384G，接下来我们利用eeheap -gc来检查托管堆。

根据这些内存来看，似乎问题不是这里，大量的内存还是出现在非托管。我们利用Windows NT堆来看一下，其实在Windows中大多数的用户堆分配器都在ntdll.dll中的NT堆管理器API（RtlAllocateHeap/RtlFreeHeap）上建立，比如说C中的malloc/free和new/delete，另外还有COM框架中的SysAllocString以及在Win32中的LocalAlloc、GlobalAlloc和HeapAlloc，虽然说这些分配器都会创建不同的堆来存储它们的内存，但是他们最终都要调用ntdll.dll中的NT堆来实现。

输出结果如上所示，NT堆内容好少....什么原因....好吧根据 maoni所说，似乎是验证出了问题。

GC没有管辖这些内存，所以说还是我们编写的代码有问题，我们返过来再考虑一个事情，“导出进行时，内存会大量增加，导出完成后内存会降低下去”。我们来看一下代码，如下所示，其实我们现在明白的是，在我们执行期间肯定是这些内存一直“持有”，并没有被释放掉。

根据内存的表现和我们的理论，我们继续利用windbg来排查一下，现在其实我们可以发现，这些对象最终还是被GC收回了，带着理论我们继续构思，GC是知道哪些对象可以终结的对吧？并且它们在变成不可到达时调用它们的终结器，在GC中会利用finalization queue来记录这些终结对象。所以说我们是不是可以查一下？如下所示，我们来看一下。

WOW！！！，看上面356个System.Drawing.Bitmap在等待回收，看起来这是我们的影响因素，我们来查一下代码。

下载地址：http://www.stevestechspot.com/default.aspx

可能大家都会像我一开始有个疑问，你这个图片我看了...没有那么大，并且在windbg中也没有表现大小呀。首先我们先来看一下这个图片的质量。 图片的像素为2560x1440，位深为24目前已知这些信息，我们计算一下未压缩的图片大小。

2560x1440x24/8

10M左右一张图，已知图片数x10M=3G，其实对于这个问题来说，这并不属于内存泄漏。