Two (or more) EvtCleanupCallback functions registered for one WDFOBJECT?

Hi,

I have just noticed that !wdfhandle shows ‘callbacks>’ even for second and subsequent contexts that are
registered for an object. That led me to thinking that it might be
possible to register more EvtCleanupCallback (or in fact
EvtDestroyCallback) callbacks. Since I couldn’t find a function which
would do that explicitly (unless I missed something in the docs) I
decided to call WdfObjectAllocateContext with
wdfObjAttr.EvtCleanupCallback set.

Lo and behold, it worked. Well, at least as far as WinDbg is concerned:

Dumping WDFHANDLE 0x78581d58
=============================
Handle type is WDFOBJECT
Refcount: 1
Contexts:
context: dt 0x87a7e2f0 FIRST_CONTEXT (size is 0x48 bytes)
EvtCleanupCallback 93515b90 driver!EvtCleanupCallback
EvtDestroyCallback 93515cc0 driver!EvtDestroyCallback

context: dt 0x89f45e40 SECOND_CONTEXT (size is 0x8 bytes)
EvtCleanupCallback 93510460 driver!SecondEvtCleanupCallback

Parent: !wdfhandle 0x725f89b8, type is WDFOBJECT

Unfortunately, the driver itself wasn’t so happy with the change. In
particular, I was getting the SecondEvtCleanupCallback callback called
at strange times (e.g. when a driver of a child device was querying
for an interface):

kd> k
# ChildEBP RetAddr
00 88cff248 847c62dc driver!SecondEvtCleanupCallback+0x5
01 88cff28c 847c9d06 Wdf01000!FxPkgPnp::HandleQueryInterface+0x1b5
02 88cff2a0 847c5e02 Wdf01000!FxPkgPdo::_PnpQueryInterface+0x15


That brings up a question. Is what I did acceptable and officially
supported? Or was it a hack with which I managed to corrupt memory?

Thanks,
Rafal

It is acceptable, it is not a hack. I am guessing that SecondEvtCleanupCallback is an empty function and the function you registered for the QI callback is also empty, so the compiler folded both definitions into one function body. Why do you think you need a 2nd cleanup callback?

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Rafal Zwierz
Sent: Monday, March 21, 2011 12:28 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Two (or more) EvtCleanupCallback functions registered for one WDFOBJECT?

Hi,

I have just noticed that !wdfhandle shows ‘callbacks>’ even for second and subsequent contexts that are
registered for an object. That led me to thinking that it might be possible to register more EvtCleanupCallback (or in fact
EvtDestroyCallback) callbacks. Since I couldn’t find a function which would do that explicitly (unless I missed something in the docs) I decided to call WdfObjectAllocateContext with wdfObjAttr.EvtCleanupCallback set.

Lo and behold, it worked. Well, at least as far as WinDbg is concerned:

Dumping WDFHANDLE 0x78581d58
=============================
Handle type is WDFOBJECT
Refcount: 1
Contexts:
context: dt 0x87a7e2f0 FIRST_CONTEXT (size is 0x48 bytes)
EvtCleanupCallback 93515b90 driver!EvtCleanupCallback
EvtDestroyCallback 93515cc0 driver!EvtDestroyCallback

context: dt 0x89f45e40 SECOND_CONTEXT (size is 0x8 bytes)
EvtCleanupCallback 93510460 driver!SecondEvtCleanupCallback

Parent: !wdfhandle 0x725f89b8, type is WDFOBJECT

Unfortunately, the driver itself wasn’t so happy with the change. In particular, I was getting the SecondEvtCleanupCallback callback called at strange times (e.g. when a driver of a child device was querying for an interface):

kd> k
# ChildEBP RetAddr
00 88cff248 847c62dc driver!SecondEvtCleanupCallback+0x5
01 88cff28c 847c9d06 Wdf01000!FxPkgPnp::HandleQueryInterface+0x1b5
02 88cff2a0 847c5e02 Wdf01000!FxPkgPdo::_PnpQueryInterface+0x15


That brings up a question. Is what I did acceptable and officially supported? Or was it a hack with which I managed to corrupt memory?

Thanks,
Rafal


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Rafal Zwierz wrote:

I have just noticed that !wdfhandle shows ‘> callbacks>’ even for second and subsequent contexts that are
> registered for an object. That led me to thinking that it might be
> possible to register more EvtCleanupCallback (or in fact
> EvtDestroyCallback) callbacks. Since I couldn’t find a function which
> would do that explicitly (unless I missed something in the docs) I
> decided to call WdfObjectAllocateContext with
> wdfObjAttr.EvtCleanupCallback set.
>
> Lo and behold, it worked. Well, at least as far as WinDbg is concerned:
> …
> Unfortunately, the driver itself wasn’t so happy with the change. In
> particular, I was getting the SecondEvtCleanupCallback callback called
> at strange times (e.g. when a driver of a child device was querying
> for an interface):
> …
> That brings up a question. Is what I did acceptable and officially
> supported? Or was it a hack with which I managed to corrupt memory?

It’s fully supported. Those callbacks are associated with the context,
not with the object. The contexts happen to be associated with the
object, but you can have an arbitrary number of contexts associated with
any given object, assuming you use a different ContextTypeInfo for the
second context.

Did your cleanup callback do something silly, like destroy the object?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Hi Doron,

Thanks for the super fast reply. As soon as I hit send I realised that
it might be just the case of empty implementation ;-). Adding body to
the function fixed this problem.

Re second callback. I am not sure whether I really needed - the
question was driven by a curiosity rather by a strong need for the
second callback.

Having said that I am now considering the use of this feature in a
following scenario. I have a payload object created by a transport
library. I want to process this payload and then send a reply. This
reply will be based on the original payload and might also contain
additional data (stored in a WDFMEMORY object). I am playing with the
idea about creating new context for the payload object to which I
could add the WDFMEMORY. I would then pass this payload back to the
transport library which would send back the payload with any
additional data stored and when it is done with the payload it would
discard it. Since I want the payload to own the WDFMEMORY I would need
to add an additional cleanup so that I don’t leak the memory. Does it
sound horribly convoluted?

Thanks,
Rafal

On 21 March 2011 19:31, Doron Holan wrote:
> It is acceptable, it is not a hack. I am guessing that SecondEvtCleanupCallback is an empty function and the function you registered for the QI callback is also empty, so the compiler folded both definitions into one function body. Why do you think you need a 2nd cleanup callback?
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Rafal Zwierz
> Sent: Monday, March 21, 2011 12:28 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Two (or more) EvtCleanupCallback functions registered for one WDFOBJECT?
>
> Hi,
>
> I have just noticed that !wdfhandle shows ‘> callbacks>’ even for second and subsequent contexts that are
> registered for an object. That led me to thinking that it might be possible to register more EvtCleanupCallback (or in fact
> EvtDestroyCallback) callbacks. Since I couldn’t find a function which would do that explicitly (unless I missed something in the docs) I decided to call WdfObjectAllocateContext with wdfObjAttr.EvtCleanupCallback set.
>
> Lo and behold, it worked. Well, at least as far as WinDbg is concerned:
>
>
> Dumping WDFHANDLE 0x78581d58
> =============================
> Handle type is WDFOBJECT
> Refcount: 1
> Contexts:
> ? ?context: ?dt 0x87a7e2f0 FIRST_CONTEXT (size is 0x48 bytes)
> ? ?EvtCleanupCallback 93515b90 driver!EvtCleanupCallback
> ? ?EvtDestroyCallback 93515cc0 driver!EvtDestroyCallback
>
> ? ?context: ?dt 0x89f45e40 SECOND_CONTEXT (size is 0x8 bytes)
> ? ?EvtCleanupCallback 93510460 driver!SecondEvtCleanupCallback
>
> Parent: !wdfhandle 0x725f89b8, type is WDFOBJECT
>
> Unfortunately, the driver itself wasn’t so happy with the change. In particular, I was getting the SecondEvtCleanupCallback callback called at strange times (e.g. when a driver of a child device was querying for an interface):
>
> kd> k
> ?# ChildEBP RetAddr
> 00 88cff248 847c62dc driver!SecondEvtCleanupCallback+0x5
> 01 88cff28c 847c9d06 Wdf01000!FxPkgPnp::HandleQueryInterface+0x1b5
> 02 88cff2a0 847c5e02 Wdf01000!FxPkgPdo::_PnpQueryInterface+0x15
> …
>
> That brings up a question. Is what I did acceptable and officially supported? Or was it a hack with which I managed to corrupt memory?
>
> Thanks,
> Rafal
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

If the payload itself is a WDF object (request, memory, whatever) of any kind, you can create the WDFMEMORY as a child of the payload object and KMDF will automatically free the WDFMEMORY when the payload object is freed. You could use the 2nd cleanup() callback too, but by using the object hierarchy, you can get this for free

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Rafal Zwierz
Sent: Monday, March 21, 2011 12:43 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Two (or more) EvtCleanupCallback functions registered for one WDFOBJECT?

Hi Doron,

Thanks for the super fast reply. As soon as I hit send I realised that it might be just the case of empty implementation ;-). Adding body to the function fixed this problem.

Re second callback. I am not sure whether I really needed - the question was driven by a curiosity rather by a strong need for the second callback.

Having said that I am now considering the use of this feature in a following scenario. I have a payload object created by a transport library. I want to process this payload and then send a reply. This reply will be based on the original payload and might also contain additional data (stored in a WDFMEMORY object). I am playing with the idea about creating new context for the payload object to which I could add the WDFMEMORY. I would then pass this payload back to the transport library which would send back the payload with any additional data stored and when it is done with the payload it would discard it. Since I want the payload to own the WDFMEMORY I would need to add an additional cleanup so that I don’t leak the memory. Does it sound horribly convoluted?

Thanks,
Rafal

On 21 March 2011 19:31, Doron Holan wrote:
> It is acceptable, it is not a hack. I am guessing that SecondEvtCleanupCallback is an empty function and the function you registered for the QI callback is also empty, so the compiler folded both definitions into one function body. Why do you think you need a 2nd cleanup callback?
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Rafal Zwierz
> Sent: Monday, March 21, 2011 12:28 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Two (or more) EvtCleanupCallback functions registered for one WDFOBJECT?
>
> Hi,
>
> I have just noticed that !wdfhandle shows ‘> callbacks>’ even for second and subsequent contexts that are
> registered for an object. That led me to thinking that it might be
> possible to register more EvtCleanupCallback (or in fact
> EvtDestroyCallback) callbacks. Since I couldn’t find a function which would do that explicitly (unless I missed something in the docs) I decided to call WdfObjectAllocateContext with wdfObjAttr.EvtCleanupCallback set.
>
> Lo and behold, it worked. Well, at least as far as WinDbg is concerned:
>
>
> Dumping WDFHANDLE 0x78581d58
> =============================
> Handle type is WDFOBJECT
> Refcount: 1
> Contexts:
> ? ?context: ?dt 0x87a7e2f0 FIRST_CONTEXT (size is 0x48 bytes)
> ? ?EvtCleanupCallback 93515b90 driver!EvtCleanupCallback
> ? ?EvtDestroyCallback 93515cc0 driver!EvtDestroyCallback
>
> ? ?context: ?dt 0x89f45e40 SECOND_CONTEXT (size is 0x8 bytes)
> ? ?EvtCleanupCallback 93510460 driver!SecondEvtCleanupCallback
>
> Parent: !wdfhandle 0x725f89b8, type is WDFOBJECT
>
> Unfortunately, the driver itself wasn’t so happy with the change. In particular, I was getting the SecondEvtCleanupCallback callback called at strange times (e.g. when a driver of a child device was querying for an interface):
>
> kd> k
> ?# ChildEBP RetAddr
> 00 88cff248 847c62dc driver!SecondEvtCleanupCallback+0x5
> 01 88cff28c 847c9d06 Wdf01000!FxPkgPnp::HandleQueryInterface+0x1b5
> 02 88cff2a0 847c5e02 Wdf01000!FxPkgPdo::_PnpQueryInterface+0x15
> …
>
> That brings up a question. Is what I did acceptable and officially supported? Or was it a hack with which I managed to corrupt memory?
>
> Thanks,
> Rafal
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

True. I think I will use the object hierarchy.
Thanks
Rafał


Sent from mobile phone

On 22 Mar 2011, at 02:16, Doron Holan wrote:

> If the payload itself is a WDF object (request, memory, whatever) of any kind, you can create the WDFMEMORY as a child of the payload object and KMDF will automatically free the WDFMEMORY when the payload object is freed. You could use the 2nd cleanup() callback too, but by using the object hierarchy, you can get this for free
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Rafal Zwierz
> Sent: Monday, March 21, 2011 12:43 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Two (or more) EvtCleanupCallback functions registered for one WDFOBJECT?
>
> Hi Doron,
>
> Thanks for the super fast reply. As soon as I hit send I realised that it might be just the case of empty implementation ;-). Adding body to the function fixed this problem.
>
> Re second callback. I am not sure whether I really needed - the question was driven by a curiosity rather by a strong need for the second callback.
>
> Having said that I am now considering the use of this feature in a following scenario. I have a payload object created by a transport library. I want to process this payload and then send a reply. This reply will be based on the original payload and might also contain additional data (stored in a WDFMEMORY object). I am playing with the idea about creating new context for the payload object to which I could add the WDFMEMORY. I would then pass this payload back to the transport library which would send back the payload with any additional data stored and when it is done with the payload it would discard it. Since I want the payload to own the WDFMEMORY I would need to add an additional cleanup so that I don’t leak the memory. Does it sound horribly convoluted?
>
> Thanks,
> Rafal
>
> On 21 March 2011 19:31, Doron Holan wrote:
>> It is acceptable, it is not a hack. I am guessing that SecondEvtCleanupCallback is an empty function and the function you registered for the QI callback is also empty, so the compiler folded both definitions into one function body. Why do you think you need a 2nd cleanup callback?
>>
>> d
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Rafal Zwierz
>> Sent: Monday, March 21, 2011 12:28 PM
>> To: Windows System Software Devs Interest List
>> Subject: [ntdev] Two (or more) EvtCleanupCallback functions registered for one WDFOBJECT?
>>
>> Hi,
>>
>> I have just noticed that !wdfhandle shows ‘>> callbacks>’ even for second and subsequent contexts that are
>> registered for an object. That led me to thinking that it might be
>> possible to register more EvtCleanupCallback (or in fact
>> EvtDestroyCallback) callbacks. Since I couldn’t find a function which would do that explicitly (unless I missed something in the docs) I decided to call WdfObjectAllocateContext with wdfObjAttr.EvtCleanupCallback set.
>>
>> Lo and behold, it worked. Well, at least as far as WinDbg is concerned:
>>
>>
>> Dumping WDFHANDLE 0x78581d58
>> =============================
>> Handle type is WDFOBJECT
>> Refcount: 1
>> Contexts:
>> context: dt 0x87a7e2f0 FIRST_CONTEXT (size is 0x48 bytes)
>> EvtCleanupCallback 93515b90 driver!EvtCleanupCallback
>> EvtDestroyCallback 93515cc0 driver!EvtDestroyCallback
>>
>> context: dt 0x89f45e40 SECOND_CONTEXT (size is 0x8 bytes)
>> EvtCleanupCallback 93510460 driver!SecondEvtCleanupCallback
>>
>> Parent: !wdfhandle 0x725f89b8, type is WDFOBJECT
>>
>> Unfortunately, the driver itself wasn’t so happy with the change. In particular, I was getting the SecondEvtCleanupCallback callback called at strange times (e.g. when a driver of a child device was querying for an interface):
>>
>> kd> k
>> # ChildEBP RetAddr
>> 00 88cff248 847c62dc driver!SecondEvtCleanupCallback+0x5
>> 01 88cff28c 847c9d06 Wdf01000!FxPkgPnp::HandleQueryInterface+0x1b5
>> 02 88cff2a0 847c5e02 Wdf01000!FxPkgPdo::_PnpQueryInterface+0x15
>> …
>>
>> That brings up a question. Is what I did acceptable and officially supported? Or was it a hack with which I managed to corrupt memory?
>>
>> Thanks,
>> Rafal
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer