BurnInTest 5.1- Parallel Port and USB Loopback Problems

[DanB]

BurninTest 5.1 (1003), Dual xeon server, W2K Server, testing all devices (2 network, 2 serial with loopbacks, 4 USB with loopbacks, 1 parallel with loopback, RAM, disks, CPU, 3D Graphics) in continuous mode.

Parallel Port problem: After an hour or so of continuous test we receive the following popup error-
"Error: Access Violation at 0x55594FF9 (tried to write to 0x01E00FFC), program terminated."
Click OK and BurninTest closes.
Restart BurninTest and restart test. All tests begin cycling except for Parallel Port. No errors flagged but no activity visible.
Stop BurninTest and parallel port error flagged- "Warning: Could not lock parallel port."
Reboot and restart testing- Parallel port testing functions properly for an hour or so then error detailed above is repeated.

USB Problem/Annoyance: USB loopbacks must be physically removed then re-added before testing can continue after error.
During continuous test we begin seeing USB errors after a few hours. Stopping and restarting the test does not cause the USB errors to go away- USB errors begin immediately after restarting test.
Within BurninTest, attempt to refresh USB Loopback list. Restart test and USB errors still there.
Reboot system and restart tests- USB errors still there.
Remove USB devices and reattach (refreshing USB list within Burnintest as we go) and USB testing restarts successfully.

Both of the the Parallel Port and USB problems described above happen with BurninTest 5.1 only. The same tests with the same duty cycle settings can be run using BurninTest 4 without error.

Thanks for looking into this- let me know if you need more info.

[David (PassMark)]

I think the error message, "Could not lock parallel port." can be ignored. This is probably a consequence of the initial Access Violation crash. The sudden crash would have meant that the device driver required for the parallel port test would not have been unloaded. So it would still be in memory holding the port open. Thus provoking the could not lock error.

So the real problem we should look at is the Access Violation error.
The address you indicated (0x55594FF9) is not in our application but might be in part of the O/S or a device driver used by our application. There is no reason to think (from the information you have given) that this crash caused by the parallel port test.

Is the crash address always the same? Can you reduce the tests you are running to try and isolate the problem to one test. For example, just the 3D test, or just the RAM test.

What are the USB errors that you see? There were lots and lots of bugs with USB devices in Windows 2000 (as W2K was developed before USB was really popular). So you need to check you have the MS patches. Are you using USB1 plugs or USB2 plugs?

You should also check you have our latest USB loopback device drivers.

It is a bit strange that a reboot doesn't fix the problem. My guess would be that the reboot nevers resets the USB hardware in the PC, you probalby need a power down the entire PC to force a reset.

-------
David

[DanB]

Thanks for the info David. I'll try testing devices individually to try and isolate what's causing the problem. Note though that testing with 4.0 does not exhibit these problems.