［翻译］时钟Gadget不转的实例分析
除了Aero毛玻璃效果之外，Windows边栏（Sidebar）也算是Windows Vista中最酷炫的特性之一，它自带一组小工具（Gadget），例如时钟、源标题（RSS Feed）和幻灯片放映等。有了Windows边栏，我们就可以把经常访问的程序放在桌面上，同时开发也很方便，所以现在已经出现成千上万的小工具，可以通过Windows Vista Gadget Gallery这样的站点去访问。出于好奇，笔者自己也下载安装了一些，并把它们放在Windows边栏的标准配置中，也从没出什么问题。但是有次安装了一组新的小工具以后没多少天，就发现一个第三方的时钟小工具不转了，于是开始进行展开调查排错。
由于系统其它功能一切正常，所以第一步首先确认Windows边栏的配置是否出了差错。右键单击Windows边栏的屏幕区域，并选择“属性”菜单项，但是却并未弹出“Windows边栏属性”对话框，Windows边栏崩溃了：
小工具运行在共享的Sidebar进程（Windows边栏）中，所以笔者首先猜测是由于Sidebar进程中的内存冲突导致时钟停转而后出现崩溃，接下来对故障现象进行分析，以便确认是否由此而导致。Windows Error Reporting（WER）服务会创建故障转储文件，这是出错进程的状态保存，我们可以选择是否把故障信息发送给微软。单击对话框上的“View Details”区域，以便查看Windows把故障转储文件保存在哪里：
对话框所显示的最后一行，WERD8EE.tmp.mdmp，就是故障转储文件，然后可以用Microsoft Debugging Tools for Windows Windbg工具打开该文件。打开转储文件时，Windbg会自动显示最终可能导致故障的指令。在本例中，就是Msvcrt中的内存复制操作所导致的问题，Msvcrt就是Microsoft C运行时库。
显示指令这一行的右边部分，表明内存复制的目标地址是0。如果内存资源耗尽，内存分配函数通常就会返回地址0，也叫做空指针（Null Pointer），因为对于Windows进程来说，这默认是一个非法地址（虽然应用程序可以在地址0手动创建可读写的内存，但是通常是无法完成的）。Sidebar进程引用地址0，并不能最终证明故障原因就是因为内存过低（而非冲突），但是看起来很像。
接下来查看导致故障的代码，这可以告诉我们是否Sidebar进程或者小工具本身给C运行时库传递了空指针。要达到这个目的，可以打开Windbg的堆栈对话框：
先前已经对Windbg的符号路径进行配置，以指向Microsoft symbol server，这样Windbg就可以报告Windows映像中的内部函数名称，因为已知的函数名称更加有助我们分析故障转储文件。堆栈追踪中列出的函数显示在Sidebar进程崩溃时，它正在查询某个“Package”的版本号。笔者不能确定Sidebar进程调用这个“Package”的什么，但是堆栈追踪确实显示Sidebar进程才是罪魁，而非小工具。
难道是Sidebar进程耗尽了内存？有几种类型的资源耗尽，可能导致内存分配失败。例如系统用完可提交内存（committable memory），进程可能会消耗自身地址空间里的所有内存，或者内部的堆到达其最大容量限制。
于是开始检查已提交内存（committed memory），因为这种方法最便捷。全部可提交内存（Total commitable memory），也叫做提交限制（commit limit），就是物理内存的绝大部分，再加上页面文件的大小。如果可提交内存变小，Windows Vista的资源耗尽检测机制会对我们发出警告，并且会列出内存消耗最多的一组进程，我们可以选择关闭这些进程，以便缓解内存压力。但是笔者并没有看到这种警告，所以怀疑这是不是问题的根源，但是还是打开Process Explorer的系统信息框，以进行检测：
让人惊讶的是，系统有充足的可提交内存。于是接下来检查Sidebar进程的虚拟内存使用。内存泄漏（Memory Leak）经常是由于进程分配了虚拟内存，在里面存储数据、使用数据，而当数据处理完成后却没有释放内存所导致的。进程用来存储自己的数据而分配的虚拟内存叫做Private Bytes（私有内存容量值），所以打开Process Explorer，并且添加显示“Private Bytes”列：
在32位Windows系统中，进程默认拥有2GB的可用地址空间，所以Private Bytes的最高可能值应该接近2GB，这实际上就是Sidebar进程（进程ID为4680）所消耗的数量。这就可以确认：Sidebar中的内存泄漏导致其耗尽地址空间，从而导致内存分配失败，最终导致空指针的引用和进程崩溃。笔者猜测Sidebar进程耗尽地址空间时，时钟小工具无法分配资源系统资源来刷新其图形界面，所以这时候时钟小工具就停转了。
接下来需要确认哪个小工具导致内存泄漏，可能就是停转的时钟小工具本身。Windows边栏包含两个进程，其中一个Sidebar.exe进程包含Windows自带的小工具，另一个Sidebar.exe子进程包含第三方的小工具。这时候我们已经了解是第三方小工具发生内存泄漏，或者导致Sidebar进程发生内存泄漏，但是笔者有多个多个第三方小工具在运行，不能确认哪个才是罪魁祸首。不幸的是，Windows边栏本身没有提供方法，来帮助我们追踪小工具的内存使用（或者其他的资源使用），所以笔者只能采用手工方法，逐步隔离内存泄漏的原因。
重启Windows边栏以后，移除所有的第三方小工具，然后每次再将它们逐个添加回来，每个小工具运行一到两分钟，以便对Sidebar进程的Private Bytes使用情况进行监控。在Process Explorer视图中添加“Private Bytes Delta”列，以便更容易发现Private Bytes的增量，当添加某个小工具以后，可以看到“Private Bytes Delta”值在周期性的不断增长，说明这个小工具就是内存泄漏的罪魁：
现在已经知道惹祸的小工具，本可以直接卸载这个小工具，这样这个问题就可以解决了。但是笔者很好奇，想知道这个小工具是怎么导致Sidebar进程崩溃的–甚至卸载了该小工具，内存泄漏还在继续。
于是定位到小工具的安装目录，打开其HTML文件，查看它所做的事情。这个小工具包含约三、四十行非常简单的Javascript代码，并未发现什么问题。为了缩小问题代码的范围，笔者逐段注释代码，然后把该小工具重新添加到Windows边栏，直到发现内存泄漏消失为止。最后所剩的代码是一个函数，配置用来每十秒刷新其背景图案。它调用Windows边栏background对象的RemoveObjects方法，然后调用background对象的AddImageObject方法，以添加背景图片和文本。这里是相关代码的一个简化版本：
事实上，该小工具正确地调用了这些API，这好像是Windows边栏的源代码导致了内存泄漏，但是快速搜索了一下Internet，却并未看到有谁提及background对象的内存泄漏问题。如果Windows边栏的API有内存泄漏的问题，那么为什么发现的人那么少？仔细检查其他小工具的源代码，发现都没有使用这些API，这解释了为什么这种内存泄漏不大发生的原因。但是，Windows Vista Gadget Gallery网站上该小工具边上的帖子说有时候会导致内存泄漏，这表明已经有用户发现了这个现象。
现在已经知道小工具无法响应的问题，是由于Windows边栏的API所导致的内存泄漏。笔者在Windows Bug数据库里递交了一个Bug，然后关闭了这个问题。
原文作者：Mark Russinovich
译文作者：盆盆
http://blogs.technet.com/markrussinovich/archive/2007/10/15/2178879.aspx