Unable to unload driver in Win 7
in [Device Drivers]
|
From: Doron Holan [MSFT] on 7 Dec 2009 14:41 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(a)gmail.com> wrote in message news:62b37eef-47b4-44db-9209-58fcedb7221f(a)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...(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. >
From: Joentke Kornse on 7 Dec 2009 20:12 Hi Doron, I was using !object on the control device object and through out my debugging I get Handle Count = 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 am, "Doron Holan [MSFT]" <doron.ho...(a)online.microsoft.com> wrote: > 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.kor...(a)gmail.com> wrote in message > > news:62b37eef-47b4-44db-9209-58fcedb7221f(a)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...(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 > > ... > > read more »
From: Maxim S. Shatskih on 8 Dec 2009 08:24 >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 maxim(a)storagecraft.com http://www.storagecraft.com
From: Joentke Kornse on 8 Dec 2009 10:31 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 pm, "Maxim S. Shatskih" <ma...(a)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...(a)storagecraft.comhttp://www.storagecraft.com
First
|
Prev
|
Pages: 1 2 Prev: Capturing Raw Native 802.11 packets in Vista using ndislwf Next: virtual bus enumeration |