### Postmortem Debugging Overview

Note: This section applies only to OS/2 local debugging.

Postmortem debugging is intended to help you isolate the causes of unanticipated traps or OS/2 exceptions, in programs that are already in production or widespread use. The stages of the postmortem debugging process are:

1. You ship the ITRAPPER utility along with your application.
2. After the end user has experienced a trap or unanticipated OS/2 exception, or in anticipation of such a problem, they reload the application under ITRAPPER. This utility has no effect on the running application. However, if the application traps or throws an unhandled exception, ITRAPPER takes control and writes relevant information to a dump file, using compression algorithms to minimize the dump file size. If the failure causing the trap was an OS/2 exception, the program continues running. If the cause was a trap, the program terminates. A separate dump file is created for each exception or trap. The end user ships you the dump files created by ITRAPPER.
3. You debug the dump file instead of a live object file. Because the dump file contains information about the state of the application at the time of the trap or exception, and is not a live object file, only a subset of debugger features are available. For example, you can view memory and register contents, but you cannot step or run the program or set breakpoints.