Re: Unable to unload driver in Win 7

Joentke Kornse <> 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,
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" <> wrote in message
news:62b37eef-47b4-44db-9209-...
> 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.
>

>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

http://www.storagecraft.com