通过简单Dump能获得的基本信息
如果有出错程序的dump, 哪怕dump不是在合适的时机获取的, 也可以分析出有用的信息.
- 通过vertarget查看系统版本和系统运行了多长时间.
- 通过!peb查看环境变量的情况. 由于很多第三方软件都习惯把自身路径添加到环境变量中, 所以这里很多时候可以看出一些已经安装的软件.
- 同时还能看到当前进程所加载的DLL和对应路径.
检查DLL和对应路径时, 可以重点检查如下的一些项目:
- 有没有防毒程序的DLL加载.
- 有没有类似MSVCRTD或MFC42D的debug版本DLL加载. 如果有, 请说明程序使用的某些组件是否是在Debug模式下编译的.
- 通过MFC42这样的DLL大致判断程序时如何开发的. 比如是否使用MFC或ATL. 如果加载了mscoree, 询问一下程序是否使用了托管代码.
- 通过lmvm命令检查值得怀疑的DLL的详细版本和公司名称. 必要情况下还可以使用sos!savemodule命令把DLL保存到本地以检查链接情况, 等等.
- 通过lmf命令还可以检查是否有unload的module. 很多问题是由正在使用的module被unload导致的, 也有很多问题最后导致某些module被unload. 看看这里的unload module是不是正常情况.
- 检查module的数量, 是否有动态生成的module加载. 如果进程中加载的module过多, 则容易导致内存地址碎片. 比如对于asp.net程序, 很多module是对应于aspx页面动态编译生成的, 需要通过设置debug=false来激活batch compilation, 以减少动态module的产生.
- 通过dump文件的尺寸来判断内存使用情况. 一般dump的大小与实际内存使用的大小一致.
- 检查某些系统dll来判断某些系统组件是否已经升级到最新. 比如检查mscorwks的版本就可以判断.NET Framework的版本以及是否打过SP1, 检查msado15就可以判断MDAC的版本.
摘自<Windows用户态程序高效排错>
