none
Modified serial sample stops calling EvtIoWrite in Windows 10 RRS feed

  • 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!

    Tuesday, November 12, 2019 4:42 PM

All replies

  • 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

    Wednesday, November 13, 2019 1:26 AM
  • 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.

    Wednesday, November 13, 2019 3:00 PM
  • 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.

    Thursday, November 14, 2019 12:17 AM
  • 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)
    

    Thursday, November 14, 2019 9:28 PM