DosDebug Notifications: Difference between revisions
No edit summary |
No edit summary |
||
| Line 33: | Line 33: | ||
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. | 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. | Some notifications (such as [[Debug_Notifications#DBG_N_ModuleLoad|DBG_N_ModuleLoad]] and [[Debug_Notifications#DBG_N_Watchpoint|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. | 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. | 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. | ||
[[Category:Debug Command]] | [[Category:Debug Command]] | ||
Latest revision as of 05:01, 16 May 2025
| 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.