Resolved Problems

This is the list of problems that have been completely resolved as of the current release of Network Trace. It is provided as a mechanism to facilitate:

the identification of defects and issues which are resolved but may not have been documented in previous releases
providing a history of all defects fixed to date for regression testing purposes

Number	Symptom	Root Cause	Status
1	Running NTRACE.EXE generates a SYS1808 ring 3 trap. This may occur in the middle of the first status display (after the "Frames" line is printer but before the "Bytes" line) OR it may occur if one presses ENTER to end a trace just after these lines have been displayed. The SYS1808 error has also been reported as a SYS3184.	The second line of the status display had an error where if 0 frames had been collected since the last status display, then printing the "Bytes" line would result in a divide by zero exception. The POPUPLOG.OS2 or the error printed on STDERR would show a SYS1808 with an exception code of 009B. This is a divide by zero exception.	This is a defect in the NTRACE.EXE module. It is resolved in v1.19A.
2	Traces on some fully operational Token-Ring adapters (IBM PCMCIA TR - IBMCOMCS driver) result in no frames captured. No errors are returned and the NTRACE believes itself to be installed successfully.	This condition can be triggered if the PacketFilter in PROTOCOL.INI is set to a filter which the MAC driver cannot support. Example: PROTOCOL.INI specifies a filter of 7 (promiscuous + directed + broadcast) when the adapter does not support promiscuous mode. This failure is not being reported properly to the NTRACE.EXE and the user is not notified that tracing is not occuring.	This is a defect in the NTRACE.OS2 module. It is resolved in v1.38A. The PROTOCOL.INI entry is no longer valid as of Network Trace v1.1. A varient of this problem can exist if the calculated PacketFilter is incorrect or if the user overrides this value with an invalid filter. See the known problems list. In no case with the error be ignored. The user will receive notification of a failure.
3	NTRDIAG.EXE fails during the load of the RXMISC.DLL. The error is a SYS2070 when run.	The 02-10-00 build of RXMISC can sometimes fail when its functions are registered. This will occur on versions of OS/2 which do not support the recent API added to PM called WinWaitForShell. This API is located in the PMWP.DLL at ordinal 512. The POPUPLOG.OS2 will often show the SYS2070 with a reference to PMWP.512.	This is a defect in the RXMISC.DLL module. It is resolved in the 03-10-00 build.
4	NTRDIAG lists MACDUMP as failing and the error "SYS0002: The system cannot find the file specified." is displayed.	This is caused when NTRDIAG.EXE is run while NTRACE.OS2 is NOT loaded. MACDUMP requires NTRACE.OS2 to be loaded in order to operate. In this case, an expected output file from MACDUMP is not available, and the SYS0002 results.	This is a defect in the NTRDIAG.EXE module. It is resolved in v1.05B.
5	NTRACE.OS2 locks up the system if it refuses to load for some reason.	This was caused by some missing termination code related to high resolution timing.	This is a defect in NTRACE.OS2. It is resolved in v1.60.
6	Trap during NDIS binding of NTRACE.OS2.	There was a small window of opportunity during NDIS binding that NTRACE.OS2 could get a NULL pointer instead of a valid MAC entry point with a subsequent TRAP.	This is a defect in NTRACE.OS2. It is resolved in v1.60. This was never reported in production.
7	Trap (most likely a trap 000D) during tracing.	Theoretically possible problem with an internal scattered list of blocks where block length is zero and data pointer is an invalid address.	This is a defect in NTRACE.OS2. It is resolved in v1.60. This was never reported in production.
8	Intermittent time outs during tracing of large amount of data.	This might occur every time an internal 16-bit counter wrapped back to 0. These timeouts may never have been large enough to be noticable, but may have resulted in some lost frames.	This is a defect in NTRACE.OS2. It is resolved in v1.60. This was never reported in production.
9	Frame timestamps as read in a trace analyzer show a highly compressed time period that does not accurately represent what is known to be factual. In some cases, timestamps over a period of minutes or hours would appear to have been generated over only a few seconds.	The Sniffer compatible trace file has the scale of its time unit set ambiguously. If an analyzer interpreted this scale as 1ms then the timestamps will appear correct. Any other interpretation will be incorrect. The fixed module sets the time unit to .83 microseconds, which is known to be fully compatible with the Sniffer file format.	This is a defect in NTRACE.EXE. It is resolved in v1.25.