The Win32 versions of the Microsoft Extended Fax Software can generate a time-stamped log of all communications activity generated by the fax drivers. This logging is enabled by default in the debug builds and disabled by default in the retail builds.
Information is logged to memory, and dumped to a file (C:\FAX0.MON by default), when releasing the port. On Win95, with TAPI, this occurs after each call is complete.
Utility DLL AWMCFG32.DLL, included in the TOOLS section of the MDK, lets you configure communications logging via the Advanced Modem Properties dialog box of the fax status application. Place this DLL in the \WINDOWS\SYSTEM directory.
If this DLL is unavailable, the following information can be used to manually edit the registry to enable logging.
Logging is configured via registry entries, which are all of type REG_SZ, and stored under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\At Work Fax\Local Modems\General. The entries are documented below.
Name | Default | Comments |
MonitorComm | 0 | 1 enables logging. [Default is 1 for the debug build.] |
MonitorBufSizeKB | 64 | Size of memory buffer in Kbytes. Maximum value supported in Win95 is 2000. |
MonitorMaxOldSizeKB | 64 | Maximum existing file size. If the existing file size is greater than this value, the existing file is renamed to OLD.MON, and file logging starts with an empty FAX0.MON. |
MonitorDir | C:\ | Directory into which the log file is written. Note that log file name is fixed as FAX0.MON. |
Utility Win32 console application DMON.EXE dumps a text version of the file. The current version expects the file to be C:\FAX0.MON. Alternately, you can click on the "view log" button in the modified advanced fax modem properties dialog that is enabled when using the AWMCFG32 DLL. The following documentation refers to "output from DMON.EXE" -- this should be interpreted as either the output of the DMON.EXE utility, or the text file that is generated automatically when using the AWCFG32 DLL.
Following is sample output from the current version of DMON.EXE. The first column is time (with respect to an arbitrary baseline) in minutes:seconds; the second column is elapsed time in seconds (modulo 60 seconds) between end of previous entry and start of current entry; and the third column is whether it is a read or write operation.
===== 02/26/1995 15:02:46 Modem Init: Start =====
These special "event" entries contain actual date and calendar time, obtained from the SYSTEMTIME structure saved in the log. Event entries are made at the start and end of significant events, such as modem initialization, dialing, and answering.
59:57.983 57.983 W AT&FS0=0E0V1Q0.
Initial timings 59:57.983 and 57.873 are meaningless because the times are measured with respect to an arbitrary baseline. The final '.' is actually a '\n' (line feed) character.
59:58.083 00.050 R E0V1Q0...OK..
Log indicates 50ms delay between the end of the previous command and the 1st character of the response. However, be warned that that these timings are based on GetTickCount, which typically has a 50ms resolution.
59:58.423 00.040 W AT.
59:58.674 00.251 R ..OK..
Log indicates a 250ms delay getting the "OK" response to "AT."
59:58.714 00.040 W ATI3.
59:58.974 00.250 R ..V4.02....OK..
59:59.064 00.040 W ATS7=255&D3&K4.
59:59.365 00.251 R ..OK..
59:59.405 00.040 W ATX4S8=2M1L1.
59:59.705 00.250 R ..OK..
===== 02/26/1995 15:02:48 Modem Init: End (0x0) =====
===== 02/26/1995 15:03:11 Modem Dial ("13939"): Start =====
00:23.139 23.434 W AT+FCLASS=1.
Log indicates 23 seconds has elapsed since the previous command. Be warned that the 2nd column only indicates relative time modulo 60 seconds, so if in doubt check the 1st column.
00:23.720 00.581 W AT.
00:23.870 00.150 R ..OK..
00:24.070 00.200 W ATDT 13939.
00:37.049 12.979 R ..CONNECT..
The modem took 13 seconds to respond to the dial command.
===== 02/26/1995 15:03:25 Modem Dial: End (0x1) =====
00:39.152 02.103 R ff [1]
This entry is in "hex display mode" (see below). Log indicates one byte, 0xff , was read. In this case it is the first byte of the DIS frame from the remote machine.
00:39.152 00.000 R 03 [1]
.... etc ....
DMON.EXE does not print all the information in the log and, for enhancing readability, collapses multiple read log entries into a single entry in cases when it believes the modem is in command mode. For example, the modem driver reads response "\r\nOK\r\n" one character at a time, and makes a time stamped log entry for each character read. DMON.EXE collapses all these entries into a single entry and displays it as follows:
00:23.870 00.150 R ..OK..
Note that it displays both '\r' and '\n' as '.'.
If DMON.EXE does not believe the modem is in command mode, it displays bytes read/written in "hex mode". In this mode, it displays only as many bytes as can fit one 80-character line, and follows that with the actual number of bytes, in brackets, for example:
33:40.692 00.000 W ff 03 43 20 20 20 20 20 34 31 30 36 20 ... [23]
DMON.EXE creates a second file, DMON.OUT, which is simply a dump of every byte written-to or read-from the port.
A final caveat is that the timestamps in the log are generated at the time the appropriate Win32 comm function was called to read or write data, not the time at which the data was actually written to or read from the physical serial port. If there is a significant delay between these two times, it indicates a problem with the comm drivers. The only way to verify these delays is to use a serial analyzer.