我试图编写一个小的应用程序，通过它的IDdebugging另一个进程，并监视应用程序，直到它崩溃。 现在我已经写了一个小代码，大部分来自MS编写debugging器的例子。
即使在目标崩溃后，我的目标应用程序也不会通过if（！de.u.Exception.dwFirstChance）。
如果我在if（！de.u.Exception.dwFirstChance）上放置一个bp，我能够看到exception，但是没有exception符合条件。
PS：太多的编辑：/
#include "stdafx.h" #include <windows.foundation.diagnostics.h> #include <debugapi.h> #include <ntstatus.h> DEBUG_EVENT de; int _tmain(int pid) { DebugActiveProcess( pid); while (true) { int a; if (WaitForDebugEvent (&de, (DWORD)1000)) { if (de.dwDebugEventCode == EXCEPTION_DEBUG_EVENT) { if(!de.u.Exception.dwFirstChance) int excep = de.u.Exception.ExceptionRecord.ExceptionCode; } } ContinueDebugEvent ( de.dwProcessId, de.dwThreadId, DBG_CONTINUE); } } 文章“为Sysinternals ProcDump v4.0编写一个插件”在伪代码中指示， 当 （并且仅当）出现“第二次机会异常”时，被监视进程的转储产生。
// (extract altered for brevity) Else "Second Chance Exception" WriteDump(..) Done = True
和“编写一个基本的Windows调试器”表示EXCEPTION_DEBUGINFO.dwFirstChance ，与警卫STATUS_BREAKPOINT / EXCEPTION_BREAKPOINT可用于检测这种情况。
“第一次和第二次机会异常处理”（KB105676）解释了异常机会类型之间的区别：
但是，如果正在调试应用程序， 则调试程序会在程序执行之前看到所有[第一次机会]异常 。 这是第一次和第二次机会异常之间的区别：调试器获得第一次看到异常（因此名称）的机会。
正在被检测到的是这些第一次机会异常（“被管理”或不是），但是它们几乎都是可恢复的 – 即它们被应用程序/运行时代码捕获，并得到适当处理。
如果调试器允许程序继续执行并且不处理异常，那么程序将像往常一样看到异常。 如果程序没有处理异常，调试器有第二次机会看到异常。 在后一种情况下， 如果调试器不存在 ， 程序通常会崩溃。
因此，procdump可能会产生第二次机会异常的转储，假定任何进程致命的异常不会被压制（另一个调试器，因为程序放弃了它的机会）。
（EXIT_PROCESS_DEBUG_EVENT 在进程终止之后发生，因此不能生成适当的转储，尽管它发出信号以结束监视。）
YMMV：所有的信息/观察都来自所列的文章和资源，没有实际使用这些技术的经验。
以前有关于单步异常的问题/回答： 什么是单步异常？
您列举的每个异常都会在您的应用程序未处理时崩溃。 网上有很多关于每个的信息。
简单的新手建议：你是第一个遇到问题或想知道什么是什么意思的人是不太可能的。 谷歌是这样的事情更合适的工具。 谷歌第一，StackExchange如果你找不到答案。