DosDebug Notifications
| Number | Name | Description |
|---|---|---|
| 0 | DBG_N_SUCCESS | Successful command completion |
| -1 | DBG_N_ERROR | Error detected during command |
| -6 | DBG_N_ProcTerm | Process termination - DosExitList done |
| -7 | DBG_N_Exception | Exception detected |
| -8 | DBG_N_ModuleLoad | Module loaded |
| -9 | DBG_N_CoError | Coprocessor not in use error |
| -10 | DBG_N_ThreadTerm | Thread termination - not in DosExitList |
| -11 | DBG_N_AsyncStop | Async Stop detected |
| -12 | DBG_N_NewProc | New Process started |
| -13 | DBG_N_AliasFree | Alias needs to be freed |
| -14 | DBG_N_Watchpoint | Watchpoint hit |
| -15 | DBG_N_ThreadCreate | Thread creation |
| -16 | DBG_N_ModuleFree | Module freed |
| -17 | DBG_N_RangeStep | Range Step detected |
Note: References to "IP" in the data return descriptions refer to the instruction pointer address. This is the 32-bit equivalent of the CS:EIP instruction pointer, regardless of the CS selector. This is also known as a linearized instruction pointer.
Some notifications (such as DBG_N_ModuleLoad and DBG_N_Watchpoint) may require multiple returns to the debugger. These additional pending notifications will be returned before the process being debugged can execute any more user code, and will be returned on the Go, SStep, or Stop commands.
Note that more notifications might be pending at any time, so a debugger should be ready to handle any notification at any time that a Go, SStep, or Stop command is issued.
If DosDebug returns ERROR_INTERRUPT after a command, the next notification might have been lost. If the process being debugged was executing code at that time (via a Go, SStep, or RangeStep command), it will be stopped automatically. To prevent this, DosDebug should not be used by thread 1 while signals are being used, or the debugger should issue DosEnterMustComplete before issuing the command.
