I wouldn’t toy with RtlXXXString IRQL requirements if you can find another
way.
In some situations it may be possible to upcase the strings at some prior
point at passive level (or when they are defined). If you can pull this off,
then you can 1.) check the Length and then 2.) if Length matches use
RtlCompareMemory on the Buffer at DISPATCH_LEVEL.
Thomas F. Divine
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Saturday, December 7, 2013 11:46 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] IRQL rules for RtlXxxString functions
The documentation for RtlXxxString and friends in most cases says IRQL must
be PASSIVE_LEVEL. Is this a hard and fast rule that the
verifier/PREfast/checked build is going to trip me up on, or is some
flexibility allowed?
If I can guarantee that the buffers for my UNICODE_STRING are NonPagedPool,
can I get away with calling RtlCompareUnicodeString? Or is it more that the
RtlCompareUnicodeString routine itself might be paged out?
My DeviceIdentification consists of two UNICODE_STRINGs of arbitrary length,
so they need to be managed separately to the DeviceIdentification. The names
reflect the name of a network resource that in turn has an arbitrary length
(there probably is an actual limit, but it’s probably longer than I want to
allocate “just in case”).
Thanks
James
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
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