Unable to unload driver in Win 7
in [Device Drivers]
|
From: Joentke Kornse on 5 Dec 2009 06:22 Hi All, I am getting this error in Win 7 but not in Vista and and not in XP: "Windows cannot load the device driver because a previous instance of the device driver is still in memory. (Code 38)" I am hoping that the experts in this group could give me a few tips on: Is there any obvious flaw that is noticeable from my description? Is there any special handling that needs to be done for Win 7? How to reproduce it: When my USB device is plugged into the system, my kernel driver is loaded correctly, but when the device is removed and the re-plugged back into the system, then my kernel driver is not reloaded. Device manager shows a yellow exclamation mark, with an error message saying the previous instance of the driver was not unloaded. This is observed only on Win 7, both 32-bit and 64-bit, but not on XP and not on Vista. The nature of the driver: The kernel driver is a KMDF-based upper filter driver, and it is filtering a hid device. The kernel driver also creates a control device, exposed to the user space supporting modules through a symbolic link. The filter device registers for EvtCleanupCallback and will WdfObjectDelete control device when this callback function is called. Outcome of my investigation so far: During this investigation, I have additionally registered for EvtCleanupCallback and EvtDestroyCallback for the filter device and the control device. When the device is unplugged, my driver received the EvtCleanupCallback and EvtDestroyCallback for the filter device. In the EvtCleanupCallback of the filter device, my driver will WdfObjectDelete the control device. In XP and Vista, my driver received both the EvtCleanupCallback and EvtDestroyCallback callbacks for control device, but in Win 7, my driver received only the EvtCleanupCallback callback. Do keep in mind that this investigation is done while ensuring that the user space components are not running, to remove issues that may arise from having an open handle on the control device. And I have also made sure that I dont use any WdfObjectReference call in my driver.
From: Tim Roberts on 6 Dec 2009 01:36 Joentke Kornse <joentke.kornse(a)gmail.com> wrote: >Hi All, > >I am getting this error in Win 7 but not in Vista and and not in XP: >"Windows cannot load the device driver because a previous instance of >the device driver is still in memory. (Code 38)" > >I am hoping that the experts in this group could give me a few tips >on: >Is there any obvious flaw that is noticeable from my description? >Is there any special handling that needs to be done for Win 7? >... >The nature of the driver: >The kernel driver is a KMDF-based upper filter driver, and it is >filtering a hid device. >The kernel driver also creates a control device, exposed to the user >space supporting modules through a symbolic link. >The filter device registers for EvtCleanupCallback and will >WdfObjectDelete control device when this callback function is called. >... >In XP and Vista, my driver received both the EvtCleanupCallback and >EvtDestroyCallback callbacks for control device, but in Win 7, my >driver received only the EvtCleanupCallback callback. What is the order of the callbacks? Do you see the EvtDestroy call for the filter device before the EvtCleanup for the control device? That would be a problem. The control device must be gone before the filter device gets deleted, otherwise the system will never unload the driver. Does it matter if you remove the EvtDestroy callback on the control device? -- Tim Roberts, timr(a)probo.com Providenza & Boekelheide, Inc.
From: Joentke Kornse on 6 Dec 2009 20:31 The callbacks comes as follows: (Win7) - EvtCleanupCallback for filter device - EvtCleanupCallback for control device - EvtDestroyCallback for filter device For XP, this is the sequence of callbacks - EvtCleanupCallback for filter device - EvtCleanupCallback for control device - EvtDestroyCallback for control device - EvtDestroyCallback for filter device I have registered for EvtDestroyCallback only for debugging purposes, applicable to both the filter and control device. I don't really need to listen to this callback. But by registering for the EvtDestroyCallback, I now know that the control device is not destroyed in Win 7. Tim, thanks for helping. Any further tip on how I can investigate deeper? On Dec 6, 2:36 pm, Tim Roberts <t...(a)probo.com> wrote: > Joentke Kornse <joentke.kor...(a)gmail.com> wrote: > >Hi All, > > >I am getting this error in Win 7 but not in Vista and and not in XP: > >"Windows cannot load the device driver because a previous instance of > >the device driver is still in memory. (Code 38)" > > >I am hoping that the experts in this group could give me a few tips > >on: > >Is there any obvious flaw that is noticeable from my description? > >Is there any special handling that needs to be done for Win 7? > >... > >The nature of the driver: > >The kernel driver is a KMDF-based upper filter driver, and it is > >filtering a hid device. > >The kernel driver also creates a control device, exposed to the user > >space supporting modules through a symbolic link. > >The filter device registers for EvtCleanupCallback and will > >WdfObjectDelete control device when this callback function is called. > >... > >In XP and Vista, my driver received both the EvtCleanupCallback and > >EvtDestroyCallback callbacks for control device, but in Win 7, my > >driver received only the EvtCleanupCallback callback. > > What is the order of the callbacks? Do you see the EvtDestroy call for the > filter device before the EvtCleanup for the control device? That would be > a problem. The control device must be gone before the filter device gets > deleted, otherwise the system will never unload the driver. > > Does it matter if you remove the EvtDestroy callback on the control device? > -- > Tim Roberts, t...(a)probo.com > Providenza & Boekelheide, Inc.
From: Joentke Kornse on 7 Dec 2009 03:17 I found a few more interesting info regarding the reference counts on my control device: (On Win7) Based on trace I have, there are actually 2 reference counts: - The RefCount returned by !WDFHANDLE - The PointerCount returned by !object Which one should I be more concerned about? And one more observation: WdfControlFinishInitializing seems to increment the PointerCount but not the RefCount. Is that expected? ****************************************************************************************************************** Just after creation: !WDFDEVICE 0x7b615940 <-- control device Dumping WDFDEVICE 0x7b615940 ================================= WDM PDEVICE_OBJECTs: self 849ea598 Control WDFDEVICE !object 849ea598 Object: 849ea598 Type: (848d6378) Device ObjectHeader: 849ea580 (new version) HandleCount: 0 PointerCount: 2 !WDFHANDLE 0x7b615940 Dumping WDFHANDLE 0x7b615940 ============================= Handle type is WDFDEVICE Refcount: 1 !wdfobject 0x849ea6b8 The type for object 0x849ea6b8 is FxDevice State: FxObjectStateCreated (0x1) ****************************************************************************************************************** After calling WdfControlFinishInitializing: !WDFDEVICE 0x7b615940 Dumping WDFDEVICE 0x7b615940 ================================= WDM PDEVICE_OBJECTs: self 849ea598 Control WDFDEVICE !object 849ea598 Object: 849ea598 Type: (848d6378) Device ObjectHeader: 849ea580 (new version) HandleCount: 0 PointerCount: 3 !WDFHANDLE 0x7b615940 Dumping WDFHANDLE 0x7b615940 ============================= Handle type is WDFDEVICE Refcount: 1 !wdfobject 0x849ea6b8 The type for object 0x849ea6b8 is FxDevice State: FxObjectStateCreated (0x1) ****************************************************************************************************************** During normal operation !WDFDEVICE 0x7b615940 Dumping WDFDEVICE 0x7b615940 ================================= WDM PDEVICE_OBJECTs: self 849ea598 Control WDFDEVICE !object 849ea598 Object: 849ea598 Type: (848d6378) Device ObjectHeader: 849ea580 (new version) HandleCount: 0 PointerCount: 3 !WDFHANDLE 0x7b615940 Dumping WDFHANDLE 0x7b615940 ============================= Handle type is WDFDEVICE Refcount: 1 !wdfobject 0x849ea6b8 The type for object 0x849ea6b8 is FxDevice State: FxObjectStateCreated (0x1) ****************************************************************************************************************** After unplugging the physical device, in the EvtCleanupCallback for filter device, before WdfObjectDelete the control device !WDFDEVICE 0x7b615940 Dumping WDFDEVICE 0x7b615940 ================================= WDM PDEVICE_OBJECTs: self 849ea598 Control WDFDEVICE !object 849ea598 Object: 849ea598 Type: (848d6378) Device ObjectHeader: 849ea580 (new version) HandleCount: 0 PointerCount: 3 !WDFHANDLE 0x7b615940 Dumping WDFHANDLE 0x7b615940 ============================= Handle type is WDFDEVICE Refcount: 1 Contexts: !wdfobject 0x849ea6b8 The type for object 0x849ea6b8 is FxDevice State: FxObjectStateCreated (0x1) ****************************************************************************************************************** After unplugging the physical device, in the EvtCleanupCallback for filter device, after WdfObjectDelete the control device !WDFDEVICE 0x7b615940 Dumping WDFDEVICE 0x7b615940 ================================= WDM PDEVICE_OBJECTs: self 849ea598 Control WDFDEVICE !object 849ea598 Object: 849ea598 Type: (848d6378) Device ObjectHeader: 849ea580 (new version) HandleCount: 0 PointerCount: 2 !WDFHANDLE 0x7b615940 Dumping WDFHANDLE 0x7b615940 ============================= Handle type is WDFDEVICE Refcount: 1 !wdfobject 0x849ea6b8 The type for object 0x849ea6b8 is FxDevice State: FxObjectStateDeferedDeleting (0x6) ****************************************************************************************************************** After unplugging the physical device, in the EvtCleanupCallback for control device !WDFDEVICE 0x7b615940 Dumping WDFDEVICE 0x7b615940 ================================= WDM PDEVICE_OBJECTs: self 849ea598 Control WDFDEVICE !object 849ea598 Object: 849ea598 Type: (848d6378) Device ObjectHeader: 849ea580 (new version) HandleCount: 0 PointerCount: 2 !WDFHANDLE 0x7b615940 Dumping WDFHANDLE 0x7b615940 ============================= Handle type is WDFDEVICE Refcount: 1 !wdfobject 0x849ea6b8 The type for object 0x849ea6b8 is FxDevice State: FxObjectStateDeletedDisposing (0x9) ****************************************************************************************************************** On Dec 7, 9:31 am, Joentke Kornse <joentke.kor...(a)gmail.com> wrote: > The callbacks comes as follows: (Win7) > - EvtCleanupCallback for filter device > - EvtCleanupCallback for control device > - EvtDestroyCallback for filter device > > For XP, this is the sequence of callbacks > - EvtCleanupCallback for filter device > - EvtCleanupCallback for control device > - EvtDestroyCallback for control device > - EvtDestroyCallback for filter device > > I have registered for EvtDestroyCallback only for debugging purposes, > applicable to both the filter and control device. > I don't really need to listen to this callback. > > But by registering for the EvtDestroyCallback, I now know that the > control device is not destroyed in Win 7. > > Tim, thanks for helping. > Any further tip on how I can investigate deeper? > > On Dec 6, 2:36 pm, Tim Roberts <t...(a)probo.com> wrote: > > > Joentke Kornse <joentke.kor...(a)gmail.com> wrote: > > >Hi All, > > > >I am getting this error in Win 7 but not in Vista and and not in XP: > > >"Windows cannot load the device driver because a previous instance of > > >the device driver is still in memory. (Code 38)" > > > >I am hoping that the experts in this group could give me a few tips > > >on: > > >Is there any obvious flaw that is noticeable from my description? > > >Is there any special handling that needs to be done for Win 7? > > >... > > >The nature of the driver: > > >The kernel driver is a KMDF-based upper filter driver, and it is > > >filtering a hid device. > > >The kernel driver also creates a control device, exposed to the user > > >space supporting modules through a symbolic link. > > >The filter device registers for EvtCleanupCallback and will > > >WdfObjectDelete control device when this callback function is called. > > >... > > >In XP and Vista, my driver received both the EvtCleanupCallback and > > >EvtDestroyCallback callbacks for control device, but in Win 7, my > > >driver received only the EvtCleanupCallback callback. > > > What is the order of the callbacks? Do you see the EvtDestroy call for the > > filter device before the EvtCleanup for the control device? That would be > > a problem. The control device must be gone before the filter device gets > > deleted, otherwise the system will never unload the driver. > > > Does it matter if you remove the EvtDestroy callback on the control device? > > -- > > Tim Roberts, t...(a)probo.com > > Providenza & Boekelheide, Inc. On Dec 7, 9:31 am, Joentke Kornse <joentke.kor...(a)gmail.com> wrote: > The callbacks comes as follows: (Win7) > - EvtCleanupCallback for filter device > - EvtCleanupCallback for control device > - EvtDestroyCallback for filter device > > For XP, this is the sequence of callbacks > - EvtCleanupCallback for filter device > - EvtCleanupCallback for control device > - EvtDestroyCallback for control device > - EvtDestroyCallback for filter device > > I have registered for EvtDestroyCallback only for debugging purposes, > applicable to both the filter and control device. > I don't really need to listen to this callback. > > But by registering for the EvtDestroyCallback, I now know that the > control device is not destroyed in Win 7. > > Tim, thanks for helping. > Any further tip on how I can investigate deeper? > > On Dec 6, 2:36 pm, Tim Roberts <t...(a)probo.com> wrote: > > > Joentke Kornse <joentke.kor...(a)gmail.com> wrote: > > >Hi All, > > > >I am getting this error in Win 7 but not in Vista and and not in XP: > > >"Windows cannot load the device driver because a previous instance of > > >the device driver is still in memory. (Code 38)" > > > >I am hoping that the experts in this group could give me a few tips > > >on: > > >Is there any obvious flaw that is noticeable from my description? > > >Is there any special handling that needs to be done for Win 7? > > >... > > >The nature of the driver: > > >The kernel driver is a KMDF-based upper filter driver, and it is > > >filtering a hid device. > > >The kernel driver also creates a control device, exposed to the user > > >space supporting modules through a symbolic link. > > >The filter device registers for EvtCleanupCallback and will > > >WdfObjectDelete control device when this callback function is called. > > >... > > >In XP and Vista, my driver received both the EvtCleanupCallback and > > >EvtDestroyCallback callbacks for control device, but in Win 7, my > > >driver received only the EvtCleanupCallback callback. > > > What is the order of the callbacks? Do you see the EvtDestroy call for the > > filter device before the EvtCleanup for the control device? That would be > > a problem. The control device must be gone before the filter device gets > > deleted, otherwise the system will never unload the driver. > > > Does it matter if you remove the EvtDestroy callback on the control device? > > -- > > Tim Roberts, t...(a)probo.com > > Providenza & Boekelheide, Inc.
From: Joentke Kornse on 7 Dec 2009 03:52 I am now suspecting that this issue is related to the WDF Coinstaller version. I can reproduce this bug on XP if I use the WDF Coinstaller v1.9. I normally build the binaries using WDK 6001.18001 and I bundle it with the v1.7 of the coinstaller. But in this particular test, I tried building using the WDK 7600.16385.0 and I bundle it with v1.9 coinstaller. Once I put in this package into an XP system, I can reproduce the same issue in XP. I am very tempted to simply claim that this is a Coinstaller problem, but I would rather not approach the problem with that view point for now. I am still suspecting that I am not handling the control device correctly and I am hoping that the experts in this forum can give me some pointers. On Dec 7, 4:17 pm, Joentke Kornse <joentke.kor...(a)gmail.com> wrote: > I found a few more interesting info regarding the reference counts on > my control device: (On Win7) > > Based on trace I have, there are actually 2 reference counts: > - The RefCount returned by !WDFHANDLE > - The PointerCount returned by !object > > Which one should I be more concerned about? > > And one more observation: > WdfControlFinishInitializing seems to increment the PointerCount but > not the RefCount. > Is that expected? > > ****************************************************************************************************************** > Just after creation: > > !WDFDEVICE 0x7b615940 <-- control device > Dumping WDFDEVICE 0x7b615940 > ================================= > > WDM PDEVICE_OBJECTs: self 849ea598 > > Control WDFDEVICE > > !object 849ea598 > Object: 849ea598 Type: (848d6378) Device > ObjectHeader: 849ea580 (new version) > HandleCount: 0 PointerCount: 2 > > !WDFHANDLE 0x7b615940 > > Dumping WDFHANDLE 0x7b615940 > ============================= > Handle type is WDFDEVICE > Refcount: 1 > > !wdfobject 0x849ea6b8 > The type for object 0x849ea6b8 is FxDevice > State: FxObjectStateCreated (0x1) > > ****************************************************************************************************************** > After calling WdfControlFinishInitializing: > > !WDFDEVICE 0x7b615940 > Dumping WDFDEVICE 0x7b615940 > ================================= > > WDM PDEVICE_OBJECTs: self 849ea598 > > Control WDFDEVICE > > !object 849ea598 > Object: 849ea598 Type: (848d6378) Device > ObjectHeader: 849ea580 (new version) > HandleCount: 0 PointerCount: 3 > > !WDFHANDLE 0x7b615940 > > Dumping WDFHANDLE 0x7b615940 > ============================= > Handle type is WDFDEVICE > Refcount: 1 > > !wdfobject 0x849ea6b8 > > The type for object 0x849ea6b8 is FxDevice > State: FxObjectStateCreated (0x1) > > ****************************************************************************************************************** > During normal operation > > !WDFDEVICE 0x7b615940 > > Dumping WDFDEVICE 0x7b615940 > ================================= > > WDM PDEVICE_OBJECTs: self 849ea598 > > Control WDFDEVICE > > !object 849ea598 > Object: 849ea598 Type: (848d6378) Device > ObjectHeader: 849ea580 (new version) > HandleCount: 0 PointerCount: 3 > > !WDFHANDLE 0x7b615940 > > Dumping WDFHANDLE 0x7b615940 > ============================= > Handle type is WDFDEVICE > Refcount: 1 > > !wdfobject 0x849ea6b8 > > The type for object 0x849ea6b8 is FxDevice > State: FxObjectStateCreated (0x1) > > ****************************************************************************************************************** > After unplugging the physical device, in the EvtCleanupCallback for > filter device, before WdfObjectDelete the control device > > !WDFDEVICE 0x7b615940 > > Dumping WDFDEVICE 0x7b615940 > ================================= > > WDM PDEVICE_OBJECTs: self 849ea598 > > Control WDFDEVICE > > !object 849ea598 > Object: 849ea598 Type: (848d6378) Device > ObjectHeader: 849ea580 (new version) > HandleCount: 0 PointerCount: 3 > > !WDFHANDLE 0x7b615940 > > Dumping WDFHANDLE 0x7b615940 > ============================= > Handle type is WDFDEVICE > Refcount: 1 > Contexts: > > !wdfobject 0x849ea6b8 > > The type for object 0x849ea6b8 is FxDevice > State: FxObjectStateCreated (0x1) > ****************************************************************************************************************** > After unplugging the physical device, in the EvtCleanupCallback for > filter device, after WdfObjectDelete the control device > > !WDFDEVICE 0x7b615940 > > Dumping WDFDEVICE 0x7b615940 > ================================= > > WDM PDEVICE_OBJECTs: self 849ea598 > > Control WDFDEVICE > > !object 849ea598 > Object: 849ea598 Type: (848d6378) Device > ObjectHeader: 849ea580 (new version) > HandleCount: 0 PointerCount: 2 > > !WDFHANDLE 0x7b615940 > > Dumping WDFHANDLE 0x7b615940 > ============================= > Handle type is WDFDEVICE > Refcount: 1 > > !wdfobject 0x849ea6b8 > > The type for object 0x849ea6b8 is FxDevice > State: FxObjectStateDeferedDeleting (0x6) > > ****************************************************************************************************************** > After unplugging the physical device, in the EvtCleanupCallback for > control device > > !WDFDEVICE 0x7b615940 > > Dumping WDFDEVICE 0x7b615940 > ================================= > > WDM PDEVICE_OBJECTs: self 849ea598 > > Control WDFDEVICE > > !object 849ea598 > Object: 849ea598 Type: (848d6378) Device > ObjectHeader: 849ea580 (new version) > HandleCount: 0 PointerCount: 2 > > !WDFHANDLE 0x7b615940 > > Dumping WDFHANDLE 0x7b615940 > ============================= > Handle type is WDFDEVICE > Refcount: 1 > > !wdfobject 0x849ea6b8 > > The type for object 0x849ea6b8 is FxDevice > State: FxObjectStateDeletedDisposing (0x9) > > ****************************************************************************************************************** > > On Dec 7, 9:31 am, Joentke Kornse <joentke.kor...(a)gmail.com> wrote: > > > > > The callbacks comes as follows: (Win7) > > - EvtCleanupCallback for filter device > > - EvtCleanupCallback for control device > > - EvtDestroyCallback for filter device > > > For XP, this is the sequence of callbacks > > - EvtCleanupCallback for filter device > > - EvtCleanupCallback for control device > > - EvtDestroyCallback for control device > > - EvtDestroyCallback for filter device > > > I have registered for EvtDestroyCallback only for debugging purposes, > > applicable to both the filter and control device. > > I don't really need to listen to this callback. > > > But by registering for the EvtDestroyCallback, I now know that the > > control device is not destroyed in Win 7. > > > Tim, thanks for helping. > > Any further tip on how I can investigate deeper? > > > On Dec 6, 2:36 pm, Tim Roberts <t...(a)probo.com> wrote: > > > > Joentke Kornse <joentke.kor...(a)gmail.com> wrote: > > > >Hi All, > > > > >I am getting this error in Win 7 but not in Vista and and not in XP: > > > >"Windows cannot load the device driver because a previous instance of > > > >the device driver is still in memory. (Code 38)" > > > > >I am hoping that the experts in this group could give me a few tips > > > >on: > > > >Is there any obvious flaw that is noticeable from my description? > > > >Is there any special handling that needs to be done for Win 7? > > > >... > > > >The nature of the driver: > > > >The kernel driver is a KMDF-based upper filter driver, and it is > > > >filtering a hid device. > > > >The kernel driver also creates a control device, exposed to the user > > > >space supporting modules through a symbolic link. > > > >The filter device registers for EvtCleanupCallback and will > > > >WdfObjectDelete control device when this callback function is called.. > > > >... > > > >In XP and Vista, my driver received both the EvtCleanupCallback and > > > >EvtDestroyCallback callbacks for control device, but in Win 7, my > > > >driver received only the EvtCleanupCallback callback. > > > > What is the order of the callbacks? Do you see the EvtDestroy call for the > > > filter device before the EvtCleanup for the control device? That would be > > > a problem. The control device must be gone before the filter device gets > > > deleted, otherwise the system will never unload the driver. > > > > Does it matter if you remove the EvtDestroy callback on the control device? > > > -- > > > Tim Roberts, t...(a)probo.com > > > Providenza & Boekelheide, Inc. > > On Dec 7, 9:31 am, Joentke Kornse <joentke.kor...(a)gmail.com> wrote: > > > The callbacks comes as follows: (Win7) > > - EvtCleanupCallback for filter device > > - EvtCleanupCallback for control device > > - EvtDestroyCallback for filter device > > > For XP, this is the sequence of callbacks > > - EvtCleanupCallback for filter device > > - EvtCleanupCallback for control device > > - EvtDestroyCallback for control device > > - EvtDestroyCallback for filter device > > > I have registered for EvtDestroyCallback only for debugging purposes, > > applicable to both the filter and control device. > > I don't really need to listen to this callback. > > > But by registering for the EvtDestroyCallback, I now know that the > > control device is not destroyed in Win 7. > > > Tim, thanks for helping. > > Any further tip on how I can investigate deeper? > > > On Dec 6, 2:36 pm, Tim Roberts <t...(a)probo.com> wrote: > > > > Joentke Kornse <joentke.kor...(a)gmail.com> wrote: > > > >Hi All, > > > > >I am getting this error in Win 7 but not in Vista and and not in XP: > > > >"Windows cannot load the device driver because a previous instance of > > > >the device driver is still in memory. (Code 38)" > > > > >I am hoping that the experts in this group could give me a few tips > > > >on: > > > >Is there any obvious flaw that is noticeable from my description? > > > >Is there any special handling that needs to be done for Win 7? > > > >... > > > >The nature of the driver: > > > >The kernel driver is a KMDF-based upper filter driver, and it is > > > >filtering a hid device. > > > >The kernel driver also creates a control device, exposed to the user > > > >space supporting modules through a symbolic link. > > > >The filter device registers for EvtCleanupCallback and will > > > >WdfObjectDelete control device when this callback function is called.. > > > >... > > > >In XP and Vista, my driver received both the EvtCleanupCallback and > > > >EvtDestroyCallback callbacks for control device, but in Win 7, my > > > >driver received only the EvtCleanupCallback callback. > > > > What is the order of the callbacks? Do you see the EvtDestroy call for the > > > filter device before the EvtCleanup for the control device? That would be > > > a problem. The control device must be gone before the filter device gets > > > deleted, otherwise the system will never unload the driver. > > > > Does it matter if you remove the EvtDestroy callback on the control device? > > > -- > > > Tim Roberts, t...(a)probo.com > > > Providenza & Boekelheide, Inc.
|
Next
|
Last
Pages: 1 2 Prev: Capturing Raw Native 802.11 packets in Vista using ndislwf Next: virtual bus enumeration |