WDM upper filter STATUS DEVICE CONFIGURATION_ERROR
-
Hello, I have a WDM upperfilter driver for some class devices(WPD, Printers). The wdm upper filter is from WDK generic toaster filter sample. The problem that I have is for some device that support or install UMDF drivers I receive STATUS DEVICE CONFIGURATION_ERROR at IRP_MN_START_DEVICE and device failed to start. Can you help me please or give me an advice? Thank you.
-
Hello, I have a WDM upperfilter driver for some class devices(WPD, Printers). The wdm upper filter is from WDK generic toaster filter sample. The problem that I have is for some device that support or install UMDF drivers I receive STATUS DEVICE CONFIGURATION_ERROR at IRP_MN_START_DEVICE and device failed to start. Can you help me please or give me an advice? Thank you.
What does 'U' stand for?
-
What does 'U' stand for?
-
And the toaster samples are kernel drivers. So how can you load a kernel filter on a usermode driver?
-
And the toaster samples are kernel drivers. So how can you load a kernel filter on a usermode driver?
-
You don't understand. I'm an upper filter driver(KERNEL) over a device class that use in his stack an UMDF driver...
The driver is in usermode. You cant run kernel code (the filter) in user mode, and vice versa.
-
The driver is in usermode. You cant run kernel code (the filter) in user mode, and vice versa.
-
You mean it works when you load it onto the toaster driver. Of course it will. However kernel code cant run in user mode, and a UMDF driver is user mode. Therefore the toaster filter driver, which is kernel code, cant be used on your UMDF driver. You really have no idea what you are doing do you? You don't even understand the concept of user mode and kernel?
-
My friend: I have a WDM filter driver, based on WDK toaster sample, that I am using to filter portable devices (mainly Phones), as upper filter. During AddDevice phase, I am querying device properties (such Description, Manufacturer and so on) and then attaching to device. I can see the IRP_MN_START_DEVICE, which I send down to next lower driver after setting a completion routine. This is working fine on most of the machines I am testing on, but on some systems (every XP and some Windows 7 and Server 2008), when I send the IRP_MN_START_DEVICE down to next driver, I get a STATUS_DEVICE_CONFIGURATION_ERROR, so this is preventing the device from being installed in the first place. I have managed to overcome this error by editing the hardware ID registry key for the device and creating "UpperDriverOk" and "KernelModeClientPolicy" values, setting them to 1. This way the device starts without issues and I can filter it as normal. Now, I am aware of Portable Devices being managed by an UMDF driver, but does that explains the issue with Start Device phase? I haven't found any differences between those systems with the issue and those that are working fine without needing the "registry values" workaround. Is there any system setting or service configuration that might be helping (or ruining) this filtering scenario? Would it be possible to apply the "KernelModeClientPolicy" workaround for the whole system and not separately for every single Phone device?
-
You mean it works when you load it onto the toaster driver. Of course it will. However kernel code cant run in user mode, and a UMDF driver is user mode. Therefore the toaster filter driver, which is kernel code, cant be used on your UMDF driver. You really have no idea what you are doing do you? You don't even understand the concept of user mode and kernel?
My friend: I have a WDM filter driver, based on WDK toaster sample, that I am using to filter portable devices (mainly Phones), as upper filter. During AddDevice phase, I am querying device properties (such Description, Manufacturer and so on) and then attaching to device. I can see the IRP_MN_START_DEVICE, which I send down to next lower driver after setting a completion routine. This is working fine on most of the machines I am testing on, but on some systems (every XP and some Windows 7 and Server 2008), when I send the IRP_MN_START_DEVICE down to next driver, I get a STATUS_DEVICE_CONFIGURATION_ERROR, so this is preventing the device from being installed in the first place. I have managed to overcome this error by editing the hardware ID registry key for the device and creating "UpperDriverOk" and "KernelModeClientPolicy" values, setting them to 1. This way the device starts without issues and I can filter it as normal. Now, I am aware of Portable Devices being managed by an UMDF driver, but does that explains the issue with Start Device phase? I haven't found any differences between those systems with the issue and those that are working fine without needing the "registry values" workaround. Is there any system setting or service configuration that might be helping (or ruining) this filtering scenario? Would it be possible to apply the "KernelModeClientPolicy" workaround for the whole system and not separately for every single Phone device?
-
My friend: I have a WDM filter driver, based on WDK toaster sample, that I am using to filter portable devices (mainly Phones), as upper filter. During AddDevice phase, I am querying device properties (such Description, Manufacturer and so on) and then attaching to device. I can see the IRP_MN_START_DEVICE, which I send down to next lower driver after setting a completion routine. This is working fine on most of the machines I am testing on, but on some systems (every XP and some Windows 7 and Server 2008), when I send the IRP_MN_START_DEVICE down to next driver, I get a STATUS_DEVICE_CONFIGURATION_ERROR, so this is preventing the device from being installed in the first place. I have managed to overcome this error by editing the hardware ID registry key for the device and creating "UpperDriverOk" and "KernelModeClientPolicy" values, setting them to 1. This way the device starts without issues and I can filter it as normal. Now, I am aware of Portable Devices being managed by an UMDF driver, but does that explains the issue with Start Device phase? I haven't found any differences between those systems with the issue and those that are working fine without needing the "registry values" workaround. Is there any system setting or service configuration that might be helping (or ruining) this filtering scenario? Would it be possible to apply the "KernelModeClientPolicy" workaround for the whole system and not separately for every single Phone device?
No, you didn't explain yourself at all well. I have no idea what the cause of your failure is.
-
No, you didn't explain yourself at all well. I have no idea what the cause of your failure is.