Code integrity check triggers bugcheck in KMDF driver

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.

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

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?

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.

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.

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.

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:

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. :frowning:

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 <your_driver_name> 0x70

Please substitute the name of your driver for <your_driver_name> … 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

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!

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