Windows debugging messages are the primary feature of the debugging version of Windows. These messages identify errors caused by applications and report the type of each error and the information you need to locate the error in your application.
Windows debugging messages have the following form:
FatalExit Code = fatalexit-code
Stack trace:
module-name!segment-name:[function-name+]address
.
.
.
Abort, Break or Ignore?
The fatalexit-code parameter identifies the type of error. For a complete set of possible error codes, see Section C.3, “Debugging Messages.”
The stack trace consists of one or more addresses representing a chain of return addresses from the function that detected the error to the application that made the original function call.
Windows displays the “Abort, Break or Ignore?” prompt at the end of each debugging message.
The following variables are found in Windows debugging messages:
| Variable | Description |
| fatalexit-code | Identifies the type of error (a hexadecimal value). |
| module-name | Specifies the name of the application or of a Windows module (such as USER, GDI, or KERNEL). |
| segment-name | Specifies the name of a segment in the application or module. |
| function-name | Specifies the name of a function in the segment. |
Note:
The segment and function names are available only if a symbol file (.SYM extension) exists for the given module. Otherwise, Windows displays addresses instead of names.
The following example shows a typical debugging message:
FatalExitCode = 0x6040 Stack trace: USER!_FFFE:SHOWCURSOR+0389 USER!_MSGBOX:08D7 USER!_FFFE:922D MYAPP!_TEXT:WINMAIN+001B MYAPP!_TEXT:__astart+0060 Abort, Break or Ignore?
In this example, the stack trace shows that the ShowCursor function in the USER module (USER.EXE) detected the error. The error type is 0x6040. This value is associated with the ERR_BAD_HWND constant; it means that the window handle passed to the function is not valid. The MYAPP application initially called the USER module at the address WINMAIN+001B in its _TEXT segment. A check of the application code at that location will probably reveal the error.
The “Abort, Break or Ignore?” prompt gives you the opportunity to terminate Windows, pass control to the debugger, or ignore the error. When you receive this prompt, you must type one of the following responses:
| Response | Action |
| A | Terminates Windows, returning control to the MS-DOS prompt or to the debugger (if one was running). |
| B | Generates a breakpoint interrupt. If no debugger is running, this response terminates Windows as if you had typed A. If a debugger is running, control passes to the debugger as if you had set a breakpoint in the application. In this case, the CS:IP registers point to an int 3 instruction. To continue execution or to enable single-stepping, you must change the IP register to the address of the next instruction. |
| I | Ignores the error and continues running the application that caused the error. |
| SPACE or NEWLINE | Directs Windows to redisplay the debugging message. This is helpful if the stack trace for the message is exceptionally long. |
Note:
Not all debuggers support the same type of stack trace that Windows displays. If you use the B response to enter a debugger that does not support stack tracing, there is no way to regenerate the trace.