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 扩展命令手册》

原文地址:https://www.cnblogs.com/ljzforever/p/6414610.html