来自ADPlus / CDB的不一致行为——在g中没有可运行的Debuggees错误

时间:2021-10-18 17:32:34

I've set up ADPlus / cdb as the default Just-In-Time debugger on my machine. When any process has an unhandled exception or crashes for any other reason, I want ADPlus to generate a crash dump for me. I'm using an ADPlus config file to set the output directory and run a precommand that is used to push the dmp file to the cloud.

我在我的机器上设置了ADPlus / cdb作为默认的即时调试器。当任何进程有未处理的异常或因其他原因而崩溃时,我希望ADPlus为我生成一个崩溃转储。我使用ADPlus配置文件来设置输出目录并运行一个precommand,用于将dmp文件推送到云。

To test to make sure that this works, I wrote a really simple program that throws an unhandled exception and crashes. ADPlus always attaches itself like it is supposed to, but it only successfully generates the dump that I want about 1 in 15 times. Without changing anything on my system, I run my crashing program back to back and get different results.

为了确保这个工作正常,我编写了一个非常简单的程序,它抛出一个未处理的异常和崩溃。ADPlus总是像它应该的那样附加在自己的位置上,但是它只成功地生成了我想要的转储文件,在15次中我想要的是1。如果不改变系统上的任何东西,我就会把崩溃的程序往回运行,得到不同的结果。

Most of the time, I get the following error from cdb:

大多数情况下,我从cdb得到以下错误:

0:000> g

       ^ No runnable debuggees error in 'g'

0:000>

*[EOF]*

When it works properly, the same place in the log looks like this:

当它正常工作时,日志中的相同位置是这样的:

0:004> g

FirstChance_epr_Process_Shut_Down

*[More stuff after here]*

Any idea why I would be getting this behavior? I can post my config file and full logs if that would be helpful. The only difference between the when-it-works logs and the when-it-doesn't-work logs is the lines all start with 0:004> when it works and with 0:000> when it doesn't.

知道我为什么会有这种行为吗?我可以发布我的配置文件和完整的日志,如果那会有用。when-it-works日志和when-it- t-work日志之间的唯一区别是,当它工作时,所有的行都以0:004>开始,而当它不工作时,则以0:00 >开始。

2 个解决方案

#1


1  

Comment couldn't hold all this...so putting here...

评论不能包含所有这些…这里把…

Yes with DebugDiag you can have a pre-attach VBS script, and you can define a Custom Action (i.e. run a VBS script) when an event occurs.

对于DebugDiag,您可以有一个预附加的VBS脚本,当事件发生时,您可以定义一个自定义动作(即运行VBS脚本)。

I think you need to wait till CDB has completed the dump and CDB/your process has exited before you attempt to launch your application again. (you can use tlist in your script to monitor processes...to wait till it disappears). ...otherwise ADPlus with the -PN option might be making CDB attempt to reattach to the already crashed process...which it can't because a debugger is already attached.

我认为您需要等到CDB完成转储,而CDB/您的流程在尝试再次启动应用程序之前已经退出。(您可以在脚本中使用tlist来监视进程…等待直到它消失)。否则,使用-PN选项的ADPlus可能会使CDB尝试重新连接已经崩溃的进程…它不能因为调试器已经附加了。

Put up TaskManager and see if you ever get multiple instances of your application showing up (if you do, then you might have to use the -p PID option instead to get adplus to monitor the right process...not ideal as you have to have started the process first in order to get its PID).

设置TaskManager,看看是否有多个应用程序实例出现(如果有的话,那么您可能需要使用-p PID选项,而不是让adplus监视正确的进程……)并不理想,因为你必须先开始这个过程才能得到它的PID。

Also look into ProcDump which uses a technique called Reflected Processes...which allows a very quick way to copy the process space and let the dump be completed without holding up things...that might help if DebugDiag doesn't.

还可以查看ProcDump,它使用了一种名为反射过程的技术。这样可以非常快速地复制进程空间,并让转储完成,而不需要占用任何东西……如果DebugDiag不这样做可能会有帮助。

Look at this link...right at the bottom...it shows how to wait for CDB to finish doing the dump (however it's a Powershell script).

看看这个链接……正确的底部…它显示了如何等待CDB完成转储(不过这是一个Powershell脚本)。

#2


0  

The WinDbg command 'g' means [Continue]

WinDbg命令'g'表示[继续]

Since you're opening a dump-file there is no way to 'continue', it only contains the process memory.

由于您正在打开一个转储文件,所以无法“继续”,它只包含进程内存。

So the message " No runnable debuggees error in 'g' " is logical in your case since the process is not running.

因此,“在‘g’中没有可运行的debuggees错误”在您的情况下是符合逻辑的,因为进程没有运行。

Concerning loading the correct version of SOS use the following command depending on the .NET version.

关于载入正确版本的SOS,使用以下命令取决于。net版本。

.NET 4 and higher .loadby sos

。net 4和更高的。loadby sos。

.NET 3.5 and 2 .loadby sos mscorwks

.NET 3.5和2 .loadby sos mscorwks。

.NET 1.0 and 1.1 .load clr10\sos

.NET 1.0和1.1 .load clr10\sos。

#1


1  

Comment couldn't hold all this...so putting here...

评论不能包含所有这些…这里把…

Yes with DebugDiag you can have a pre-attach VBS script, and you can define a Custom Action (i.e. run a VBS script) when an event occurs.

对于DebugDiag,您可以有一个预附加的VBS脚本,当事件发生时,您可以定义一个自定义动作(即运行VBS脚本)。

I think you need to wait till CDB has completed the dump and CDB/your process has exited before you attempt to launch your application again. (you can use tlist in your script to monitor processes...to wait till it disappears). ...otherwise ADPlus with the -PN option might be making CDB attempt to reattach to the already crashed process...which it can't because a debugger is already attached.

我认为您需要等到CDB完成转储,而CDB/您的流程在尝试再次启动应用程序之前已经退出。(您可以在脚本中使用tlist来监视进程…等待直到它消失)。否则,使用-PN选项的ADPlus可能会使CDB尝试重新连接已经崩溃的进程…它不能因为调试器已经附加了。

Put up TaskManager and see if you ever get multiple instances of your application showing up (if you do, then you might have to use the -p PID option instead to get adplus to monitor the right process...not ideal as you have to have started the process first in order to get its PID).

设置TaskManager,看看是否有多个应用程序实例出现(如果有的话,那么您可能需要使用-p PID选项,而不是让adplus监视正确的进程……)并不理想,因为你必须先开始这个过程才能得到它的PID。

Also look into ProcDump which uses a technique called Reflected Processes...which allows a very quick way to copy the process space and let the dump be completed without holding up things...that might help if DebugDiag doesn't.

还可以查看ProcDump,它使用了一种名为反射过程的技术。这样可以非常快速地复制进程空间,并让转储完成,而不需要占用任何东西……如果DebugDiag不这样做可能会有帮助。

Look at this link...right at the bottom...it shows how to wait for CDB to finish doing the dump (however it's a Powershell script).

看看这个链接……正确的底部…它显示了如何等待CDB完成转储(不过这是一个Powershell脚本)。

#2


0  

The WinDbg command 'g' means [Continue]

WinDbg命令'g'表示[继续]

Since you're opening a dump-file there is no way to 'continue', it only contains the process memory.

由于您正在打开一个转储文件,所以无法“继续”,它只包含进程内存。

So the message " No runnable debuggees error in 'g' " is logical in your case since the process is not running.

因此,“在‘g’中没有可运行的debuggees错误”在您的情况下是符合逻辑的,因为进程没有运行。

Concerning loading the correct version of SOS use the following command depending on the .NET version.

关于载入正确版本的SOS,使用以下命令取决于。net版本。

.NET 4 and higher .loadby sos

。net 4和更高的。loadby sos。

.NET 3.5 and 2 .loadby sos mscorwks

.NET 3.5和2 .loadby sos mscorwks。

.NET 1.0 and 1.1 .load clr10\sos

.NET 1.0和1.1 .load clr10\sos。