type of memory allocated for WdfRegistryQueryMultiString

James_Harper · August 7, 2009, 7:12am

I’m doing some string operations (eg RtlXxxStringXxx) in my drivers, and
even though I am at PASSIVE_LEVEL, the swap file isn’t yet running on
resume from hibernate.

In my EvtDeviceAdd I grab the contents of a MultiString registry value
using WdfRegistryQueryMultiString. In the restore path when I try to
access the data that was grabbed in EvtDeviceAdd, I deadlock. Presumably
WdfRegistryQueryMultiString has allocated from PagedPool and the data
has been paged out. I’ve never seen it happen when not running the
verifier but it’s still a problem that needs fixing. So I need to tell
WdfRegistryQueryMultiString to allocate all the memory it requires from
NonPagedPool.

Am I out of luck here? If it can’t be done then I’ll need to copy the
data into a NonPagedPool structure myself, which involves writing more
code to work around limitations in WDF…

Thanks

James

Maxim_S_Shatskih · August 7, 2009, 7:16am

>Am I out of luck here?

Yes, I think the whole registry code is pageable.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

James_Harper · August 7, 2009, 7:20am

>

>Am I out of luck here?

Yes, I think the whole registry code is pageable.

I read the keys during normal driver install and I store the wdf
collection handle in my driver context. That all works fine.

It’s when I go and access the data later (not accessing the registry,
accessing the strings I previously read from the registry) I find that
it’s paged out. It’s not the registry I am accessing, it’s just some WDF
string’s, which are (I assume) allocated from PagedPool instead of
NonPagedPool.

James

Mark_Roddy · August 7, 2009, 7:35am

If the execution level of the collection object is set to
WdfExecutionLevelDispatch shouldn’t all of its collected objects also
be appropriate to dispatch level operations?

Mark Roddy

On Fri, Aug 7, 2009 at 7:19 AM, James
Harper wrote:
>>
>> >Am I out of luck here?
>>
>> Yes, I think the whole registry code is pageable.
>>
>
> I read the keys during normal driver install and I store the wdf
> collection handle in my driver context. That all works fine.
>
> It’s when I go and access the data later (not accessing the registry,
> accessing the strings I previously read from the registry) I find that
> it’s paged out. It’s not the registry I am accessing, it’s just some WDF
> string’s, which are (I assume) allocated from PagedPool instead of
> NonPagedPool.
>
> James
>
> —
> 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
>

James_Harper · August 7, 2009, 7:55am

>

If the execution level of the collection object is set to
WdfExecutionLevelDispatch shouldn’t all of its collected objects also
be appropriate to dispatch level operations?

I started chasing that down in the docs too, but it says of
“WDF_OBJECT_ATTRIBUTES”:

“specifies the maximum IRQL at which the framework will call the
object’s event callback functions”
And
“By default, the framework sets the ExecutionLevel value of framework
driver objects to WdfExecutionLevelDispatch”

So I think it only relates to the callback functions, and is set to
Dispatch by default anyway.

James

Mark_Roddy · August 7, 2009, 8:58am

I am not an expert on WDF, but it would not make a lot of sense to
have the objects collected be pageable while the callbacks that
process those objects are executing at dispatch level. Perhaps when
Doron or one of the other devs for WDF wake up they will illumninate
us.

Mark Roddy

On Fri, Aug 7, 2009 at 7:54 AM, James
Harper wrote:
>>
>> If the execution level of the collection object is set to
>> WdfExecutionLevelDispatch shouldn’t all of its collected objects also
>> be appropriate to dispatch level operations?
>>
>
> I started chasing that down in the docs too, but it says of
> “WDF_OBJECT_ATTRIBUTES”:
>
> “specifies the maximum IRQL at which the framework will call the
> object’s event callback functions”
> And
> “By default, the framework sets the ExecutionLevel value of framework
> driver objects to WdfExecutionLevelDispatch”
>
> So I think it only relates to the callback functions, and is set to
> Dispatch by default anyway.
>
> James
>
>
>
>
> —
> 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 · August 7, 2009, 8:59am

You probably have to roll your own. All of the WdfStringXxx() access
functions seem to be pinned to PASSIVE_LEVEL. When I need to have access to
a UNICODE_STRING at DISPATCH_LEVEL I use a simple approach of converting
WDFSTRING objects to WDFMEMORY objects. I just attach a UNICODE_STRING
structure as a context, point it at the memory, setup the lengths, and use a
context accessor (MyGetUnicodeString for instance) to provide essentially
the same use pattern but not the IRQL restriction.

As for the multi-string thing, well, writing a conversion routine that walks
the collection of WDFSTRING and produces a new collection of WDFMEMORY seems
pretty straight forward.

In retrospect, I think I should have complained to the WDF team about not
being able to attribute WDFSTRING creation to allocate from NonPagedPool.
They probably agonized over that and perhaps one of them will step in and
share the back-story. In the end, the work-around was not that big a deal.

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Friday, August 07, 2009 7:20 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] type of memory allocated for
WdfRegistryQueryMultiString

>Am I out of luck here?

Yes, I think the whole registry code is pageable.

I read the keys during normal driver install and I store the wdf
collection handle in my driver context. That all works fine.

It’s when I go and access the data later (not accessing the registry,
accessing the strings I previously read from the registry) I find that
it’s paged out. It’s not the registry I am accessing, it’s just some WDF
string’s, which are (I assume) allocated from PagedPool instead of
NonPagedPool.

James

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

James_Harper · August 7, 2009, 9:17am

>

You probably have to roll your own. All of the WdfStringXxx() access
functions seem to be pinned to PASSIVE_LEVEL. When I need to have
access to
a UNICODE_STRING at DISPATCH_LEVEL I use a simple approach of
converting
WDFSTRING objects to WDFMEMORY objects. I just attach a
UNICODE_STRING
structure as a context, point it at the memory, setup the lengths, and
use a
context accessor (MyGetUnicodeString for instance) to provide
essentially
the same use pattern but not the IRQL restriction.

As for the multi-string thing, well, writing a conversion routine that
walks
the collection of WDFSTRING and produces a new collection of WDFMEMORY
seems
pretty straight forward.

In retrospect, I think I should have complained to the WDF team about
not
being able to attribute WDFSTRING creation to allocate from
NonPagedPool.
They probably agonized over that and perhaps one of them will step in
and
share the back-story. In the end, the work-around was not that big a
deal.

Thanks. I was secretly hoping for someone to step up and say something
like “Just call the magic WdfSetAllocateAllMemoryFromNonPagedPool()
function” but obviously it wasn’t to be

Having thought about it some more, some of those RtlXxx functions can
allocate their own memory when required, and there is no way to control
where they get it from. If they were being called by Wdf (and why
wouldn’t Wdf use them?) then that probably explains it.

Is there such thing as a ‘page file lock’ or other synchronisation
object that I could acquire for testing and debug purposes? If I could
acquire the hypothetical ‘page file lock’ before I do things like this
and a paging operation tries to happen (it will hang because at this
point I haven’t restarted the device holding the pagefile yet as I am
resuming from hibernate) then the verifier should catch the deadlock and
I’d know instantly where the problem was, rather than just having a hang
that requires the use of the debugger to find (or KdPrint’s - I can
rebuild my drivers, upload to the remote machine, and reboot it about 10
times faster than I can attach the debugger and get the system to the
point where it will hang and then debug it :).

Thanks

James

James_Harper · August 7, 2009, 9:25am

>

Thanks. I was secretly hoping for someone to step up and say something
like “Just call the magic WdfSetAllocateAllMemoryFromNonPagedPool()
function” but obviously it wasn’t to be

In theory, could I create an Mdl for each allocated buffer and then do
MmProbeAndLockPages to stop it being swapped out?

In reality, locking a 4K page of memory to preserve a ~64 byte string
isn’t really a smart thing to do, especially when there are several
strings probably all on separate pages, I’m just curious.

Maybe if I locked the pages before hibernate then unlocked them
afterwards it would be better, although I think by the time the driver
knows that the hibernate is going to happen it’s too late to read them
from the page file (if required).

I’ll just copy the strings to a linked list and leave it at that I
think.

James

David_R_Cattley · August 7, 2009, 9:39am

AFAIK, the FxObject is not paged but the memory allocated to hold the string
might be. FxObject(s) with dispatch level execution contracts end up
having spinlocks to protect the internal context. They would all be NP. My
experience so far is that I have not seen an actual WDF Object itself be
allocated from NP pool but that might just be because I have not hit the
case it makes sense yet.

I think, however, that all of the memory that defines framework context
(FxObject) and allocations for the ‘association’ objects in the collection
that store the reference to the ‘collected’ objects, along with the
framework context of each collected object, is entirely in NP memory and
thus traversable/accesable at elevated IRQL.

Consider that WdfObjectDelete() is callable at DISPATCH_LEVEL. That would
pretty much mean an object, no matter what, cannot have the FxObject in
paged pool.

So I think Jame’s issue is that the backing pool for the string data itself
is in NPPool, not the remaining goobledygook of the FxObjects, etc.

Cheers,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Friday, August 07, 2009 8:58 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] type of memory allocated for
WdfRegistryQueryMultiString

I am not an expert on WDF, but it would not make a lot of sense to
have the objects collected be pageable while the callbacks that
process those objects are executing at dispatch level. Perhaps when
Doron or one of the other devs for WDF wake up they will illumninate
us.

Mark Roddy

On Fri, Aug 7, 2009 at 7:54 AM, James
Harper wrote:
>>
>> If the execution level of the collection object is set to
>> WdfExecutionLevelDispatch shouldn’t all of its collected objects also
>> be appropriate to dispatch level operations?
>>
>
> I started chasing that down in the docs too, but it says of
> “WDF_OBJECT_ATTRIBUTES”:
>
> “specifies the maximum IRQL at which the framework will call the
> object’s event callback functions”
> And
> “By default, the framework sets the ExecutionLevel value of framework
> driver objects to WdfExecutionLevelDispatch”
>
> So I think it only relates to the callback functions, and is set to
> Dispatch by default anyway.
>
> James
>
>
>
>
> —
> 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 · August 7, 2009, 10:00am

Yes the underlying class that supports the handle is NP. For additional memory allocations such as for WDFSTRING or a pageable WDFMEMORY buffer, they can come from pagable pool. The buffer in WDFSTRING is always pagable, this follow the pattern of Rtl and since nearly all supporting string APIs are passive lvel only, it does not make much sense to put the string buffers in NP pool.

Mark, the execution level only dictates callbacks (and even then really only callbacks on queues). If it were set to dispatch, what api would you use to create the string inf the first place? Again all of them require passive…

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: David R. Cattley
Sent: Friday, August 07, 2009 6:48 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] type of memory allocated for WdfRegistryQueryMultiString

AFAIK, the FxObject is not paged but the memory allocated to hold the string
might be. FxObject(s) with dispatch level execution contracts end up
having spinlocks to protect the internal context. They would all be NP. My
experience so far is that I have not seen an actual WDF Object itself be
allocated from NP pool but that might just be because I have not hit the
case it makes sense yet.

I think, however, that all of the memory that defines framework context
(FxObject) and allocations for the ‘association’ objects in the collection
that store the reference to the ‘collected’ objects, along with the
framework context of each collected object, is entirely in NP memory and
thus traversable/accesable at elevated IRQL.

Consider that WdfObjectDelete() is callable at DISPATCH_LEVEL. That would
pretty much mean an object, no matter what, cannot have the FxObject in
paged pool.

So I think Jame’s issue is that the backing pool for the string data itself
is in NPPool, not the remaining goobledygook of the FxObjects, etc.

Cheers,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Friday, August 07, 2009 8:58 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] type of memory allocated for
WdfRegistryQueryMultiString

I am not an expert on WDF, but it would not make a lot of sense to
have the objects collected be pageable while the callbacks that
process those objects are executing at dispatch level. Perhaps when
Doron or one of the other devs for WDF wake up they will illumninate
us.

Mark Roddy

On Fri, Aug 7, 2009 at 7:54 AM, James
Harper wrote:
>>
>> If the execution level of the collection object is set to
>> WdfExecutionLevelDispatch shouldn’t all of its collected objects also
>> be appropriate to dispatch level operations?
>>
>
> I started chasing that down in the docs too, but it says of
> “WDF_OBJECT_ATTRIBUTES”:
>
> “specifies the maximum IRQL at which the framework will call the
> object’s event callback functions”
> And
> “By default, the framework sets the ExecutionLevel value of framework
> driver objects to WdfExecutionLevelDispatch”
>
> So I think it only relates to the callback functions, and is set to
> Dispatch by default anyway.
>
> James
>
>
>
>
> —
> 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

Mark_Roddy · August 7, 2009, 11:08am

The use case is clear. One initializes the collection of strings at
passive level but then need to access them subsequently at dispatch
level. The collection needs to be dispatch level safe. Perhaps it is
just a doc issue, but for the WDM and earlier apis, the Rtl docs make
it clear that the returned strings if allocated by the interface are
allocated from paged pool, the WDF docs obscure this information, thus
causing James to have his problem.

Mark Roddy

On Fri, Aug 7, 2009 at 10:00 AM, Doron Holan wrote:
> Yes the underlying class that supports the handle is NP. For additional memory allocations such as for WDFSTRING or a pageable WDFMEMORY buffer, they can come from pagable pool. The buffer in WDFSTRING is always pagable, this follow the pattern of Rtl and since nearly all supporting string APIs are passive lvel only, it does not make much sense to put the string buffers in NP pool.
>
> Mark, the execution level only dictates callbacks (and even then really only callbacks on queues). If it were set to dispatch, what api would you use to create the string inf the first place? Again all of them require passive…
>
> d
>
> Sent from my phone with no t9, all spilling mistakes are not intentional.
>
> -----Original Message-----
> From: David R. Cattley
> Sent: Friday, August 07, 2009 6:48 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] type of memory allocated for WdfRegistryQueryMultiString
>
>
> AFAIK, the FxObject is not paged but the memory allocated to hold the string
> might be. ? FxObject(s) with dispatch level execution contracts end up
> having spinlocks to protect the internal context. ?They would all be NP. My
> experience so far is that I have not seen an actual WDF Object itself be
> allocated from NP pool but that might just be because I have not hit the
> case it makes sense yet.
>
> I think, however, that all of the memory that defines framework context
> (FxObject) and allocations for the ‘association’ objects in the collection
> that store the reference to the ‘collected’ objects, along with the
> framework context of each collected object, is entirely in NP memory and
> thus traversable/accesable at elevated IRQL.
>
> Consider that WdfObjectDelete() is callable at DISPATCH_LEVEL. ?That would
> pretty much mean an object, no matter what, cannot have the FxObject in
> paged pool.
>
> So I think Jame’s issue is that the backing pool for the string data itself
> is in NPPool, not the remaining goobledygook of the FxObjects, etc.
>
> Cheers,
> Dave Cattley
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
> Sent: Friday, August 07, 2009 8:58 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] type of memory allocated for
> WdfRegistryQueryMultiString
>
> I am not an expert on WDF, but it would not make a lot of sense to
> have the objects collected be pageable while the callbacks that
> process those objects are executing at dispatch level. Perhaps when
> Doron or one of the other devs for WDF wake up they will illumninate
> us.
>
> Mark Roddy
>
>
>
> On Fri, Aug 7, 2009 at 7:54 AM, James
> Harper wrote:
>>>
>>> If the execution level of the collection object is set to
>>> WdfExecutionLevelDispatch shouldn’t all of its collected objects also
>>> be appropriate to dispatch level operations?
>>>
>>
>> I started chasing that down in the docs too, but it says of
>> “WDF_OBJECT_ATTRIBUTES”:
>>
>> “specifies the maximum IRQL at which the framework will call the
>> object’s event callback functions”
>> And
>> “By default, the framework sets the ExecutionLevel value of framework
>> driver objects to WdfExecutionLevelDispatch”
>>
>> So I think it only relates to the callback functions, and is set to
>> Dispatch by default anyway.
>>
>> James
>>
>>
>>
>>
>> —
>> 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
>

Doron_Holan · August 7, 2009, 11:36am

The collection object itself is NP, just the string buffers are paged. WDFSTRING is not a generalized srtring class (note there is no cat, compare, etc), it solves one small design problem controlling the lifetime of a string alloc’ed by kmdf and giving you a way to free it. Outside of that purpose which suites the vast majority, you will need to roll your own whatever it is you need

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: Mark Roddy
Sent: Friday, August 07, 2009 8:08 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] type of memory allocated for WdfRegistryQueryMultiString

The use case is clear. One initializes the collection of strings at
passive level but then need to access them subsequently at dispatch
level. The collection needs to be dispatch level safe. Perhaps it is
just a doc issue, but for the WDM and earlier apis, the Rtl docs make
it clear that the returned strings if allocated by the interface are
allocated from paged pool, the WDF docs obscure this information, thus
causing James to have his problem.

Mark Roddy

On Fri, Aug 7, 2009 at 10:00 AM, Doron Holan wrote:
> Yes the underlying class that supports the handle is NP. For additional memory allocations such as for WDFSTRING or a pageable WDFMEMORY buffer, they can come from pagable pool. The buffer in WDFSTRING is always pagable, this follow the pattern of Rtl and since nearly all supporting string APIs are passive lvel only, it does not make much sense to put the string buffers in NP pool.
>
> Mark, the execution level only dictates callbacks (and even then really only callbacks on queues). If it were set to dispatch, what api would you use to create the string inf the first place? Again all of them require passive…
>
> d
>
> Sent from my phone with no t9, all spilling mistakes are not intentional.
>
> -----Original Message-----
> From: David R. Cattley
> Sent: Friday, August 07, 2009 6:48 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] type of memory allocated for WdfRegistryQueryMultiString
>
>
> AFAIK, the FxObject is not paged but the memory allocated to hold the string
> might be. FxObject(s) with dispatch level execution contracts end up
> having spinlocks to protect the internal context. They would all be NP. My
> experience so far is that I have not seen an actual WDF Object itself be
> allocated from NP pool but that might just be because I have not hit the
> case it makes sense yet.
>
> I think, however, that all of the memory that defines framework context
> (FxObject) and allocations for the ‘association’ objects in the collection
> that store the reference to the ‘collected’ objects, along with the
> framework context of each collected object, is entirely in NP memory and
> thus traversable/accesable at elevated IRQL.
>
> Consider that WdfObjectDelete() is callable at DISPATCH_LEVEL. That would
> pretty much mean an object, no matter what, cannot have the FxObject in
> paged pool.
>
> So I think Jame’s issue is that the backing pool for the string data itself
> is in NPPool, not the remaining goobledygook of the FxObjects, etc.
>
> Cheers,
> Dave Cattley
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
> Sent: Friday, August 07, 2009 8:58 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] type of memory allocated for
> WdfRegistryQueryMultiString
>
> I am not an expert on WDF, but it would not make a lot of sense to
> have the objects collected be pageable while the callbacks that
> process those objects are executing at dispatch level. Perhaps when
> Doron or one of the other devs for WDF wake up they will illumninate
> us.
>
> Mark Roddy
>
>
>
> On Fri, Aug 7, 2009 at 7:54 AM, James
> Harper wrote:
>>>
>>> If the execution level of the collection object is set to
>>> WdfExecutionLevelDispatch shouldn’t all of its collected objects also
>>> be appropriate to dispatch level operations?
>>>
>>
>> I started chasing that down in the docs too, but it says of
>> “WDF_OBJECT_ATTRIBUTES”:
>>
>> “specifies the maximum IRQL at which the framework will call the
>> object’s event callback functions”
>> And
>> “By default, the framework sets the ExecutionLevel value of framework
>> driver objects to WdfExecutionLevelDispatch”
>>
>> So I think it only relates to the callback functions, and is set to
>> Dispatch by default anyway.
>>
>> James
>>
>>
>>
>>
>> —
>> 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
>

—
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

James_Harper · August 7, 2009, 8:08pm

>

The collection object itself is NP, just the string buffers are paged.
WDFSTRING is not a generalized srtring class (note there is no cat,
compare,
etc), it solves one small design problem controlling the lifetime of a
string
alloc’ed by kmdf and giving you a way to free it. Outside of that
purpose
which suites the vast majority, you will need to roll your own
whatever it is
you need

Thanks for the clarification Doron.

The collection contains an enumerated list from a registry multi string
value, and represents a list of xen device names that my bus driver
should not enumerate (either because they don’t represent real devices
or because I don’t have a driver for them (nothing to be gained by
having a paravirtualised keyboard driver when the emulated one is
sufficient)). Ultimately I convert them to ANSI strings before comparing
them to each xen device name before I actually enumerate a device (or
not) so I’ll do the conversion at boot time and just store the strings
as a list (LIST_ENTRY etc), allocated from NonPagedPool.

Thanks again.

James