Dump Formatter Installation

The Dump Formatter may be installed together with PMDF by using the installation procedure supplied with the OS2PDP package. Alternatively copy the *.EXE files to either a private directory or a directory in your current PATH. The only files the Dump Formatter accesses implicitly are Symbol Files, which if used, are convenient to have installed in the same directory as the *.EXE program files.

The command line syntax for Dump Formatter is as follows:

──┬─ DF_RET ─┬─ dumpfile ─┬───────────────┬─────────────────
    │          │            └─ -P pipname ──┘
    └─ DF_DEB ─┘

The parameters have the following meaning:

dumpfile

The file name of the (decompressed) dump to be analysed. If a path is not prefixed to the file nape then the Dump Formatter assumes the current path. See Dump Decompression below.
-Ppipename
The name of a named pipe through which Dump Formatter output and commands are channelled.

Note: This parameter is intended for use when df_ret.exe or df_deb.exe is started from another program using the DosExecPgm API.

Note:

If no parameters are entered then the Dump Formatter give a syntax message. This message implies that a COM port may also be used as an interface, but this has not been implemented.

When the Dump Formatter is started it displays the build level of the system from which the dump was taken and then the build level of the formatter. If these do not match unpredictable results may occur. However, if the levels are close then it is probably safe to use the Dump Formatter, though not guaranteed.

If the incorrect type of Dump Formatter is used, for example retail Dump Formatter with a ALLSTRICT dump, then the Dump Formatter will probably trap. If it does not, then an error message will appear.

In general the dump formatter traps for one of three reasons:

• The reasons stated above, where there are type and level mismatches.

• The dump file is incomplete or corrupted.

• The Dump Formatter stack overflows.

The latter problem usually occurs when the .P command is used. This is sometimes circumvented by using the EXEDHR utility to increase the stack size of the Dump Formatter. Another approach is to use the %PS REXX to display each thread slot individually.

As part of the initialisation sequence, the Dump Formatter attempts to load symbol files, from the current directory, for each module that was loaded on the dumped system.

Notes:

Windows, WINOS2 and DOS symbol files are not usable under the Dump Formatter However, the SYMLST REXX exec in the tools directory of the accompanying CD-ROM may be used to list a symbol file. This can sometimes be used in conjunction with the Dump Formatter provided that at least one location of a module or its data can be determined absolutely.

Symbol files not present in the current directory may be manually loaded using the WA command. The syntax and function of this command differs subtly from the Kernel Debugger equivalent:

• Under Dump Formatter names are symbol file names unlike Kernel Debugger where they are symbol map names. This allows relative path names to be used.

• Under Dump Formatter WA reads the symbol file, whereas under Kernel Debugger it is just marked active provided it was loaded when the module was loaded.

The Dump Formatter prompts for command input with a single # sign. Unlike the Kernel Debugger this is not used to signify the processor mode or whether paging is enabled. Consequently the Dump Formatter always assumes that the current processor mode is Protect Mode with Paging Enabled. The user must therefore explicitly prefix segment:offset addresses in Virtual 8089 mode with an ampersand (&).

Commands may be interrupted by pressing the ESC key.

---

[Back: Taking a System Dump]
[Next: Dump Decompression]