Microsoft (R) Windows Debugger Version 6.5.0003.7 Copyright (c) Microsoft Corporation. All rights reserved.
CommandLine: myapp.exe Symbol search path is: *** Invalid *** **************************************************************************** * Symbol loading may be unreliable without a symbol search path. * * Use .symfix to have the debugger choose a symbol path. * * After setting your symbol path, use .reload to refresh symbol locations. * ****************************************************************************
调试CPU高消耗的问题 对大多数软件来说,太高的CPU消耗率(根据任务管理器的显示,在单CPU上接近100%)明显指出软件中有bug。通常意味着应用程序的某个线程陷入了死循环。当然,调试这个问题的、最普通的方法是用Visual Studio调试器附上这个进程,查找哪个线程在捣乱。但是我们应该检查哪个线程呢?CDB为我们提供了简便的方法??!runaway命令。当不带参数使用时,这条命令显示应用程序每个线程执行用户模式代码时所花的时间(使用另外的参数,可以显示在内核模式下所花的时间,自线程启动后占用的时间等)。 如下是在CDB下使用这条命令的示例: cdb -pv -pn myapp.exe -logo out.txt -c "!runaway;q" 下面是!runaway命令的输出示例: 0:000> !runaway User Mode Time Thread Time 1:358 0 days 0:00:47.408 2:150 0 days 0:00:03.495 0:d8 0 days 0:00:00.000 看起来好像是ID为0x358的线程占用了大部分的CPU时间。但这个消息还不足以证明线程0x358就是罪魁祸首,因为这条命令显示的CPU时间是线程在它整个生命期中所花的。我们还需要进一步查看线程所用CPU时间的变化情况。让我们再次运行这条命令。这次,我们可以看到类似于下列的内容: 0:000> !runaway User Mode Time Thread Time 1:358 0 days 0:00:47.408 2:150 0 days 0:00:06.859 0:d8 0 days 0:00:00.000 现在,我们可以把这个输出内容与上次的输出内容做个比较,找出CPU时间增长最快的线程。在这个例子里,很明显就是线程0x150。现在,我们可以用Visual Studio调试器附上这个应用程序,切换到这个线程下,检查它为什么转个不停。