去年底，公司一个上线了近一年的系统逐渐出现访问缓慢，操作超时的问题。本人使用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?
二. 内存泄露是最常见的问题
公司使用的技术框架比较老，大部份仍停留在原生Sql + DataTable的方式上。我的第一反应是查询返回的数据太多，DataTable对象可能占用了过多的内存。下面的文章具体介绍了定位方法。
使用WinDbg+SOS及WinDbg Script寻找内存中DataTable第M行N列的值
抛出的异常过多，不正确的缓存使用也会造成内存的大量浪费
调试.NET Web应用程序High Memory - Part 1
调试.NET Web应用程序High Memory - Part 2
三. 线程死锁也是一个常见问题
使用Windbg找出死锁，解决生产环境中运行的软件不响应请求的问题
四. 最后，熟练掌握各条命令是活用winDBG的基础
《WinDbg 命令三部曲：（二）WinDbg SOS 扩展命令手册》
《WinDbg 命令三部曲：（三）WinDbg SOSEX 扩展命令手册》