Unable to unload driver in Win 7 - microsoft.public.development.device.drivers

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 don=92t use any WdfObjectReference call in my driver.

Joentke Kornse <joentke.kornse@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@probo.com Providenza & Boekelheide, Inc.

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=A0pm, Tim Roberts <t...@probo.com> wrote: > Joentke Kornse <joentke.kor...@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, =A0and 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? =A0Do you see the EvtDestroy call for= the > filter device before the EvtCleanup for the control device? =A0That would= be > a problem. =A0The control device must be gone before the filter device ge= ts > deleted, otherwise the system will never unload the driver. > > Does it matter if you remove the EvtDestroy callback on the control devic= e? > -- > Tim Roberts, t...@probo.com > Providenza & Boekelheide, Inc.

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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D 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...@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...@probo.com> wrote: > > > Joentke Kornse <joentke.kor...@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 ge= ts > > deleted, otherwise the system will never unload the driver. > > > Does it matter if you remove the EvtDestroy callback on the control dev= ice? > > -- > > Tim Roberts, t...@probo.com > > Providenza & Boekelheide, Inc. On Dec 7, 9:31=A0am, Joentke Kornse <joentke.kor...@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=A0pm, Tim Roberts <t...@probo.com> wrote: > > > Joentke Kornse <joentke.kor...@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, =A0and 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? =A0Do you see the EvtDestroy call f= or the > > filter device before the EvtCleanup for the control device? =A0That wou= ld be > > a problem. =A0The 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 dev= ice? > > -- > > Tim Roberts, t...@probo.com > > Providenza & Boekelheide, Inc.

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=A0pm, Joentke Kornse <joentke.kor...@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 =A0 <-- control device > Dumping WDFDEVICE 0x7b615940 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > WDM PDEVICE_OBJECTs: =A0self 849ea598 > > Control WDFDEVICE > > !object 849ea598 > Object: 849ea598 =A0Type: (848d6378) Device > =A0 =A0 ObjectHeader: 849ea580 (new version) > =A0 =A0 HandleCount: 0 =A0PointerCount: 2 > > !WDFHANDLE 0x7b615940 > > Dumping WDFHANDLE 0x7b615940 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > WDM PDEVICE_OBJECTs: =A0self 849ea598 > > Control WDFDEVICE > > !object 849ea598 > Object: 849ea598 =A0Type: (848d6378) Device > =A0 =A0 ObjectHeader: 849ea580 (new version) > =A0 =A0 HandleCount: 0 =A0PointerCount: 3 > > !WDFHANDLE 0x7b615940 > > Dumping WDFHANDLE 0x7b615940 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > WDM PDEVICE_OBJECTs: =A0self 849ea598 > > Control WDFDEVICE > > !object 849ea598 > Object: 849ea598 =A0Type: (848d6378) Device > =A0 =A0 ObjectHeader: 849ea580 (new version) > =A0 =A0 HandleCount: 0 =A0PointerCount: 3 > > !WDFHANDLE 0x7b615940 > > Dumping WDFHANDLE 0x7b615940 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > WDM PDEVICE_OBJECTs: =A0self 849ea598 > > Control WDFDEVICE > > !object 849ea598 > Object: 849ea598 =A0Type: (848d6378) Device > =A0 =A0 ObjectHeader: 849ea580 (new version) > =A0 =A0 HandleCount: 0 =A0PointerCount: 3 > > !WDFHANDLE 0x7b615940 > > Dumping WDFHANDLE 0x7b615940 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > WDM PDEVICE_OBJECTs: =A0self 849ea598 > > Control WDFDEVICE > > !object 849ea598 > Object: 849ea598 =A0Type: (848d6378) Device > =A0 =A0 ObjectHeader: 849ea580 (new version) > =A0 =A0 HandleCount: 0 =A0PointerCount: 2 > > !WDFHANDLE 0x7b615940 > > Dumping WDFHANDLE 0x7b615940 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > WDM PDEVICE_OBJECTs: =A0self 849ea598 > > Control WDFDEVICE > > !object 849ea598 > Object: 849ea598 =A0Type: (848d6378) Device > =A0 =A0 ObjectHeader: 849ea580 (new version) > =A0 =A0 HandleCount: 0 =A0PointerCount: 2 > > !WDFHANDLE 0x7b615940 > > Dumping WDFHANDLE 0x7b615940 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > 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...@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...@probo.com> wrote: > > > > Joentke Kornse <joentke.kor...@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 o= f > > > >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, =A0and 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? =A0Do you see the EvtDestroy call= for the > > > filter device before the EvtCleanup for the control device? =A0That w= ould be > > > a problem. =A0The control device must be gone before the filter devic= e gets > > > deleted, otherwise the system will never unload the driver. > > > > Does it matter if you remove the EvtDestroy callback on the control d= evice? > > > -- > > > Tim Roberts, t...@probo.com > > > Providenza & Boekelheide, Inc. > > On Dec 7, 9:31=A0am, Joentke Kornse <joentke.kor...@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=A0pm, Tim Roberts <t...@probo.com> wrote: > > > > Joentke Kornse <joentke.kor...@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 o= f > > > >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, =A0and 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? =A0Do you see the EvtDestroy call= for the > > > filter device before the EvtCleanup for the control device? =A0That w= ould be > > > a problem. =A0The control device must be gone before the filter devic= e gets > > > deleted, otherwise the system will never unload the driver. > > > > Does it matter if you remove the EvtDestroy callback on the control d= evice? > > > -- > > > Tim Roberts, t...@probo.com > > > Providenza & Boekelheide, Inc.

I don't think I would pin this on the cointstaller, rather I would look into the new version of KMDF behavior. destroy() not being called on the WDFDEVICE is due to the KMDF ref count > 0. KMDF makes sure the ref count on a legacy/control WDFDEVICE remains > 0 until the last handle to it is closed. I would look at your app and see if it still has an open handle to the control WDFDEVICE (!object <pdevobj> will give you the handle and Ob ref count) d -- This posting is provided "AS IS" with no warranties, and confers no rights. "Joentke Kornse" <joentke.kornse@gmail.com> wrote in message news:62b37eef-47b4-44db-9209-58fcedb7221f@r24g2000prf.googlegroups.com... > 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...@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...@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...@probo.com> wrote: >> >> > > Joentke Kornse <joentke.kor...@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...@probo.com >> > > Providenza & Boekelheide, Inc. >> >> On Dec 7, 9:31 am, Joentke Kornse <joentke.kor...@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...@probo.com> wrote: >> >> > > Joentke Kornse <joentke.kor...@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...@probo.com >> > > Providenza & Boekelheide, Inc. >

Hi Doron, I was using !object on the control device object and through out my debugging I get Handle Count =3D 0. Is this the count that you are referring to when you mention that app may have an open handle on my control device? Let me do more debugging on the reference count and give you an update again. Btw, I have also listed a trace of !WDFDEVICE, !WDFHANDLE, !WDFOBJECT and !object at different phases of the driver execution. You should be able find it in one of the earlier mails is this thread. Thanks, Doron. On Dec 8, 3:41=A0am, "Doron Holan [MSFT]" <doron.ho...@online.microsoft.com> wrote: > I don't think I would pin this on the cointstaller, rather I would look i= nto > the new version of KMDF behavior. =A0destroy() not being called on the > WDFDEVICE is due to the KMDF ref count > 0. =A0KMDF makes sure the ref co= unt > on a legacy/control WDFDEVICE remains > 0 until the last handle to it is > closed. =A0I would look at your app and see if it still has an open handl= e to > the control WDFDEVICE (!object <pdevobj> will give you the handle and Ob = ref > count) > > d > > -- > > This posting is provided "AS IS" with no warranties, and confers no right= s. > > "Joentke Kornse" <joentke.kor...@gmail.com> wrote in message > > news:62b37eef-47b4-44db-9209-58fcedb7221f@r24g2000prf.googlegroups.com... > > > 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...@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 =A0 <-- control device > >> Dumping WDFDEVICE 0x7b615940 > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >> WDM PDEVICE_OBJECTs: =A0self 849ea598 > > >> Control WDFDEVICE > > >> !object 849ea598 > >> Object: 849ea598 =A0Type: (848d6378) Device > >> =A0 =A0 ObjectHeader: 849ea580 (new version) > >> =A0 =A0 HandleCount: 0 =A0PointerCount: 2 > > >> !WDFHANDLE 0x7b615940 > > >> Dumping WDFHANDLE 0x7b615940 > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > >> 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 > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >> WDM PDEVICE_OBJECTs: =A0self 849ea598 > > >> Control WDFDEVICE > > >> !object 849ea598 > >> Object: 849ea598 =A0Type: (848d6378) Device > >> =A0 =A0 ObjectHeader: 849ea580 (new version) > >> =A0 =A0 HandleCount: 0 =A0PointerCount: 3 > > >> !WDFHANDLE 0x7b615940 > > >> Dumping WDFHANDLE 0x7b615940 > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > >> 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 > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >> WDM PDEVICE_OBJECTs: =A0self 849ea598 > > >> Control WDFDEVICE > > >> !object 849ea598 > >> Object: 849ea598 =A0Type: (848d6378) Device > >> =A0 =A0 ObjectHeader: 849ea580 (new version) > >> =A0 =A0 HandleCount: 0 =A0PointerCount: 3 > > >> !WDFHANDLE 0x7b615940 > > >> Dumping WDFHANDLE 0x7b615940 > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > >> 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 > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >> WDM PDEVICE_OBJECTs: =A0self 849ea598 > > >> Control WDFDEVICE > > >> !object 849ea598 > >> Object: 849ea598 =A0Type: (848d6378) Device > >> =A0 =A0 ObjectHeader: 849ea580 (new version) > >> =A0 =A0 HandleCount: 0 =A0PointerCount: 3 > > >> !WDFHANDLE 0x7b615940 > > >> Dumping WDFHANDLE 0x7b615940 > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > >> 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 > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >> WDM PDEVICE_OBJECTs: =A0self 849ea598 > > >> Control WDFDEVICE > > >> !object 849ea598 > >> Object: 849ea598 =A0Type: (848d6378) Device > >> =A0 =A0 ObjectHeader: 849ea580 (new version) > >> =A0 =A0 HandleCount: 0 =A0PointerCount: 2 > > >> !WDFHANDLE 0x7b615940 > > >> Dumping WDFHANDLE 0x7b615940 > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > >> 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 > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >> WDM PDEVICE_OBJECTs: =A0self 849ea598 > > >> Control WDFDEVICE > > >> !object 849ea598 > >> Object: 849ea598 =A0Type: (848d6378) Device > >> =A0 =A0 ObjectHeader: 849ea580 (new version) > >> =A0 =A0 HandleCount: 0 =A0PointerCount: 2 > > >> !WDFHANDLE 0x7b615940 > > >> Dumping WDFHANDLE 0x7b615940 > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > >> 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...@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...@probo.com> wrote: > > >> > > Joentke Kornse <joentke.kor...@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 instanc= e > >> > > >of > >> > > >the device driver is still in memory. (Code 38)" > > >> > > >I am hoping that the experts in this group could give me a few ti= ps > >> > > >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, =A0and it = is > >> > > >filtering a hid device. > >> > > >The kernel driver also creates a control device, exposed to the u= ser > >> > > >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 a= nd > >> > > >EvtDestroyCallback callbacks for control device, but in Win 7, my > >> > > >driver received only the EvtCleanupCallback callback. > > >> > > What is the order of the callbacks? =A0Do you see the EvtDestroy c= all > >> > > for the > >> > > filter device before the EvtCleanup for the control device? =A0Tha= t > >> > > would be > >> > > a problem. =A0The control device must be gone before the filter de= vice > >> > > gets > >> > > deleted, otherwise the system will never unload the driver. > > >> > > Does it matter if you remove the EvtDestroy callback on the contro= l > >> > > device? > >> > > -- > >> > > Tim Roberts, t...@probo.com > >> > > Providenza & Boekelheide, Inc. > > >> On Dec 7, 9:31 am, Joentke Kornse <joentke.kor...@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 > > ... > > read more =BB

>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? Both. --=20 Maxim S. Shatskih Windows DDK MVP maxim@storagecraft.com http://www.storagecraft.com

Thanks, guys. I have finally managed to fix this bug. Apparently the crux of the problem lies in the error of calling WdfObjectDelete within a spinlock. This would essentially violates the requirement of deleting control device at passive IRQL. Once I delete the control device out of the spinlock, my driver can unload. On Dec 8, 9:24=A0pm, "Maxim S. Shatskih" <ma...@storagecraft.com.no.spam> wrote: > >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? > > Both. > > -- > Maxim S. Shatskih > Windows DDK MVP > ma...@storagecraft.comhttp://www.storagecraft.com

Similiar Articles:

Server 2008 R2 - Unable to install any printer drivers - microsoft ...
Server 2008 R2 - Unable to install any printer drivers - Vista Forums The server has all available current updates. It is a DC for a small school network, and has the ...

Cannot find ODBC driver for MS Access 2007 database on Win 7 64-bi ...
But problem is I am unable to create a DSN using Windows\system32 ... Cannot find ODBC driver for MS Access 2007 database on Win 7 64-bi ... Cannot find ODBC driver for MS ...

printer driver install on Windows 7 x64 - microsoft.public ...
OneNote printer driver for Windows 7 64bit - microsoft.public ... server 2008 x64 - microsoft ... re: printer driver install on Windows 7 x64 - microsoft.public ... Unable ...

Adding Windows 7 64 bit Print Driver to Server 2003 32 bit ...
... 32 Bit driver; selected Have Disk; selected the new Win 7 64 bit driver ... Srv 2008 R2 - 32 bit printer drivers - struggling - microsoft ... Unable to add printers to ...

Print To OneNote Driver Windows 7 64x bit - microsoft.public ...
How do you get the Print to OneNote driver for Windows 7 Ultimate 64-bit? ... ... to-OneNote ..... installed OneNote 2010 RTM on my Windows 7 machine and am unable to ...

Unable to add printers to windows server 2008 x64 - microsoft ...
printer driver install on Windows 7 x64 - microsoft.public ... Unable to add printers to windows server 2008 x64 - microsoft ... printer driver install on Windows 7 x64 ...

re: printer driver install on Windows 7 x64 - microsoft.public ...
Server 2008 R2 - Unable to install any printer drivers - microsoft ... Srv 2008 R2 ... ... an install disk when I bought it. Windows ... C1600 drivers for Windows 7 64 ...

WinDbg: Unable to get verifier list - microsoft.public.windowsxp ...
... All pool allocations checked on unload ... microsoft.public.development.device.drivers - page 7 ... WinDbg: Unable to get verifier list Windows 7 I have been attempting to get ...

Scanner for Win 7 x64 - microsoft.public.windows.64bit.general ...
Is document imaging available in windows 7 version of office ... Unable to Initialize ... scanners with ... main problem there is that I don't have drivers for Windows ...

Virtual Game Controller driver - microsoft.public.development ...
... gotten the nonpnp part of my driver working (I'm able to load/unload the KMDF driver ... Download Microsoft Xbox 360™ Wireless Controller for Windows® driver and ... 360 ...

Unable to unload driver in Win 7 Windows 7
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.

Re: Unable to unload driver in Win 7 - Windows Vista Tips
I don't think I would pin this on the cointstaller, rather I would look into the new version of KMDF behavior. destroy() not being called on the

Unable to upload drivers w/Win 7 & nipp532 - Novell - NetIQ - SUSE
Be sure to unload NDPS environment and the ... Re: Unable to upload drivers w/Win 7 & nipp532 ... the newer Iprint Client (5.32) for Windows 7. Note ...

Load and unload device drivers
Determines which users can dynamically load and unload device drivers. This privilege is necessary for installing drivers for Plug and Play devices.

Non Administrator Permissions to Load and Unload Device Drivers
This article describes how to configure Windows 2000 to permit users who do not have administrator or power user permissions to install and uninstall ...

7/14/2012 8:58:57 PM