去年底，公司一个上线了近一年的系统逐渐出现访问缓慢，操作超时的问题。本人使用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版本不匹配问题解决

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

    公司使用的技术框架比较老，大部份仍停留在原生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 扩展命令手册》

winDBG排错小记