Hi,
When the third parameter for RtlAnsiStringToUnicodeString and
RtlUnicodeStringToAnsiString is TRUE those functions will allocate the
destination string themselves when converting from ANSI_STRING to
UNICODE_STRING or vice versa. Furthermore, RtlStringFromGUID will always
allocate the destination string itself.
Is there a way to control the pool type (specifically, how can I force it to
be NonPagedPool) of the buffer that will be allocated for the destination
string?
What is the pool type these functions use by default?
Thanks,
Shahar
Seeing that these APIs can only be called at passive level, they
allocate from PagedPool. If you want the buffer to be from NonPagedPool
you can either:
-
call RtlAnsiStringToUnicodeSize and allocate the buffer yourself
-
let RtlAnsiStringToUnicodeString do the allocation, then allocate
your own buffer and free the old one via RtlFreeUnicodeString. Seeing
that RtlFreeUnicodeString zeros out the complete structure, I would go
for option 1)
There is no way to change the pool they allocate from.
d
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
Sent: Thursday, September 23, 2004 10:16 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] RtlAnsiStringToUnicodeString and
RtlUnicodeStringToAnsiString
Hi,
When the third parameter for RtlAnsiStringToUnicodeString and
RtlUnicodeStringToAnsiString is TRUE those functions will allocate the
destination string themselves when converting from ANSI_STRING to
UNICODE_STRING or vice versa. Furthermore, RtlStringFromGUID will always
allocate the destination string itself.
Is there a way to control the pool type (specifically, how can I force
it to be NonPagedPool) of the buffer that will be allocated for the
destination string?
What is the pool type these functions use by default?
Thanks,
Shahar
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument:
''
To unsubscribe send a blank email to xxxxx@lists.osr.com