Notifies the debugger that a native event has been fired.
If the thread being debugged is a Win32 thread, do not use any members of the Win32 debugging interface. You can call ICorDebugController::Continue only on a Win32 thread and only when continuing past an out-of-band event.
The DebugEvent callback does not follow the standard rules for callbacks. When you call DebugEvent, the process will be in the raw, OS-debug stopped state. The process will not be synchronized. It will automatically enter the synchronized state when necessary to satisfy requests for information about managed code, which may result in other nested DebugEvent callbacks.
Call ICorDebugProcess::ClearCurrentException on the process to ignore an exception event before continuing the process. Calling this method sends DBG_CONTINUE instead of DBG_EXCEPTION_NOT_HANDLED on the continue request, and automatically clears out-of-band breakpoints and single-step exceptions. Out-of-band events can come at any time, even when the application being debugged appears stopped and when an outstanding in-band event already exists.
In the .NET Framework version 2.0, the debugger should immediately continue past an out-of-band breakpoint event. The debugger should be using the ICorDebugProcess2::SetUnmanagedBreakpoint and ICorDebugProcess2::ClearUnmanagedBreakpoint methods to add and remove breakpoints. These methods will skip over any out-of-band breakpoints automatically. Thus, the only out-of-band breakpoints that get dispatched should be raw breakpoints that are already in the instruction stream, such as a call to the Win32 DebugBreak function. Do not try to use ICorDebugProcess::ClearCurrentException, ICorDebugProcess::GetThreadContext, ICorDebugProcess::SetThreadContext, or any other member of the debugging API.
Platforms: See .NET Framework System Requirements.
Header: CorDebug.idl, CorDebug.h
.NET Framework Versions: 4, 3.5 SP1, 3.5, 3.0 SP1, 3.0, 2.0 SP1, 2.0, 1.1, 1.0