Modified serial sample stops calling EvtIoWrite in Windows 10

Question

I'm not sure what all information to provide here. I'm using a slightly modified version of the serial sample provided by Microsoft to support our multiport asynchronous RS422 cards. The modification is largely adding IOCTLs for custom clock speeds and 9-bit support. In Windows 7, it works very reliably and has continued to work since 2014. Now in Windows 10, every so often EvtIoWrite seems to simply never call the appropriate function.

The way I determined this is by inserting DbgPrints and using WinDbg along with both RealTerm and/or another small loop program written in C. The behavior is intermittent. What happens is that (using RealTerm or the other small program) I will transmit data continuously, about 4 bytes at a time. At first, it will operate fine on all 4 ports. Then, after a significant amount of time (1 hour+), it'll stop. I have DbgPrints at the entrance and exit of EvtIoWrite (and in a few other key places) and there's no indication that anything fails or exits early. At some point, it simply never enters EvtIoWrite even though WriteFile() starts blocking (and never stops blocking). There's no indication in WinDbg that there's an issue, driver verifier sees no issues, and because of this I can't 'catch' it as it happens and instead have to check it periodically to see if it has stopped. The frequency of the failure seems to increase and decrease with the number of ports in use (~1 hour with all 4 ports running, much longer if ever for less).

I'm at a real loss on how to move forward on debugging this problem.

Thanks!

Answer 1

> even though WriteFile() starts blocking (and never stops blocking)

This means, WriteFile  on some port blocks and never returns? And other 3 ports keep running (with several instances of your "loop program") ?

-- pa

Answer 2

My personal loop program is simple enough and has no threading, so it stops everything as soon as any port blocks but when using RealTerm with 4 instances open (one for each port) they will each individually stop transmitting. Some will continue, some will stop. There appears to be no pattern on which port will stop or continue.

Answer 3

Have you broken into the kernel debugger and dumped the wdfioqueue state? You could have a driver bug which puts the queue into a state where it will not present new io requests.

---

d -- This posting is provided "AS IS" with no warranties, and confers no rights.

Answer 4

I'm a novice at this, but it appears that it's getting into the default queue and just never leaving.

This is what I see:

Dumping WDFQUEUE 0x00004ef048dab3f8
=========================
Parallel, Auto, Power-managed, PowerOn, Can accept, Can dispatch, ExecutionLevelDispatch, SynchronizationScopeDevice
    Number of driver owned requests: 1
    !wdfrequest 0x00004ef04c68f218  !irp 0xffffb10fb5afce10
    Number of waiting requests: 0

    Number of driver owned cancelable requests: 1
!wdfrequest 0x00004ef04c68f218  !irp 0xffffb10fb5afce10


    EvtIoRead: (0xfffff806f8416258) serialfc!SerialEvtIoRead
    EvtIoWrite: (0xfffff806f841b344) serialfc!SerialEvtIoWrite
    EvtIoDeviceControl: (0xfffff806f8411ab4) serialfc!SerialEvtIoDeviceControl
    EvtIoInternalDeviceControl: (0xfffff806f8413bec) serialfc!SerialEvtIoInternalDeviceControl
    EvtIoCanceledOnQueue: (0xfffff806f8417488) serialfc!SerialEvtCanceledOnQueue
    EvtIoStop: (0xfffff806f8417204) serialfc!SerialEvtIoStop
    EvtIoResume: (0xfffff806f84172a4) serialfc!SerialEvtIoResume
0: kd> !irp 0xffffb10fb5afce10
Irp is active with 3 stacks 3 is current (= 0xffffb10fb5afcf70)
 No Mdl: System buffer=ffffb10fb96c8ff0: Thread ffffb10fb780c080:  Irp stack trace.  
     cmd  flg cl Device   File     Completion-Context
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000    

			Args: 00000000 00000000 00000000 00000000
 [N/A(0), N/A(0)]
            0 10 00000000 00000000 00000000-00000000    

			Args: 00000000 00000000 00000000 00000000
>[IRP_MJ_WRITE(4), N/A(0)]
            0  1 ffffb10fb81ba6c0 ffffb10fba956870 00000000-00000000    pending
	       \Driver\Serial
			Args: 00000004 00000000 00000000 00000000

Irp Extension present at 0xffffb10fb5afcfb8:
0: kd> !wdfrequest 0x00004ef04c68f218
Treating handle as a KMDF handle!
    !irp 0xffffb10fb5afce10

!wdfqueue 0x00004ef048dab3f8
   State:  Pending, Allocated by WDF for incoming IRP
   System Buffer 0xffffb10fb96c8ff0, Length 0x4, !wdfmemory 0x00004ef04c68f141

   Cancel Routine: serialfc!SerialCancelCurrentWrite (fffff806f841ba70)
0: kd> !wdfmemory 0x00004ef04c68f141
Treating handle as a KMDF handle!
WDFMEMORY 0x00004ef04c68f141:  Buffer 0xffffb10fb96c8ff0, Length 0x4 (4) bytes
0: kd> !wdfrequest 0x00004ef04c68f218
Treating handle as a KMDF handle!
    !irp 0xffffb10fb5afce10

!wdfqueue 0x00004ef048dab3f8
   State:  Pending, Allocated by WDF for incoming IRP
   System Buffer 0xffffb10fb96c8ff0, Length 0x4, !wdfmemory 0x00004ef04c68f141

   Cancel Routine: serialfc!SerialCancelCurrentWrite (fffff806f841ba70)