Crash Mode

In crash mode, ADPlus attaches the CDB debugger to all processes that are specified at the command prompt and automatically configures the debugger to monitor for the following kinds of exceptions:

• Invalid handle
• Illegal instruction
• Integer divide-by-zero
• Floating-point divide-by-zero
• Integer overflow
• Invalid lock sequence
• Access violation
• Stack overflow
• C++ EH exception
• Unknown exception

You can use ADPlus in crash mode instead of UserDump when you are troubleshooting these kinds of exceptions.

Because crash mode uses an "invasive" attach through the CDB debugger, you cannot use this mode in a Microsoft Windows 2000 Terminal Server session, because these operating systems do not permit a debugger in one window station to attach to a process in a different window station. Crash mode is supported in a Terminal Server session on Windows XP and later versions of Windows. Hang mode does work inside a Terminal Server session on any platform.

Note  For a workaround in Windows 2000 Terminal Server by using remote.exe, see Running in Crash Mode Remotely. For more information about invasive and non-invasive attaching, see Starting the Debugger.

When ADPlus is running in crash mode, a debugger remains attached to each process that is specified at the command prompt for the lifetime of that process until a fatal exception is trapped and the process fails (that is, crashes), or until a user presses CTRL+C to detach the debugger from that process. To manually detach the debugger from the process, you must maximize the debugger window and press CTRL+C to break into the debugger. When you press CTRL+C, ADPlus traps the command, begins to list the stacks for all threads to a log file, and then produces a minidump file of the process before it detaches from the debugger. Because crash mode performs an invasive attach, the process is ended when the debugger is detached, and you have to restart it. If the process is a Microsoft Transaction Server (MTS) or COM+ process, the process is restarted automatically the next time that a call is made to a component in that package.

First-Chance Exceptions

Each kind of exception (access violation, stack overflow, and so on) can be raised to a debugger as a "first chance" or "second chance" exception. First-chance exceptions are not fatal unless they are not handled properly by an error handler. If a first-change exception is not handled properly by an error handler, they are raised again as a second-chance exception (which only a debugger can handle). If a debugger does not handle a second-chance exception, the application is shut down.

By default, when ADPlus detects a first-chance (nonfatal) exception for all kinds of exceptions (except unknown and EH exceptions), ADPlus does the following:

1. Pauses the process to log the date and time that the exception occurred in the log file for the process that is being monitored.
2. Logs the thread ID and call stack for the thread that raised the exception in the log file for the process that is being monitored.
3. Produces a uniquely-named minidump file of the process at the time that the exception occurred and then resumes the process. (This step is equivalent to .dump -u /m.)

By default, ADPlus does not produce a unique minidump file for first-chance EH and unknown exceptions because processes frequently encounter many of these exceptions. These kinds of exceptions are typically handled by error handling code in a process or DLL. In other words, these exceptions are typically handled exceptions, and they do not become second-chance (unhandled) exceptions, which end the process.

However, you can configure ADPlus to produce unique minidump files for first-chance EH and unknown exceptions. For more information about how to configure ADPlus, see ADPlus Command-Line Options and ADPlus Configuration Files.

Second-Chance Exceptions

When ADPlus detects a second-chance (fatal) exception for all kinds of exceptions (including EH and unknown exceptions), ADPlus does the following:

1. Pauses the process.
2. Logs the date and time that the exception occurred.
3. Logs the thread ID and the call stack for the thread that raised the exception.
4. Produces a full memory dump of the process at the time that the fatal exception occurred.
5. Exits the debugger. This step ends the process.

ADPlus keeps a separate log file for each process that it monitors.