Hi,
I’ve searched previous posts about removing my device from the “Safely Remove Hardware” wizard. They’ve dealt with WDM code.
I’ve made the transformation to UMDF, and added these lines to the code:
in CMyDevice::Initialize (called from CMyDevice::CreateInstance), right after FxDeviceInit->SetLockingConstraint(WdfDeviceLevel),
FxDeviceInit->SetPnpCapability(WdfPnpCapSurpriseRemovalOk ,WdfTrue);
FxDeviceInit->SetPnpCapability(WdfPnpCapRemovable,WdfFalse);
(And later comes FxDriver->CreateDevice(FxDeviceInit, unknown, &fxDevice))
This didn’t help. I’ve put a breakpoint later on in the code and saw that the values of the data members m_PnpCapSurpriseRemovalOk and m_PnpCapRemoveable of m_FxDevice are WdfUseDefault (0), which, to my understanding, means that the changes I’ve made to these values did not take effect.
Was I supposed to define something more, or maybe these lines should be located elsewhere in the code?
Gadi
Addition -
FxDeviceInit->GetPnpCapability(WdfPnpCapSurpriseRemovalOk);
and
FxDeviceInit->GetPnpCapability(WdfPnpCapRemovable);
right after setting them to the values specified above, retrieves the correct values.
But, as I specified before, putting a bp later on in the code shows that the values in m_FxDevice were not updated.
Gadi
There is a commit call you must make after setting the values.
D
Sent using my smartphone, apologies forany typos
-----Original Message-----
From: “xxxxx@n-trig.com”
To: “Windows System Software Devs Interest List”
Sent: 07/05/07 7:21 AM
Subject: [ntdev] Safely Remove Hardware in UMDF
Hi,
I’ve searched previous posts about removing my device from the “Safely Remove Hardware” wizard. They’ve dealt with WDM code.
I’ve made the transformation to UMDF, and added these lines to the code:
in CMyDevice::Initialize (called from CMyDevice::CreateInstance), right after FxDeviceInit->SetLockingConstraint(WdfDeviceLevel),
FxDeviceInit->SetPnpCapability(WdfPnpCapSurpriseRemovalOk ,WdfTrue);
FxDeviceInit->SetPnpCapability(WdfPnpCapRemovable,WdfFalse);
(And later comes FxDriver->CreateDevice(FxDeviceInit, unknown, &fxDevice))
This didn’t help. I’ve put a breakpoint later on in the code and saw that the values of the data members m_PnpCapSurpriseRemovalOk and m_PnpCapRemoveable of m_FxDevice are WdfUseDefault (0), which, to my understanding, means that the changes I’ve made to these values did not take effect.
Was I supposed to define something more, or maybe these lines should be located elsewhere in the code?
Gadi
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Gadi,
UMDF has a bug where UMDF driver supplied capabilities get overwritten
by the ones reported by lower drivers.
I don’t know why the values will be set to WdfUseDefault - they should
be set to TRUE/FALSE as reported by lower drivers. We will look into it.
Since UMDF honors capabilities reported by lower drivers, USB devices
should by default get SurpriseRemovalOK. So unless you want surprise
removal not OK, you should be fine despite the bug.
Do you see a different behavior (aka unsafe surprise removal popup)?
Thanks,
Praveen
Doron,
I’ve looked for a commit callback which handles pnp capabilities and could not find one. I only found CommitPnpState, which, to my understanding, commits the state and not the capabilities.
Praveen,
What I see is that the “Safely Remove Hardware” icon appears on the bottom right side of the screen, and my device is on its list (and is the only one. The icon appears as I install the driver).
As I understood from previous posts, the values I defined for the pnp capabilities (WdfPnpCapSurpriseRemovalOk = WdfTrue, WdfPnpCapRemovable = WdfFalse) should have prevented the “Safely Remove Hardware” icon from appearing (for my HW).
Correct me if I’m wrong.
And if everything is correct, and no commit callback is missing, when will this bug be fixed or is there a workaround for this issue?
Thanks,
Gadi
Gadi,
You are right, there is no commit callback for capabilities and you
don’t need commit. It is only for SetPnpState.
I stand corrected. For USB devices PDO actually clears the
SurpriseRemovalOK flag (not set it). If UMDF driver sets this flag, UMDF
sets it on query capability irp’s way down. But it gets cleared by PDO
when the irp reaches PDO.
UMDF needs to re-apply the flag on the way up, which it doesn’t do
currently. That is why the capabilities specified by your driver get
overridden.
This will be fixed in future versions but right now there is no easy
workaround short of sticking a kernel mode filter to handle setting of
capabilities on the way up - this should be fairly straightforward to do
with a KMDF driver. Not sure how big a deal this is for you.
Praveen
ps: The member values you were looking at - firstly, I don’t know if you
are using the right address of the object, secondly, these members are
transient - they are only applicable during device add, so you can’t
infer actual capabilities from them, thirdly, they are internal
implementation detail.
Praveen,
Any estimtation when will the version with this fix be released?
We need to know wether to wait for it or add the KMDF driver you’ve mentioned.
Also, have you seen my latest post in “Profiling UMDF Drivers”? I’ve added a question which I think is pretty trivial for you guys.
Thanks,
Gadi
Gadi Tunes wrote:
Any estimtation when will the version with this fix be
released? We need to know wether to wait for it or
add the KMDF driver you’ve mentioned.
Setting surprise-removal to OK with a KMDF filter is very easy…I wouldn’t bother waiting for a fix. (Frankly I’m amazed that you can’t do this in UMDF, but…)
Here’s all the code you need:
NTSTATUS DriverEntry(IN PDRIVER_OBJECT DriverObject,
IN PUNICODE_STRING RegistryPath)
{
WDF_DRIVER_CONFIG config;
WDFDRIVER hDriver;
WDF_DRIVER_CONFIG_INIT(&config, FiltEvtDeviceAdd);
return (WdfDriverCreate(DriverObject, RegistryPath,
WDF_NO_OBJECT_ATTRIBUTES, &config, &hDriver));
}
NTSTATUS FiltEvtDeviceAdd(IN WDFDRIVER Driver,
IN PWDFDEVICE_INIT DeviceInit)
{
WDFDEVICE device;
NTSTATUS status;
WDF_DEVICE_PNP_CAPABILITIES pnpCaps;
WdfFdoInitSetFilter(DeviceInit);
status = WdfDeviceCreate(&DeviceInit,
WDF_NO_OBJECT_ATTRIBUTES, &device);
if (!NT_SUCCESS(status)) return status;
WDF_DEVICE_PNP_CAPABILITIES_INIT(&pnpCaps);
pnpCaps.SurpriseRemovalOK = WdfTrue;
WdfDeviceSetPnpCapabilities(device, &pnpCaps);
return status;
}
Do I add this in my current project (the UMDF driver code), or open a new project for a KMDF driver which is underneath the UMDF driver in the device stack, and connect them?
Gadi
Gadi Tunes wrote:
Do I add this in my current project (the UMDF driver code), or open
a new project for a KMDF driver which is underneath the UMDF
driver in the device stack, and connect them?
You build kernel drivers with the WDK build environment, not any project in VS. Also, this would need to be an upper filter, not lower.
> Also, this would need to be an upper filter, not lower.
You will actually set this as a lower filter to UMDF reflector driver
but above WinUSB. Kernel mode filters above reflector are not allowed.
Praveen
Hi,
I have complied the code above, added the lower filter in the inf and got Code 41 (“Windows successfully loaded the device driver for this hardware but cannot find the hardware device”) at the end of the installation.
What could cause this?