Q:
Hi, all. I have a question that is if a driver was loaded by calling ActivateDevice() in device manager, and then I want to unload it in my app by calling DeActivateDevice(), how to get the handle needed by DeActivateDevice()? Because DeActivateDevice() needs a handle as it's parameter, but it is device manager not me who loaded that driver, I do not know how to get that handle. Anyone can hlep me? Thanks very much! Lee
A1:
There is no documented and supported way to do that. If the device manager loaded the driver, then it is the device manager who should unload it. Why do you want to do this? Maybe you should leave it to your app to call ActivateDeviceEx() instead of having the device manager do it for your app. -- Bruce Eitman (eMVP) Senior Engineer beitman AT applieddata DOT net Applied Data Systems www.applieddata.net An ISO 9001:2000 Registered Company Microsoft WEP Gold-level Member
A2:
have a look at the FindFirstDevice and FindNextDevice. You should be able to enumerate the loaded device drivers and find the one you look after HTH -- ---------------------------------------------------------------- Anthony Pellerin ADENEO (ADESET) Windows Embedded Consultant <apellerin AT adeneo DOT adetelgroup DOT com> http://www.adeneo.adetelgroup.com Tél : +33 (0)4.72.18.57.77 Fax : +33 (0)4.72.18.57.78
A3:
As Bruce told you there is no documented and supported way to do that. PB help states "Only Device Manager should access the Active key for read or write access. You can indirectly access the Active key through a parameter to a device driver's initialization function" The Device Manager stores the handle returned by ActivateDevice under the HKEY_LOCAL_MACHINE/Drivers/Active/nn registry key corresponding to your driver; you can retrieve such a key calling OpenDeviceKey in your XXX_Init driver funcion. Anyway you should not do it...
A4:
Actually in V5.0 there IS a documented way to do that. However, it's still dangerous to do in MOST (but not all) situations. If you loaded the driver with an application that is no longer running then you can deactivate it safely. This is useful in debugging the driver that will otherwise be loaded from the "built-in" key. However, if the driver was loaded by a bus driver/enumerator then the bus driver needs to do the unload; otherwise there will, at best, be a memory leak in the bus driver as it maintains resources for all the drivers it loads. How about explaining a bit about WHY you think you need to do this? -- Steve Maillet EmbeddedFusion www.EmbeddedFusion.com smaillet at EmbeddedFusion dot com
A5:
"So I want to unload the usb function driver in my oempoweroff() and load it in my OemPowerOn() to solve this problem. Does this make sense?" Uhm, no. If you'd just said that from the beginning we'd have saved some time. You can't load/unload the drivers in the OEMPowerOff() handler (There's no such thing as OEMPowerOn() unless your BSP created one for some reason.) You can have a driver that receives the power manager notifications and unloads and reloads the USB function driver on resume - but honestly that's a hack - fix your function driver to work correctly and the whole issue is moot. -- Steve Maillet EmbeddedFusion www.EmbeddedFusion.com smaillet at EmbeddedFusion dot com
A6:
Because the OS is effectively shut down by the time it gets there. The scheduler is already stopped and the only thing you can do there is return or turn off power and suspend the hardware. You cannot call ANY of the WIN32 APIs in that context. -- Steve Maillet EmbeddedFusion www.EmbeddedFusion.com smaillet at EmbeddedFusion dot com