possible wrong IRP being processed by unrelated device

I have a hang in NT kernel. It is VERY rare and takes about 1 month of
effort to reproduce. However before the system is deployed to 3000 servers
it needs to be fixed.

It appears to me that Pathworks (which implements a network protocol
called DECnet) is attempting to process an IRP for a serial port (Serial 6

  • COM7), this results in a hang (or sometimes a blue screen in NDIS).

I don’t know how the IRP could get from the serial driver through IO
manager to the network stack. Neither are related filter drivers, and RAS
is not installed.

I suspision is Pathworks (because it has a bad history). The serial driver
(written by 3rd party) is largely based on the DDK example (only 8 x 16550
on PCI), the vendor is being very helpful and will send me source code. I
have no access to source or symbols for Pathworks.

Below is an abbreviated and commented kd log:

Is there any way that I can tell how deciocb ended up processing this IRP
(ideally without spending another month - not joking) to reproduce the
problem. I still have the windbg session alive.

I have been hunting through the OSR book for clues.

kd> k
nt!RtlpBreakWithStatusInstruction
nt!KeUpdateSystemTime+0x13e
EL90xBC4+0x504d <– 3Com NIC driver
NDIS!ndisMStartSendPackets+0x4ac
NDIS!ndisMProcessDeferred+0x1aa
NDIS!ndisMSendToSendPackets+0x16f
Decndis+0x2cf7
Decndis+0xc54
// then lots more frames in Pathworks (Dec***)
Deciocb+0xec4 // this is the dispatch routine arg1 = 83ce2370, arg2 =
84e472c8 (see below)
nt!IofCallDriver+0x37
nt!IopSynchronousServiceTail+0x6a
nt!IopXxxControlFile+0x6f3
nt!NtDeviceIoControlFile+0x28
nt!KiSystemService+0xc4
next is DeviceIoControl user mode etc.

kd> !devobj 83ce2370 // expand the device object – this is as expected
Device object is for:
DECIOCB \Driver\Deciocb DriverObject 83ce2030
Current Irp 00000000 RefCount 3 Type 00008000 DevExt 83ce2428
Device queue is not busy.

kd> !irp 84e472c8 // expand IRP that deciocb is processing
Irp is active with 1 stacks 1 is current
No Mdl System buffer = 80578aa8 Thread 85dca300: Irp stack trace.
cmd flg cl Device File Completion-Context

3 0 1 84aac580 ff8923a8 801dd6c4-ff8b5c68 pending
\Driver\SsNt SCSIPORT!ScsiPortInternalCompletion
Args: 00000001 00000000 00000000 00000007

// The device reported in the IRP is not as expected: SsNt is the serial
port driver. Strangely the device in the first argument to the Pathworks
driver is okay, but the IRP in the second argument is for the serial port
and appearently corrently formed.

kd> !devobj 84aac580
Device object is for:
Serial6 \Driver\SsNt DriverObject 848e5dd0
Current Irp 00000000 RefCount 1 Type 0000001b DevExt 84deb788
Device queue is not busy.

Any clues, or advise are very welcome.

Thanks.