|
Vista边栏时钟不转的实例分析(1) 除了Aero毛玻璃效果之外，Windows边栏（Sidebar）也算是Windows Vista中最酷炫的特性之一，它自带一组小工具（Gadget），例如时钟、源标题（RSS Feed）和幻灯片放映等。有了Windows边栏，我们就可以把经常访问的程序放在桌面上，同时开发也很方便，所以现在已经出现成千上万的小工具，可以通过Windows Vista Gadget Gallery这样的站点去访问。出于好奇，笔者自己也下载安装了一些，并把它们放在Windows边栏的标准配置中，也从没出什么问题。但是有次安装了一组新的小工具以后没多少天，就发现一个第三方的时钟小工具不转了，于是开始进行展开调查排错。
由于系统其它功能一切正常，所以第一步首先确认Windows边栏的配置是否出了差错。右键单击Windows边栏的屏幕区域，并选择“属性”菜单项，但是却并未弹出“Windows边栏属性”对话框，Windows边栏崩溃了：
 ASPx" width=484>
小工具运行在共享的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进程才是罪魁，而非小工具。
| 
