Browse by Tags
All Tags »
WinDbg (RSS)
Sorry, but there are no more tags available to filter with.
CLR小组中存在着大量的回归测试，这些回归测试会定期执行来发现CLR中的Bug，Developer在Checkin之前，也需要执行这些测试的一部分（大概是10小时左右，如果全部跑的话估计要好几天）。这些测试对于保证CLR的质量是至关重要的。有时候，这些测试会偶尔失败，比如跑100次失败大概一到两次，有些极端的例子甚至是10000次才失败一次。像这种问题通常是很难调试的。在前面 调试Bug的神兵利器：通过WinDbg条件断点收集Log 这篇文章中，我讲到了如何通过条件断点收集各种信息来判断Bug究竟出在哪里。但是，这个方法还是不太管用，因为它不能够反复执行某个程序。下面我要讲一种技巧可以用来调试类似这样的问题，这种技巧主要适用于下面几种情况：
Read More...
前段时间花了几天一直在用WinDbg调试一个比较棘手的Bug。这个Bug是C# Team那边发现的，他们的Testcase跑大概10分钟左右会出一个在CLR内部的ASSERT。比较难调试的主要原因在于ASSERT表明一个全局的数据结构出现了问题，本来不应该用完的数组却已经用完了（因为按照设计，这个数组是边使用边清理的，是不会用完的）。初步想到的有下面几种方案来调试： 1. 设置数据断点 2. 一步一步调试 3. 添加Log代码 设置数据断点的主要问题是不太好确定到底是因为什么原因导致的数据结构问题，而且因为是数组被用完，很难将是到底是哪一个数组元素的加入导致了数组被全部占用，因此无法通过设置数据断点的方法来调试。一步一步的调试显然也没法解决问题，因为这个Testcase本身要跑十分钟，可以想象单步调试运行十分钟的程序会花费多长时间。因此两个方案都被我否决。添加Log代码其实是可以的，只是需要修改代码，每次修改之后需要重新编译代码，然后需要在目标机器上安装，而且C#使用的CLR的Branch并非我们正在开发的Branch，需要重新下载源代码，相对比较麻烦。最后为了解决这个问题，我采取的方法是使用WinDbg的条件断点＋Log的方式。大致的方法如下：
Read More...
Sometimes you might find that the workspaces in your WinDbg cannot be deleted. It doesn't show up in the workspace list, but it is still in effect if you start to debug that particular program. I did a little bit research and found that WinDbg stored
Read More...
Symbol servers are very convenient but from time to time it hurts performance by trying to access symbol server for a DLL/EXE it doesn’t have again & again. This is one of the reasons WinDbg keep being “BUSY”. To speed up the performance, you can
Read More...
