Having trouble forcing a WdfTime to execute at passive level

Shane_Corbin · April 15, 2008, 2:53pm

I’ve set AutomaticSerialization to false, and the execution level of the timer’s object attributes to passive, but it fails to create my timer. Am I overlooking something?

Here’s what I’m doing when it fails:

WDF_TIMER_CONFIG_INIT();
set auto serialization false
set period
WDF_OBJECT_ATTRIBUITES_INIT();
set executionlevel passive
WdfTimerCreate();

If I set serialization true, and set the parent object to the device, while omitting the execution level the timer callback is always called at dispatch level. I’m trying to do some Zw file i/o in my callback, and I don’t want these routines called at dispatch level.

Tim_Roberts · April 15, 2008, 3:20pm

xxxxx@hotmail.com wrote:

I’ve set AutomaticSerialization to false, and the execution level of the timer’s object attributes to passive, but it fails to create my timer. Am I overlooking something?
…
If I set serialization true, and set the parent object to the device, while omitting the execution level the timer callback is always called at dispatch level. I’m trying to do some Zw file i/o in my callback, and I don’t want these routines called at dispatch level.

Timer callbacks are ALWAYS called at dispatch level.
http://msdn2.microsoft.com/en-us/library/aa492464.aspx
http://msdn2.microsoft.com/en-us/library/aa490189.aspx

If you need passive, you’ll need to queue up a work item in your timer
callback.

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

Peter_Viscarola_OSR · April 15, 2008, 4:10pm

Tim’s right.

The key point is that you can’t constrain execution level of timer callbacks using the SynchronizationScope file of the WDF_OBJECT_ATTRIBUTES for the WDFTIMER Object. You can only use the Sync Scope field in WDF_OBJECT_ATTRIBUTES to constrain the callbacks that are direct decendants of WDFQUEUE and/or WDFDEVICE. See: http://msdn2.microsoft.com/en-us/library/aa491377.aspx

I know this can be very confusing…

Peter
OSR

Shane_Corbin · April 15, 2008, 4:35pm

Well then, that’d explain it.

Thanks for that drop of knowledge. I’ll get these things figured out someday; hopefully.

David_R_Cattley · April 16, 2008, 12:44pm

So I counted myself among the thoroughly confused when I read this and then
went back and re-read the MSDN page Peter refers to. I have to say, having
now read it quite a few times, I did not find where one could conclude that
WDFTIMERs (not regular timers mind you, that is clear) could not invoke
there callback synchronized to a Parent WDFDEVICE or WDFQUEUE at the
execution level of the parent (if it happens to be passive level).

So indeed, this remained very confusing until I went to read the MSDN page
on WDF_EXECUTION_LEVEL at
http://msdn2.microsoft.com/en-us/library/aa491405.aspx which says (in part)

WdfExecutionLevelInheritFromParent
The framework uses the maximum IRQL value of the object’s parent, unless the
object is one that requires IRQL = DISPATCH_LEVEL (such as a DPC object).
This value is the default if a driver does not specify a
WDF_EXECUTION_LEVEL-typed value.

WdfExecutionLevelPassive
The framework always calls the object’s callback functions at IRQL =
PASSIVE_LEVEL.

Now note well the offhand remark about “(such as a DPC object)”. So
cutting the overworked DocTeam some slack, lets just go ahead sweep into
that category WDFTIMER as well (it would be better if it used the term
WDFDPC instead of DPC, btw.)

So looking at the page for EvtTimerFunc we see that

The EvtTimerFunc callback function is called at IRQL = DISPATCH_LEVEL.

But I have yet to find the explicit prohibition on WdfExecutionLevelPassive
or a table of objects (until Peter published the opposite table) which says
what all of the callback serviced objects are that cannot therefore, share
the synchronization scope of a WDFDEVICE or WDFQUEUE if the the execution
level is PASSIVE_LEVEL. I’m sure it is somewhere.

So I can now say I have made the transition from “Thoroughly Confused” to
“Mildly Befuddled” on this point. I was among (the probably many) that
simply assumed that KMDF added the useful feature of bundling the necessary
Work Item bounce to PASSIVE_LEVEL ‘under the covers’ when it saw that a
callback object was created which was joined in a synchronization domain
with a passive level execution constraint. But this magic is ‘not in
scope’ and surely for good reason (not that I know what it is).

-dave

wrote in message news:xxxxx@ntdev…
> Tim’s right.
>
> The key point is that you can’t constrain execution level of timer
> callbacks using the SynchronizationScope file of the WDF_OBJECT_ATTRIBUTES
> for the WDFTIMER Object. You can only use the Sync Scope field in
> WDF_OBJECT_ATTRIBUTES to constrain the callbacks that are direct
> decendants of WDFQUEUE and/or WDFDEVICE. See:
> http://msdn2.microsoft.com/en-us/library/aa491377.aspx
>
> I know this can be very confusing…
>
> Peter
> OSR
>
>
>
>

Doron_Holan · April 16, 2008, 12:59pm

These 2 features (execution level, sync scope) are the only parts of KMDF that I can never remember and wrap my mind around. To me, they hurt way more then they help, but that is just my opnion ;).

As for passive level timers, the version of KMDF should have them (with an explicit init option to create them).

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Wednesday, April 16, 2008 9:43 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Having trouble forcing a WdfTime to execute at passive level

So I counted myself among the thoroughly confused when I read this and then
went back and re-read the MSDN page Peter refers to. I have to say, having
now read it quite a few times, I did not find where one could conclude that
WDFTIMERs (not regular timers mind you, that is clear) could not invoke
there callback synchronized to a Parent WDFDEVICE or WDFQUEUE at the
execution level of the parent (if it happens to be passive level).

So indeed, this remained very confusing until I went to read the MSDN page
on WDF_EXECUTION_LEVEL at
http://msdn2.microsoft.com/en-us/library/aa491405.aspx which says (in part)

WdfExecutionLevelInheritFromParent
The framework uses the maximum IRQL value of the object’s parent, unless the
object is one that requires IRQL = DISPATCH_LEVEL (such as a DPC object).
This value is the default if a driver does not specify a
WDF_EXECUTION_LEVEL-typed value.

WdfExecutionLevelPassive
The framework always calls the object’s callback functions at IRQL =
PASSIVE_LEVEL.

Now note well the offhand remark about “(such as a DPC object)”. So
cutting the overworked DocTeam some slack, lets just go ahead sweep into
that category WDFTIMER as well (it would be better if it used the term
WDFDPC instead of DPC, btw.)

So looking at the page for EvtTimerFunc we see that

The EvtTimerFunc callback function is called at IRQL = DISPATCH_LEVEL.

But I have yet to find the explicit prohibition on WdfExecutionLevelPassive
or a table of objects (until Peter published the opposite table) which says
what all of the callback serviced objects are that cannot therefore, share
the synchronization scope of a WDFDEVICE or WDFQUEUE if the the execution
level is PASSIVE_LEVEL. I’m sure it is somewhere.

So I can now say I have made the transition from “Thoroughly Confused” to
“Mildly Befuddled” on this point. I was among (the probably many) that
simply assumed that KMDF added the useful feature of bundling the necessary
Work Item bounce to PASSIVE_LEVEL ‘under the covers’ when it saw that a
callback object was created which was joined in a synchronization domain
with a passive level execution constraint. But this magic is ‘not in
scope’ and surely for good reason (not that I know what it is).

-dave

wrote in message news:xxxxx@ntdev…
> Tim’s right.
>
> The key point is that you can’t constrain execution level of timer
> callbacks using the SynchronizationScope file of the WDF_OBJECT_ATTRIBUTES
> for the WDFTIMER Object. You can only use the Sync Scope field in
> WDF_OBJECT_ATTRIBUTES to constrain the callbacks that are direct
> decendants of WDFQUEUE and/or WDFDEVICE. See:
> http://msdn2.microsoft.com/en-us/library/aa491377.aspx
>
> I know this can be very confusing…
>
> Peter
> OSR
>
>
>
>

—
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

David_R_Cattley · April 16, 2008, 1:12pm

Doron,

You just moved me back to “Thoroughly Confused”

Are you saying that KMDF 1.x “does” or “should but does not” have this
feature of passive level timer callback?

-dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, April 16, 2008 12:56 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Having trouble forcing a WdfTime to execute at
passive level

These 2 features (execution level, sync scope) are the only parts of KMDF
that I can never remember and wrap my mind around. To me, they hurt way
more then they help, but that is just my opnion ;).

As for passive level timers, the version of KMDF should have them (with an
explicit init option to create them).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Wednesday, April 16, 2008 9:43 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Having trouble forcing a WdfTime to execute at passive
level

So I counted myself among the thoroughly confused when I read this and then
went back and re-read the MSDN page Peter refers to. I have to say, having
now read it quite a few times, I did not find where one could conclude that
WDFTIMERs (not regular timers mind you, that is clear) could not invoke
there callback synchronized to a Parent WDFDEVICE or WDFQUEUE at the
execution level of the parent (if it happens to be passive level).

So indeed, this remained very confusing until I went to read the MSDN page
on WDF_EXECUTION_LEVEL at
http://msdn2.microsoft.com/en-us/library/aa491405.aspx which says (in part)

WdfExecutionLevelInheritFromParent
The framework uses the maximum IRQL value of the object’s parent, unless the
object is one that requires IRQL = DISPATCH_LEVEL (such as a DPC object).
This value is the default if a driver does not specify a
WDF_EXECUTION_LEVEL-typed value.

WdfExecutionLevelPassive
The framework always calls the object’s callback functions at IRQL =
PASSIVE_LEVEL.

Now note well the offhand remark about “(such as a DPC object)”. So
cutting the overworked DocTeam some slack, lets just go ahead sweep into
that category WDFTIMER as well (it would be better if it used the term
WDFDPC instead of DPC, btw.)

So looking at the page for EvtTimerFunc we see that

The EvtTimerFunc callback function is called at IRQL = DISPATCH_LEVEL.

But I have yet to find the explicit prohibition on WdfExecutionLevelPassive
or a table of objects (until Peter published the opposite table) which says
what all of the callback serviced objects are that cannot therefore, share
the synchronization scope of a WDFDEVICE or WDFQUEUE if the the execution
level is PASSIVE_LEVEL. I’m sure it is somewhere.

So I can now say I have made the transition from “Thoroughly Confused” to
“Mildly Befuddled” on this point. I was among (the probably many) that
simply assumed that KMDF added the useful feature of bundling the necessary
Work Item bounce to PASSIVE_LEVEL ‘under the covers’ when it saw that a
callback object was created which was joined in a synchronization domain
with a passive level execution constraint. But this magic is ‘not in
scope’ and surely for good reason (not that I know what it is).

-dave

wrote in message news:xxxxx@ntdev…
> Tim’s right.
>
> The key point is that you can’t constrain execution level of timer
> callbacks using the SynchronizationScope file of the WDF_OBJECT_ATTRIBUTES
> for the WDFTIMER Object. You can only use the Sync Scope field in
> WDF_OBJECT_ATTRIBUTES to constrain the callbacks that are direct
> decendants of WDFQUEUE and/or WDFDEVICE. See:
> http://msdn2.microsoft.com/en-us/library/aa491377.aspx
>
> I know this can be very confusing…
>
> Peter
> OSR
>
>
>
>

—
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

Doron_Holan · April 16, 2008, 1:22pm

Sorry about that. The *next* version of KMDF will have passive level timers. Current versions do not

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Wednesday, April 16, 2008 10:12 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Having trouble forcing a WdfTime to execute at passive level

Doron,

You just moved me back to “Thoroughly Confused”

Are you saying that KMDF 1.x “does” or “should but does not” have this
feature of passive level timer callback?

-dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, April 16, 2008 12:56 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Having trouble forcing a WdfTime to execute at
passive level

These 2 features (execution level, sync scope) are the only parts of KMDF
that I can never remember and wrap my mind around. To me, they hurt way
more then they help, but that is just my opnion ;).

As for passive level timers, the version of KMDF should have them (with an
explicit init option to create them).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Wednesday, April 16, 2008 9:43 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Having trouble forcing a WdfTime to execute at passive
level

So I counted myself among the thoroughly confused when I read this and then
went back and re-read the MSDN page Peter refers to. I have to say, having
now read it quite a few times, I did not find where one could conclude that
WDFTIMERs (not regular timers mind you, that is clear) could not invoke
there callback synchronized to a Parent WDFDEVICE or WDFQUEUE at the
execution level of the parent (if it happens to be passive level).

So indeed, this remained very confusing until I went to read the MSDN page
on WDF_EXECUTION_LEVEL at
http://msdn2.microsoft.com/en-us/library/aa491405.aspx which says (in part)

WdfExecutionLevelInheritFromParent
The framework uses the maximum IRQL value of the object’s parent, unless the
object is one that requires IRQL = DISPATCH_LEVEL (such as a DPC object).
This value is the default if a driver does not specify a
WDF_EXECUTION_LEVEL-typed value.

WdfExecutionLevelPassive
The framework always calls the object’s callback functions at IRQL =
PASSIVE_LEVEL.

Now note well the offhand remark about “(such as a DPC object)”. So
cutting the overworked DocTeam some slack, lets just go ahead sweep into
that category WDFTIMER as well (it would be better if it used the term
WDFDPC instead of DPC, btw.)

So looking at the page for EvtTimerFunc we see that

The EvtTimerFunc callback function is called at IRQL = DISPATCH_LEVEL.

But I have yet to find the explicit prohibition on WdfExecutionLevelPassive
or a table of objects (until Peter published the opposite table) which says
what all of the callback serviced objects are that cannot therefore, share
the synchronization scope of a WDFDEVICE or WDFQUEUE if the the execution
level is PASSIVE_LEVEL. I’m sure it is somewhere.

So I can now say I have made the transition from “Thoroughly Confused” to
“Mildly Befuddled” on this point. I was among (the probably many) that
simply assumed that KMDF added the useful feature of bundling the necessary
Work Item bounce to PASSIVE_LEVEL ‘under the covers’ when it saw that a
callback object was created which was joined in a synchronization domain
with a passive level execution constraint. But this magic is ‘not in
scope’ and surely for good reason (not that I know what it is).

-dave

wrote in message news:xxxxx@ntdev…
> Tim’s right.
>
> The key point is that you can’t constrain execution level of timer
> callbacks using the SynchronizationScope file of the WDF_OBJECT_ATTRIBUTES
> for the WDFTIMER Object. You can only use the Sync Scope field in
> WDF_OBJECT_ATTRIBUTES to constrain the callbacks that are direct
> decendants of WDFQUEUE and/or WDFDEVICE. See:
> http://msdn2.microsoft.com/en-us/library/aa491377.aspx
>
> I know this can be very confusing…
>
> Peter
> OSR
>
>
>
>

—
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

David_R_Cattley · April 16, 2008, 1:26pm

-> “Mildly Befuddled”

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, April 16, 2008 1:20 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Having trouble forcing a WdfTime to execute at
passive level

Sorry about that. The *next* version of KMDF will have passive level
timers. Current versions do not

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Wednesday, April 16, 2008 10:12 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Having trouble forcing a WdfTime to execute at
passive level

Doron,

You just moved me back to “Thoroughly Confused”

Are you saying that KMDF 1.x “does” or “should but does not” have this
feature of passive level timer callback?

-dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, April 16, 2008 12:56 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Having trouble forcing a WdfTime to execute at
passive level

These 2 features (execution level, sync scope) are the only parts of KMDF
that I can never remember and wrap my mind around. To me, they hurt way
more then they help, but that is just my opnion ;).

As for passive level timers, the version of KMDF should have them (with an
explicit init option to create them).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Wednesday, April 16, 2008 9:43 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Having trouble forcing a WdfTime to execute at passive
level

So I counted myself among the thoroughly confused when I read this and then
went back and re-read the MSDN page Peter refers to. I have to say, having
now read it quite a few times, I did not find where one could conclude that
WDFTIMERs (not regular timers mind you, that is clear) could not invoke
there callback synchronized to a Parent WDFDEVICE or WDFQUEUE at the
execution level of the parent (if it happens to be passive level).

So indeed, this remained very confusing until I went to read the MSDN page
on WDF_EXECUTION_LEVEL at
http://msdn2.microsoft.com/en-us/library/aa491405.aspx which says (in part)

WdfExecutionLevelInheritFromParent
The framework uses the maximum IRQL value of the object’s parent, unless the
object is one that requires IRQL = DISPATCH_LEVEL (such as a DPC object).
This value is the default if a driver does not specify a
WDF_EXECUTION_LEVEL-typed value.

WdfExecutionLevelPassive
The framework always calls the object’s callback functions at IRQL =
PASSIVE_LEVEL.

Now note well the offhand remark about “(such as a DPC object)”. So
cutting the overworked DocTeam some slack, lets just go ahead sweep into
that category WDFTIMER as well (it would be better if it used the term
WDFDPC instead of DPC, btw.)

So looking at the page for EvtTimerFunc we see that

The EvtTimerFunc callback function is called at IRQL = DISPATCH_LEVEL.

But I have yet to find the explicit prohibition on WdfExecutionLevelPassive
or a table of objects (until Peter published the opposite table) which says
what all of the callback serviced objects are that cannot therefore, share
the synchronization scope of a WDFDEVICE or WDFQUEUE if the the execution
level is PASSIVE_LEVEL. I’m sure it is somewhere.

So I can now say I have made the transition from “Thoroughly Confused” to
“Mildly Befuddled” on this point. I was among (the probably many) that
simply assumed that KMDF added the useful feature of bundling the necessary
Work Item bounce to PASSIVE_LEVEL ‘under the covers’ when it saw that a
callback object was created which was joined in a synchronization domain
with a passive level execution constraint. But this magic is ‘not in
scope’ and surely for good reason (not that I know what it is).

-dave

wrote in message news:xxxxx@ntdev…
> Tim’s right.
>
> The key point is that you can’t constrain execution level of timer
> callbacks using the SynchronizationScope file of the WDF_OBJECT_ATTRIBUTES
> for the WDFTIMER Object. You can only use the Sync Scope field in
> WDF_OBJECT_ATTRIBUTES to constrain the callbacks that are direct
> decendants of WDFQUEUE and/or WDFDEVICE. See:
> http://msdn2.microsoft.com/en-us/library/aa491377.aspx
>
> I know this can be very confusing…
>
> Peter
> OSR
>
>
>
>

—
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

Tim_Roberts · April 16, 2008, 1:26pm

Doron Holan wrote:

These 2 features (execution level, sync scope) are the only parts of KMDF that I can never remember and wrap my mind around. To me, they hurt way more then they help, but that is just my opnion ;).

Yes, I agree. The only real problem I encountered during my first KMDF
experience was with synchronization scope. I made the somewhat naïve
leap that “if a little synchronization is good, then a lot must be
better.” Deadlock reports from the client made my folly clear.

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

Stephen_Cleary · April 16, 2008, 3:07pm

Doron Holan wrote:

These 2 features (execution level, sync scope) are the only parts of KMDF that
I can never remember and wrap my mind around. To me, they hurt way more then
they help, but that is just my opnion ;).

Tim Roberts wrote:

Yes, I agree. The only real problem I encountered during my first KMDF
experience was with synchronization scope.

I also agree. Having worked with KMDF for about a year now, the hardest part for me was also the synchronization scope (and how it interactes with serialization and the object’s parent hierarchy).

I just keep a copy of pg 392 from Orwick/Smith’s “Developing Drivers With the WDF” at my desk. That whole section of that book is excellent, and I hope to see something similar (with the “Summary of KMDF Callback Serialization” table) in MSDN someday.

-Stephen Cleary

Doron_Holan · April 16, 2008, 3:18pm

Good suggestion. I fwd’ed the request to our doc writer.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Wednesday, April 16, 2008 12:12 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Having trouble forcing a WdfTime to execute at passive level

Doron Holan wrote:

These 2 features (execution level, sync scope) are the only parts of KMDF that
I can never remember and wrap my mind around. To me, they hurt way more then
they help, but that is just my opnion ;).

Tim Roberts wrote:

Yes, I agree. The only real problem I encountered during my first KMDF
experience was with synchronization scope.

I also agree. Having worked with KMDF for about a year now, the hardest part for me was also the synchronization scope (and how it interactes with serialization and the object’s parent hierarchy).

I just keep a copy of pg 392 from Orwick/Smith’s “Developing Drivers With the WDF” at my desk. That whole section of that book is excellent, and I hope to see something similar (with the “Summary of KMDF Callback Serialization” table) in MSDN someday.

-Stephen Cleary

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