Intercepting IoCallDriver to PDO from filter driver?

NTDEV
1

<context>
I am trying to work around an annoying Windows bug/feature. When writing a WDDM miniport driver, in order to get Windows to unload the BDD driver attached to the POST display, you need to have the UEFI GOP framebuffer match the range of one of the resource list entries.

Specifically, in dxgkrnl!DpiAddDevice a call to dxgkrnl!DpiFdoDetectPostDevice is made where a IoCallDriver (IRP_MJ_PNP/IRP_MN_QUERY_RESOURCES) is made using the PDO passed to AddDevice.

I want to find a way to intercept this call and append an entry to the UEFI framebuffer directly.

In my device (QEMU device), I set up a BAR pointing to the UEFI framebuffer. This works but causes random crashes on some systems. I suspect it is a bug in either the hypervisor I am using or UEFI or both. To isolate the issue, I am trying to write a driver which does not require modifying the BAR.
</context>

I tried to write a lower filter driver that is installed with the function driver. However, I see that the IoCallDriver is not making it to my filter driver. This makes sense because IoCallDriver is called with the PDO and not the result of IoAttachDeviceToDeviceStack. Do I need to write a bus filter driver? Is there an easier way to achieve what I want?

2

I just had an awful idea. What if I just modify pPhysicalDeviceObject->DriverObject->MajorFunction[IRP_MJ_PNP] in the AddDevice of my function driver? I can capture this one call from dxgkrnl!DpiFdoDetectPostDevice, return the value it expects, and then restore the original function. Some quick WinDbg shows my function is getting called. Can someone tell me why this is a bad idea?

3

This is well-defined behavior. A certain amount of ugliness is forgiven when you're working around a problem.

1 Like