Device callback object isn't referenced by the framework
in [Device Drivers]
|
Prev: size of private devmode members struct unable to change in my postscript driver
Next: How simulate the OSR USB FX2 Kit ?
From: Figueredo on 16 May 2008 09:31 Hi, I've been studying about developing a driver using WDF (UMDF in my case) for a while using "Developing Drivers with the Windows Driver Foundation" and the examples that comes with the DDK. In those examples (e.g. fx2_driver and echo), I've noticed that after an object creation a call to Release() is made on it, so that the framework, who has taken a reference to this object, will be responsible for it's deletion, am I right? My problem is that I found a situation where this doesn't happen. My device callback object doesn't implement any of the interfaces (except IUnknown), because I want the framework to manage pnp events, so by the time of creation, I noticed that the fx won't take a reference to my device object as it does when I implement an interface, such as IPnpCallbackHardware. Here is where it happens: // CMyDevice::Initialize IUnknown *unknown = this->QueryIUnknown(); // When my device obj doesn't implement any interfaces except IUnknown // the fx won't take a reference to it hr = FxDriver->CreateDevice(FxDeviceInit, unknown, &fxDevice); unknown->Release(); // ... So if I call Release() after the initilization and configuration of my device callback object, it will delete itself ! But my queues take a reference to this object (a weak reference as it is named on the example) and my driver crashes when they try to reference my device callback object (obviously). Here is where it calls Release() // CMyDriver::OnDeviceAdd // ... if (SUCCEEDED(hr)) { hr = device->Configure(); } if (NULL != device) { device->Release(); } // ... I've solved this by implementing IPnpCallback with dummy methods (they just return S_OK), but I'd like to know how can I do it the best way: - should I avoid weak references in my queues? But then they would be responsible for the deletion of my device callback object, wouldn't they? - should I do as I did implementing IPnpCallback? - or should I be aware that my object doesn't implement an interface that the fx requires and don't call Release() after it's creation? Thanks in advance Thiago Figueredo
From: Egidio [MSFT] on 16 May 2008 13:20 At this time the best way to fix this is by implementing the IObjectCleanup::OnCleanup callback that does nothing. The new UMDF version 1.9 will fix this problem. Egi. "Figueredo" <Figueredo(a)discussions.microsoft.com> wrote in message news:AE756413-8FFA-403B-95B6-D4A6DA1B366C(a)microsoft.com... > Hi, > > I've been studying about developing a driver using WDF (UMDF in my case) > for > a while using "Developing Drivers with the Windows Driver Foundation" and > the > examples that comes with the DDK. > > In those examples (e.g. fx2_driver and echo), I've noticed that after an > object creation a call to Release() is made on it, so that the framework, > who > has taken a reference to this object, will be responsible for it's > deletion, > am I right? > > My problem is that I found a situation where this doesn't happen. My > device > callback object doesn't implement any of the interfaces (except IUnknown), > because I want the framework to manage pnp events, so by the time of > creation, I noticed that the fx won't take a reference to my device object > as > it does when I implement an interface, such as IPnpCallbackHardware. > > Here is where it happens: > // CMyDevice::Initialize > IUnknown *unknown = this->QueryIUnknown(); > > // When my device obj doesn't implement any interfaces except > IUnknown > // the fx won't take a reference to it > hr = FxDriver->CreateDevice(FxDeviceInit, unknown, &fxDevice); > > unknown->Release(); > // ... > > So if I call Release() after the initilization and configuration of my > device callback object, it will delete itself ! But my queues take a > reference to this object (a weak reference as it is named on the example) > and > my driver crashes when they try to reference my device callback object > (obviously). > > Here is where it calls Release() > // CMyDriver::OnDeviceAdd > // ... > if (SUCCEEDED(hr)) > { > hr = device->Configure(); > } > if (NULL != device) > { > device->Release(); > } > // ... > > I've solved this by implementing IPnpCallback with dummy methods (they > just > return S_OK), but I'd like to know how can I do it the best way: > - should I avoid weak references in my queues? But then they would be > responsible for the deletion of my device callback object, wouldn't they? > - should I do as I did implementing IPnpCallback? > - or should I be aware that my object doesn't implement an interface that > the fx requires and don't call Release() after it's creation? > > Thanks in advance > > Thiago Figueredo
From: Maxim S. Shatskih on 17 May 2008 04:53 > // the fx won't take a reference to it > hr = FxDriver->CreateDevice(FxDeviceInit, unknown, &fxDevice); ....and will return FAILED hr. Here, if hr SUCCEEDED, then FxDriver now holds a reference to "unknown". -- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation maxim(a)storagecraft.com http://www.storagecraft.com
From: Figueredo on 20 May 2008 09:17 Thanks, Egidio, it worked just fine and seems to me a better solution. "Egidio [MSFT]" wrote: > At this time the best way to fix this is by implementing the > IObjectCleanup::OnCleanup callback that does nothing. > The new UMDF version 1.9 will fix this problem. > > Egi.
From: Figueredo on 20 May 2008 09:25
Well, if the fx should fail when no reference is taken, the version I'm using has a bug (this must be the bug that Egidio mentioned). After this call, hr SUCCEEDED and the reference counter for my device callback object isn't incremented. :/ Thiago Figueredo "Maxim S. Shatskih" wrote: > > // the fx won't take a reference to it > > hr = FxDriver->CreateDevice(FxDeviceInit, unknown, &fxDevice); > > ....and will return FAILED hr. > > Here, if hr SUCCEEDED, then FxDriver now holds a reference to "unknown". > > -- > Maxim Shatskih, Windows DDK MVP > StorageCraft Corporation > maxim(a)storagecraft.com > http://www.storagecraft.com > |