winDBG排错小记

去年底，公司一个上线了近一年的系统逐渐出现访问缓慢，操作超时的问题。本人使用winDBG工具对抓下来的内存映象进行了诊断，虽最后没有查出什么原因，但在过程中也学到了不少东西，现记录如下

一. “Failed to load data access DLL, 0x80004005”错误

这个错误还有另外一种提示：“The version of SOS does not match the version of CLR you are debugging”。

从原理上讲，象winDBG等非托管调试工具，是使用sos.dll模块，通过mscordacwks.dll接口，调用clr.dll实现，最终实现对.Net运行时托管代码的访问。这里有两点需要注意

1. sos.dll，mscordacwks.dll这两个之间的版本必须一致

2. sos.dll与被调用的映象运行时版本必须一致

上面两个有任意一处不一致，都会导致上述的错误信息。对于我，则是服务器是.net 4.0版本，我本机是4.6版本，即报此错误。解决的方案有两个

1. 使用正确版本的各个dll。一般来讲，从服务器除了复制内存映象文件外，还需复制以上两个dll，确保调试成功。至少需要复制sos.dll，winDBG在执行过程中会自动从符号文件服务器下载与当前sos.dll匹配版本的mscordacwks.dll。

2. 使用Psscor4工具。它是sos.dll的进阶版，添加了若干增强工具，会自动判断当前被调试的内存映象，下载正确匹配版本的mscordacwks.dll。推荐使用此方案。

What to do with “The version of SOS does not match the version of CLR you are debugging” in WinDbg?

“Failed to load data access DLL, 0x80004005” – OR – What is mscordacwks.dll?

The version of SOS does not match the version of CLR you are debugging; SOS.dll版本不匹配; Dump文件不同环境mscordacwks.dll版本问题

windbg配置问题汇总

windbg sos版本不匹配问题解决

.NET应用程序调试—原理、工具、方法

二. 内存泄露是最常见的问题

公司使用的技术框架比较老，大部份仍停留在原生Sql + DataTable的方式上。我的第一反应是查询返回的数据太多，DataTable对象可能占用了过多的内存。下面的文章具体介绍了定位方法。

使用WinDbg+SOS及WinDbg Script寻找内存中DataTable第M行N列的值

使用windbg排查一个内存溢出的问题

抛出的异常过多，不正确的缓存使用也会造成内存的大量浪费

调试.NET Web应用程序High Memory - Part 1

调试.NET Web应用程序High Memory - Part 2

三. 线程死锁也是一个常见问题

使用Windbg找出死锁，解决生产环境中运行的软件不响应请求的问题

Debugging a Deadlock

四. 最后，熟练掌握各条命令是活用winDBG的基础

《WinDbg 命令三部曲：（一）WinDbg 命令手册》

《WinDbg 命令三部曲：（二）WinDbg SOS 扩展命令手册》

《WinDbg 命令三部曲：（三）WinDbg SOSEX 扩展命令手册》