Debugging the Uniaud drivers

If you open a ticket, additional information will almost always be necessary. You can save a lot of time by always attaching the log file created by the testlog.cmd program to your ticket when you open it, rather than waiting for the developer to ask for it.

Known Problems and Limitations

If you are using ACPI.PSD, you must have version 3.20.01 or later. Uniaud32 will not work with ACPI.PSD versions older than 3.20.01.

Capturing a testlog log file

If you don't already have the current version of testlog.cmd, you can download it here: ​Get testlog.cmd

Open a command window and execute the testlog command:

testlog uniaud

Real Time Logs

You can see the log output in real time by connecting a terminal or second system to the serial port.

Enable the serial output by adding the "/P:1" or the "/P:2" switch to Uniaud32.sys in your config.sys. /P:1 specifies to use serial port 1, and /P:2 specifies to use serial port 2.

DEVICE=D:\MMOS2\UNIAUD32.SYS /P:1

Set the serial port baud rate to 115200, 8 bits, no parity.

mode com1:115200,n,8,1

Trap Dumps

If you are getting kernel or driver exceptions, a trap dump volume can often get you the data to figure out where and why this is happening. See ​http://home.earthlink.net/~steve53/os2diags/TrapDumpRef.txt for a setup guide.

The Kernel Debugger

There are times when you just has to watch the code execute to understand the issue. The kernel debugger can help here. You need a second system and either a serial port to or a supported NIC to use the debugger. You can not use a NIC for debugging driver initialization and such. Not enough of the OS is loaded. However, NIC debugging can make working other areas of driver operation go faster.

The kernel debugger comes in two flavors. There's the traditional command line debugger and there's the ICAT source level GUI debugger. Which is best depends on which part of the driver code you are working on. The source level debugging is handy, but it can be slow over a serial port.

More to come...