Debugging the Uniaud drivers

Logging

The drivers do some internal logging. To extract this data

copy alsahlp$ alsahlp.log

Uniaud16 sends its logging to the uniaud32 log and each line from Uniaud16 is preceded by "U16:".

The Retail versions of both uniaud16 and uniaud32 only output error messages and other important messages. The Debug versions output much more verbose information.

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...