无论如何,我正在尝试使用WinDbg并在附加到我的进程后,调试器说：
(1e9c.1128): Break instruction exception - code 80000003 (first chance) eax=7ffda000 ebx=00000000 ecx=00000000 edx=77c5c964 esi=00000000 edi=00000000 eip=77c18b2e esp=0543ff5c ebp=0543ff88 iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246 ntdll!DbgBreakPoint: 77c18b2e cc int 3
如果我运行！analyze -v,它会显示：
FAULTING_IP: ntdll!DbgBreakPoint+0 77c18b2e cc int 3
我是一名软件开发人员(VB.NET / C#),没有这种级别的调试经验,所以我不确定我在做什么,但好像WinDbg附加到我的进程然后立即破解.然后,当我进行分析时,它认为断点(它刚刚设置)是应用程序的问题？
我应该如何使用WinDbg简单地附加到流程并进行分析？
(另外,有没有关于开始使用此级别的调试和WinDbg的好书/教程？)
SOS和PSSCOR2提供或多或少相同的功能,而SOSEX为管理调试添加了新功能.可以使用WinDbg获得每个文件的帮助文件.例如.要获得SOS的帮助,您可以使用！sos.help命令.
您必须加载SOS或PSSCOR2以及可能的SOSEX来使用WinDbg调试托管应用程序.例如.如果你想加载SOS,你可以像这样使用load命令
.loadby sos clr
这将从.NET运行时的位置加载SOS.请注意,运行时在.NET 2中称为mscorwks,在Silverlight中称为coreclr,因此如果您使用其中任何一个,则需要相应地更改.loadby命令.
WinDbg需要符号来显示其他信息.这对于非托管代码尤为重要.您可以使用.symfix命令让WinDbg根据需要从Microsoft的符号服务器中检索符号.
当您的应用程序挂起时,您很可能会有一个或多个被阻止的线程.您可以使用！threads(或只是！t)命令查看托管线程.在.NET中,使用名为SyncBlocks的结构在内部实现简单锁.您可以使用！syncblk命令查看这些内容.如果已加载SOSEX,则！dlk命令可以自动检测死锁.
如果您想了解更多信息,可以阅读几本书和一些博客.
图书：
> Advanced .NET Debugging by Mario Hewardt.同一作者还有一本关于native debugging的书.
> Debugging Microsoft .NET 2.0 Applications,John Robbins
杰弗里里希特> CLR via C#是对CLR内部的精彩介绍.
博客：
> Tess’ blog很棒.它有许多可以用来练习的教程和实验.
> Tom’s blog也很有用.
视频：
>我在丹麦的Microsoft开发中心做了有关管理调试的演讲.频道可在频道p上找到. Part 1和part 2.