Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

Code integrity check triggers bugcheck in KMDF driver

Benjamin_HöglingerBenjamin_Höglinger Member - All Emails Posts: 7

Greetings!

I've got an interesting crash scenario I don't fully understand. My otherwise fine and dandy working KMDF bus driver decides to crash (KMODE_EXCEPTION_NOT_HANDLED (1e)) when run on a machine with HVCI (reproducible with Code integrity checks on in Driver Verifier) right here:

status = WdfRequestForwardToIoQueue(Request, xusb->HoldingUsbInRequests);

return (NT_SUCCESS(status)) ? STATUS_PENDING : status;

!wdfkd.wdflogdump gave me:

57: FxIoQueue::Vf_VerifyForwardRequest - Cannot forward a request to a different WDFDEVICE 0x00007CF5A1B7A308 

which is what I'm struggling with. The Request and Queue objects are handled by the same WDFDEVICE and I got no complaints with verifier off.

Thanks in advance. I ofc. can provide any other detail from the crash dump necessary but I didn't want to clutter the first post too much.

Comments

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 6,836

    I got no complaints with verifier off

    Well THAT doesn't mean anything, right? I mean... there are lots of things that will "work" without Verifier, but are clearly invalid. Just sayin...

    What function in your WDF driver is it that this code you showed us appears? Offhand, I don't understand your use of STATUS_PENDING in the code clip.

    Also... can you please show us the output from "!WDFKD.WDFDRIVERINFO 0x70" ??

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 12,715
    via Email
    Benjamin_Höglinger wrote:
    > I've got an interesting crash scenario I don't fully understand. My otherwise fine and dandy working KMDF bus driver decides to crash (KMODE_EXCEPTION_NOT_HANDLED (1e)) when run on a machine with HVCI (reproducible with Code integrity checks on in Driver Verifier) right here:
    >
    > status = WdfRequestForwardToIoQueue(Request, xusb->HoldingUsbInRequests); return (NT_SUCCESS(status)) ? STATUS_PENDING : status;
    >
    > !wdfkd.wdflogdump gave me:
    >
    > 57: FxIoQueue::Vf_VerifyForwardRequest - Cannot forward a request to a different WDFDEVICE 0x00007CF5A1B7A308
    >
    > which is what I'm struggling with. The Request and Queue objects are handled by the same WDFDEVICE and I got no complaints with verifier off.

    The fact that you are a bus driver means you are probably seeing both
    FDO and PDO requests, which would be two different WDFDEVICEs. You're
    sure you're not passing a PDO request into an FDO queue here?

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Benjamin_HöglingerBenjamin_Höglinger Member - All Emails Posts: 7

    Thanks for the suggestions. The function in question is this one (line with the hickup).

    Requested output:

    3: kd> !WDFKD.WDFDRIVERINFO 0x70
    ----------------------------------
    warning: could not retreive framework image for client driver 0x70
    Default driver image name: 0x70
    WDF library image name: 
    hint: Are symbols available for this driver?
    hint: Did you provide the correct .sys/.dll extension in the drivername parameter?
    
    Could not find 0x70 in client list
    

    This however returned:

    3: kd> !WDFKD.WDFDRIVERINFO ViGEmBus
    ----------------------------------
    Default driver image name: ViGEmBus
    WDF library image name: Wdf01000
     FxDriverGlobals  0xffff830a5b3439f0
     WdfBindInfo      0xfffff80ba38ac020
       Version        v1.9
     Library module   0xffff830a57dd61e0
       ServiceName    \Registry\Machine\System\CurrentControlSet\Services\Wdf01000
       ImageName      Wdf01000
    ----------------------------------
    WDFDRIVER: 0x00007cf5a4850968
    Driver logs: Not available 
    Framework logs: !wdflogdump ViGEmBus.sys -f
    
        !wdfdevice 0x00007cf5a1b7a308 ff (FDO)
            Pnp/Power State: WdfDevStatePnpStarted, WdfDevStatePowerD0, WdfDevStatePwrPolStarted
            context:  dt 0xffff830a5e485fe0 ViGEmBus!FDO_DEVICE_DATA (size is 0x20 bytes)
            <no associated attribute callbacks>
            !wdfdevicequeues 0x00007cf5a1b7a308
    
            !wdfdevice 0x00007cf59d005478 ff (PDO)
                Pnp/Power State: WdfDevStatePnpStarted, WdfDevStatePowerD0BusWakeOwner, WdfDevStatePwrPolStartingSucceeded
                context:  dt 0xffff830a62ffae70 ViGEmBus!PDO_DEVICE_DATA (size is 0x48 bytes)
                <no associated attribute callbacks>
    
                context:  dt 0xffff830a626274b0 ViGEmBus!XUSB_DEVICE_DATA (size is 0x30 bytes)
                <no associated attribute callbacks>
                !wdfdevicequeues 0x00007cf59d005478
    
    ----------------------------------
    
    WDF Verifier settings for ViGEmBus.sys is ON
      Enhanced verifier is OFF
      Pool tracking is ON
      Handle verification is ON
      IO verification is ON
      Lock verification is ON
      Power reference tracking is OFF (stack capture is OFF)
      Handle reference tracking is OFF
    ----------------------------------
    

    Yes, I am confident, that it's the PDO's queue.

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 12,715
    via Email
    Benjamin_Höglinger wrote:
    > Thanks for the suggestions. The function in question is this one (line with the hickup).
    >
    > Requested output:
    >
    > 3: kd> !WDFKD.WDFDRIVERINFO 0x70 ---------------------------------- warning: could not retreive framework image for client driver 0x70 Default driver image name: 0x70 WDF library image name: hint: Are symbols available for this driver? hint: Did you provide the correct .sys/.dll extension in the drivername parameter? Could not find 0x70 in client list

    We will have to figure out how to paste output so that it does not get
    wordwrapped.  I assume there is a button for this.


    > This however returned:
    > ...
    > Yes, I am confident, that it's the PDO's queue.

    I appreciate your confidence, but the verifier says there is a problem. 
    Have you done a !wdfrequest to see the details, and a !wdfdevicequeues
    or !wdfqueue do verify the device association? It's easy to confuse
    devices in a bus driver.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,019

    If you want to forward from your PDO's queue to your FDO's queue you need to call WdfRequestForwardToParentDeviceIoQueue.

    However, using WdfRequestForwardToIoQueue with Verifier enabled should only result in the call failing, not to a crash. So you might have another problem here that needs fixed.

    -scott
    OSR

  • Benjamin_HöglingerBenjamin_Höglinger Member - All Emails Posts: 7

    Thanks Tim, I'll double-check with the path you suggested. Also I crafted the post with Markdown as suggested, so pardon me if it got mangled.

    Hey Scott, no, that's not what I'm trying, PDO requests shall remain in PDO queues :smile:

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 6,836
    edited October 2

    We will have to figure out how to paste output so that it does not get wordwrapped.

    It's not word-wrapped here in the group online. :(

    Mr. Höglinger... you're making us work AWFULLY hard to try to help you.

    So... instead of pointing me to your code, can you tell me what function... what WDF Callback... you're in when you get this error? I'd rather not download your entire project just to help you with this problem.

    Requested output:
    3: kd> !WDFKD.WDFDRIVERINFO 0x70

    Sorry... that's !WDFKD.WDFDRIVERINFO 0x70

    Please substitute the name of your driver for ... The 0x70 I gave you are the flags, right?

    Yes, I am confident, that it's the PDO's queue.

    Hmmmm... According to the output:

    57: FxIoQueue::Vf_VerifyForwardRequest - Cannot forward a request to a different WDFDEVICE 0x00007CF5A1B7A308

    You're forwarding the Request to the FDO. The WDF Device ending in 0x...A308 is your FDO.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Benjamin_HöglingerBenjamin_Höglinger Member - All Emails Posts: 7

    Oh dear, this is so embarrassing... @Tim_Roberts you were right on the spot. I accidentally created my PDO queues on the FDO device object by confusing the variable names passed to WdfIoQueueCreate... It works now. Thank you so much!

  • Benjamin_HöglingerBenjamin_Höglinger Member - All Emails Posts: 7
    edited October 2

    @Peter_Viscarola said:
    Mr. Höglinger... you're making us work AWFULLY hard to try to help you.

    Not my intention, I interpreted your response as you'd have liked to see the full source of the function the snippet was called in. So since it's open source anyway I thought a link would be quickest instead of pasting more snippets with probably missing information.

    And drop the "Mr." please, I don't think I deserve one yet :wink:

    @Peter_Viscarola said:

    Yes, I am confident, that it's the PDO's queue.

    Hmmmm... According to the output:

    57: FxIoQueue::Vf_VerifyForwardRequest - Cannot forward a request to a different WDFDEVICE 0x00007CF5A1B7A308

    You're forwarding the Request to the FDO. The WDF Device ending in 0x...A308 is your FDO.

    Right on the spot. WinDbg confirmed that, a simple mistake hidden in plain sight. Will have more trust in the verifier in the future!

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!