前几天发现一个奇怪的bug,分给这里的一个seniro dev他也没太多的办法。我在一个高手的指导下自己debug and figure out了root cause。在和这个高手的交流中,也基本明确了一下步的学习目标。以前的我主要是靠自己摸索,我想多跟高手接触,交流还是非常非常有帮助的,当然机会也不是很多。那么我的下一步的目标就是“code review, debugging, windows internal and WDM”。Debugging可以说贯穿了其他的三个,因此我今天先谈谈我对debugging tools的感受。
我们基本都是用微软提供的几个debuggers,ntsd, cdb, kd, windbg。ntsd和cbd是user mode debugger, kd是kernel mode debugger, 他们都是command line的,而windbg是UI的debugger, 可以调试both user and kernel mode。大多数情况,我都是用windbg,但是在一些特殊的情况下,我还是需要其他的tools。今天我主要是谈windbg,我想学习windbg大概分这么几个阶段:
- windbg的命令,共三种命令,普通命令,加'.'的命令和加'!'的命令。Debugging tools自带的那个教程学习一下就应该差不多了,以后就靠经验积累了。
- 如何开始debug, 这要根据你所debug的目标和要debug的问题来决定了。你应该决定是使用user debugger 还是 kernel debugger, 是 local debugging 还是 remote debugging, 是用windbg还是ntsd, 等等。通常都有几种方式去debug,你要能够准确选择一个最合适的。
- 怎样进行debug。对于一个需要debug的问题,你需要有你的策略。比如,在哪里设置断点,如何设置断点,等等技巧。
- 利用一些tools。有些情况下只有debugger还是很难debug,你需要使用其他的tools去辅助。比如,有的时候在问题显露的时候已经太晚了,你很难追踪问题发生时的情况。这里,你可以用一些tool使得在事情发生的时候跳到debugger上去。
- Code review非常重要。当你发现一个bug的时候,如果你代码熟悉,你可能直接就能想到问题出在哪里,或者你稍微读读代码就能发现问题所在,根本就不需要debugger。而在你debugging的时候,常常你也需要review相关的代码来理解这个问题。
- 汇编语言。当你在调试optimized code的时候,你常常不能通过dv, dt等命令正确地看参数,变量等等,或者变量根本就没得显示。这就需要你具备汇编语言的阅读能力,了解calling convention, 不同cpu的汇编,以及在disassembly模式去调试。
- Kernel debugging。如果你具备了以上的技能以后,user mode debugging应该不成什么问题了。但是对于调试kenrel mode还是需要一些附加的知识与技能。首先,kernel debugger的命令很多跟user mode的就不一样了,你需要学习。其次,你需要了解Windows internal的知识和数据结构,以及Windows driver model。这也是为什么我把Windows internal 和 WDM作为两个学习要点。
最后引用高手的两句话,“debug一两年,你就没什么问题debug不了了”,“只要能repro,你总能找到办法去debug”。
1 comment:
hi,你好。我下载了一个Debugging Tools for Windows,想用它调试一个别人编写的exe(之前我看见别人调试时“Attach to a Process”,然后执行exe中的事件,在调试器中就会出现exe崩溃的错误提示),但是我一Attach就报错“*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\ntdll.dll -
ntdll!DbgBreakPoint:”
Post a Comment