RtlStringCbVPrintfW and IRQL

In my driver I want to create some WCHAR strings based on an input
format string, so I use RtlStringCbVPrintfW. Now the docs don’t
mention anything about IRQL requirements, but after running in the
checked build, I get assertion failures because the function is
sometimes called at DISPATCH_LEVEL.

The stack trace at the time shows ansi->unicode conversion going on,
which I know can’t be called at dispatch_level because the mapping
tables are in paged memory.

What’s strange is that my format string is this:

L"%4.4d/%2.2d/%2.2d %2.2d:%2.2d:%2.2d.%3.3d"

All I’m trying to do is compose a date string, and from a posting a
while back regarding swprintf / RtlStringCbVPrintfW , it seems that as
long as there are no string format specifiers, the IRQL shouldn’t
matter.

Any ideas as to what I’m doing wrong?

Callers of RtlStringCbVPrintfExW and RtlStringCbVPrintfExA must be running
at IRQL = PASSIVE_LEVEL.

Cant be much clearer whatever you think; them’s the rules, if you break 'em,
some day, you hose the system. I guess this is your thread
http://www.osronline.com/showThread.cfm?link=71570 from before.

You arent by some wierd chance passing some paged pool or the like for the
output string?

wrote in message news:xxxxx@ntdev…
> In my driver I want to create some WCHAR strings based on an input
> format string, so I use RtlStringCbVPrintfW. Now the docs don’t
> mention anything about IRQL requirements, but after running in the
> checked build, I get assertion failures because the function is
> sometimes called at DISPATCH_LEVEL.
>
> The stack trace at the time shows ansi->unicode conversion going on,
> which I know can’t be called at dispatch_level because the mapping
> tables are in paged memory.
>
> What’s strange is that my format string is this:
>
> L"%4.4d/%2.2d/%2.2d %2.2d:%2.2d:%2.2d.%3.3d"
>
> All I’m trying to do is compose a date string, and from a posting a
> while back regarding swprintf / RtlStringCbVPrintfW , it seems that as
> long as there are no string format specifiers, the IRQL shouldn’t
> matter.
>
> Any ideas as to what I’m doing wrong?
>

Strange, I’ve never seen the MSDN docs specifically state an IRQL
requirement for RtlStringCbVPrintfW (or RtlStringCbVPrintfExW). Can
you point me to where you saw this? Hopefully I haven’t been
referencing outdated docs this whole time! :slight_smile:

Regardless, it is obviously the case that there is a restriction that
IRQL must be PASSIVE_LEVEL, because down the line, the system calls
RtlAnsiStringToUnicodeString.

What I’m really curious about is why it needs to go through a
RtlAnsiStringToUnicodeString at all if my format specifier is just a
bunch of %d and the arguments are just a bunch of integers. Because
in the thread I read (the one you reference below) it seems this
should not be the case.

BTW, I’m not using any paged pool memory for output buffer.

On Tue, 28 Mar 2006 00:15:10 +0100, “Lyndon J. Clarke”
wrote:

>Callers of RtlStringCbVPrintfExW and RtlStringCbVPrintfExA must be running
>at IRQL = PASSIVE_LEVEL.
>
>Cant be much clearer whatever you think; them’s the rules, if you break 'em,
>some day, you hose the system. I guess this is your thread
>http://www.osronline.com/showThread.cfm?link=71570 from before.
>
>You arent by some wierd chance passing some paged pool or the like for the
>output string?
>
> wrote in message news:xxxxx@ntdev…
>> In my driver I want to create some WCHAR strings based on an input
>> format string, so I use RtlStringCbVPrintfW. Now the docs don’t
>> mention anything about IRQL requirements, but after running in the
>> checked build, I get assertion failures because the function is
>> sometimes called at DISPATCH_LEVEL.
>>
>> The stack trace at the time shows ansi->unicode conversion going on,
>> which I know can’t be called at dispatch_level because the mapping
>> tables are in paged memory.
>>
>> What’s strange is that my format string is this:
>>
>> L"%4.4d/%2.2d/%2.2d %2.2d:%2.2d:%2.2d.%3.3d"
>>
>> All I’m trying to do is compose a date string, and from a posting a
>> while back regarding swprintf / RtlStringCbVPrintfW , it seems that as
>> long as there are no string format specifiers, the IRQL shouldn’t
>> matter.
>>
>> Any ideas as to what I’m doing wrong?
>>
>
>

unicode tables are stored in paged pool, that’s why all Rtl* functions which
works with unicode string has to be called at passive_level – those
functions are also declared in paged memory (with using #pragma alloc(page,
…)) – it’s quite annoying to call e.g. RtlUpcaseUnicodeString only at
passive_level :slight_smile:

even DbgPrint with the unicode format codes (%C, %wZ, …) has to be called
with IRQL passive_level (see ddk help)

wrote in message news:xxxxx@ntdev…
> Strange, I’ve never seen the MSDN docs specifically state an IRQL
> requirement for RtlStringCbVPrintfW (or RtlStringCbVPrintfExW). Can
> you point me to where you saw this? Hopefully I haven’t been
> referencing outdated docs this whole time! :slight_smile:
>
> Regardless, it is obviously the case that there is a restriction that
> IRQL must be PASSIVE_LEVEL, because down the line, the system calls
> RtlAnsiStringToUnicodeString.
>
> What I’m really curious about is why it needs to go through a
> RtlAnsiStringToUnicodeString at all if my format specifier is just a
> bunch of %d and the arguments are just a bunch of integers. Because
> in the thread I read (the one you reference below) it seems this
> should not be the case.
>
> BTW, I’m not using any paged pool memory for output buffer.
>
> On Tue, 28 Mar 2006 00:15:10 +0100, “Lyndon J. Clarke”
> wrote:
>
>>Callers of RtlStringCbVPrintfExW and RtlStringCbVPrintfExA must be running
>>at IRQL = PASSIVE_LEVEL.
>>
>>Cant be much clearer whatever you think; them’s the rules, if you break
>>'em,
>>some day, you hose the system. I guess this is your thread
>>http://www.osronline.com/showThread.cfm?link=71570 from before.
>>
>>You arent by some wierd chance passing some paged pool or the like for the
>>output string?
>>
>> wrote in message news:xxxxx@ntdev…
>>> In my driver I want to create some WCHAR strings based on an input
>>> format string, so I use RtlStringCbVPrintfW. Now the docs don’t
>>> mention anything about IRQL requirements, but after running in the
>>> checked build, I get assertion failures because the function is
>>> sometimes called at DISPATCH_LEVEL.
>>>
>>> The stack trace at the time shows ansi->unicode conversion going on,
>>> which I know can’t be called at dispatch_level because the mapping
>>> tables are in paged memory.
>>>
>>> What’s strange is that my format string is this:
>>>
>>> L"%4.4d/%2.2d/%2.2d %2.2d:%2.2d:%2.2d.%3.3d"
>>>
>>> All I’m trying to do is compose a date string, and from a posting a
>>> while back regarding swprintf / RtlStringCbVPrintfW , it seems that as
>>> long as there are no string format specifiers, the IRQL shouldn’t
>>> matter.
>>>
>>> Any ideas as to what I’m doing wrong?
>>>
>>
>>
>

xxxxx@msn.com wrote:

Strange, I’ve never seen the MSDN docs specifically state an IRQL
requirement for RtlStringCbVPrintfW (or RtlStringCbVPrintfExW). Can
you point me to where you saw this? Hopefully I haven’t been
referencing outdated docs this whole time! :slight_smile:

Regardless, it is obviously the case that there is a restriction that
IRQL must be PASSIVE_LEVEL, because down the line, the system calls
RtlAnsiStringToUnicodeString.

What I’m really curious about is why it needs to go through a
RtlAnsiStringToUnicodeString at all if my format specifier is just a
bunch of %d and the arguments are just a bunch of integers. Because
in the thread I read (the one you reference below) it seems this
should not be the case.

It’s complicated.

If you look at ntstrsafe.h, you’ll see that RtlStringCbVPrintfW
eventually calls vsnwprintf. If you look at vsnwprintf in the C
run-time library included in the Visual Studio .NET 2005 (and I *am*
assuming that the one in libcntpr.lib is virtually identical), you’ll
see that it eventually calls __woutput (as ALL of the printf variants
eventually do). If you look at THAT routine, you’ll see that, for every
% conversion that it does, it maintains a flag which says whether it
wrote any Unicode characters during this conversion. At the end of each
conversion, if the flag does not match the desired output type, it
converts the characters it just wrote.

In the case of the integer conversions, it writes 8-bit characters and
sets the flag to “narrow” (non-Unicode). Since every character that can
be written during a numeric conversion (0-9.,±E) is the same in ANSI
and Unicode, it would be safe to always set the flag to skip the
character set conversion, but they don’t do it that way.


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

I’ve long considered the pageable unicode translation tables to be one of
the stupidest examples of misusing kernel pageable data. WCHAR data is
useful in the kernel, is frequently a requirement, is forced on you if you
are using the system event log, and is pervasive up in user mode. And yet %S
ends up tossing an exception if your code path might be >= DISPATCH_LEVEL.
Grrr… Offhand I think that perhaps a simpler version of unicode support
for kernel string processing, one that took a more restricted view of things
that one might consider to be a character, like say the ascii character set,
and supported WCHAR operations at any IRQL without the occasional bugcheck
would be a good idea.

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, March 28, 2006 7:50 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] RtlStringCbVPrintfW and IRQL

xxxxx@msn.com wrote:

>Strange, I’ve never seen the MSDN docs specifically state an IRQL
>requirement for RtlStringCbVPrintfW (or RtlStringCbVPrintfExW). Can
>you point me to where you saw this? Hopefully I haven’t been
>referencing outdated docs this whole time! :slight_smile:
>
>Regardless, it is obviously the case that there is a
restriction that
>IRQL must be PASSIVE_LEVEL, because down the line, the system calls
>RtlAnsiStringToUnicodeString.
>
>What I’m really curious about is why it needs to go through a
>RtlAnsiStringToUnicodeString at all if my format specifier is just a
>bunch of %d and the arguments are just a bunch of integers. Because
>in the thread I read (the one you reference below) it seems this
>should not be the case.
>
>

It’s complicated.

If you look at ntstrsafe.h, you’ll see that
RtlStringCbVPrintfW eventually calls vsnwprintf. If you look
at vsnwprintf in the C run-time library included in the
Visual Studio .NET 2005 (and I *am* assuming that the one in
libcntpr.lib is virtually identical), you’ll see that it
eventually calls __woutput (as ALL of the printf variants
eventually do). If you look at THAT routine, you’ll see
that, for every % conversion that it does, it maintains a
flag which says whether it wrote any Unicode characters
during this conversion. At the end of each conversion, if
the flag does not match the desired output type, it converts
the characters it just wrote.

In the case of the integer conversions, it writes 8-bit
characters and sets the flag to “narrow” (non-Unicode).
Since every character that can be written during a numeric
conversion (0-9.,±E) is the same in ANSI and Unicode, it
would be safe to always set the flag to skip the character
set conversion, but they don’t do it that way.


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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

I agree that this is an unnecessary annoyance in principle, but in
practice, what are you going to *do* with a Unicode string in the
kernel? Probably pass it to something like ZwCreateFile or
RtlQueryRegistryValues.

As far as I can tell, almost all of the kernel functions that take
strings as inputs (or generate strings as outputs) do something that is
or could be legitimately pageable (or might need to wait).

Now, that’s not to say there’s a legitimate reason *any more* to make
the Unicode tables pageable (or, indeed, almost anything in the kernel
save perhaps the registry and other memory mapped files), but at the
time the functions were first designed memory wasn’t free.

So I’m inclined to give MS a break as long as they express remorse about
it :-).

Mark Roddy wrote:

I’ve long considered the pageable unicode translation tables to be one of
the stupidest examples of misusing kernel pageable data. WCHAR data is
useful in the kernel, is frequently a requirement, is forced on you if you
are using the system event log, and is pervasive up in user mode. And yet %S
ends up tossing an exception if your code path might be >= DISPATCH_LEVEL.
Grrr… Offhand I think that perhaps a simpler version of unicode support
for kernel string processing, one that took a more restricted view of things
that one might consider to be a character, like say the ascii character set,
and supported WCHAR operations at any IRQL without the occasional bugcheck
would be a good idea.

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
> Sent: Tuesday, March 28, 2006 7:50 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] RtlStringCbVPrintfW and IRQL
>
> xxxxx@msn.com wrote:
>
>> Strange, I’ve never seen the MSDN docs specifically state an IRQL
>> requirement for RtlStringCbVPrintfW (or RtlStringCbVPrintfExW). Can
>> you point me to where you saw this? Hopefully I haven’t been
>> referencing outdated docs this whole time! :slight_smile:
>>
>> Regardless, it is obviously the case that there is a
> restriction that
>> IRQL must be PASSIVE_LEVEL, because down the line, the system calls
>> RtlAnsiStringToUnicodeString.
>>
>> What I’m really curious about is why it needs to go through a
>> RtlAnsiStringToUnicodeString at all if my format specifier is just a
>> bunch of %d and the arguments are just a bunch of integers. Because
>> in the thread I read (the one you reference below) it seems this
>> should not be the case.
>>
>>
> It’s complicated.
>
> If you look at ntstrsafe.h, you’ll see that
> RtlStringCbVPrintfW eventually calls vsnwprintf. If you look
> at vsnwprintf in the C run-time library included in the
> Visual Studio .NET 2005 (and I *am* assuming that the one in
> libcntpr.lib is virtually identical), you’ll see that it
> eventually calls __woutput (as ALL of the printf variants
> eventually do). If you look at THAT routine, you’ll see
> that, for every % conversion that it does, it maintains a
> flag which says whether it wrote any Unicode characters
> during this conversion. At the end of each conversion, if
> the flag does not match the desired output type, it converts
> the characters it just wrote.
>
> In the case of the integer conversions, it writes 8-bit
> characters and sets the flag to “narrow” (non-Unicode).
> Since every character that can be written during a numeric
> conversion (0-9.,±E) is the same in ANSI and Unicode, it
> would be safe to always set the flag to skip the character
> set conversion, but they don’t do it that way.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online
> at http://www.osronline.com/page.cfm?name=ListServer
>


Ray

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Ray Trent[SMTP:xxxxx@synaptics.spamblock.com]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, March 29, 2006 11:09 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] RtlStringCbVPrintfW and IRQL

I agree that this is an unnecessary annoyance in principle, but in
practice, what are you going to *do* with a Unicode string in the
kernel? Probably pass it to something like ZwCreateFile or
RtlQueryRegistryValues.

Print using DbgPrint(). For example to display readable device/link name at DISPATCH_LEVEL to distinguish instances in traces. Once I encountered check build of ndis.sys which caused bugcheck for this exact reason. %wZ at DISPATCH_LEVEL.

Now, that’s not to say there’s a legitimate reason *any more* to make
the Unicode tables pageable (or, indeed, almost anything in the kernel
save perhaps the registry and other memory mapped files), but at the
time the functions were first designed memory wasn’t free.

Yes but it hardly has justification in this millennium.

So I’m inclined to give MS a break as long as they express remorse about
it :-).

Well, the best remorse would be to finally fix it :slight_smile: Better late than never.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

“Mark Roddy” wrote in message news:xxxxx@ntdev…
> I’ve long considered the pageable unicode translation tables to be one of
> the stupidest examples of misusing kernel pageable data.

So, is there a simple way to lock these tables in memory, at least temporary?

–PA

No.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Wednesday, March 29, 2006 3:05 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] RtlStringCbVPrintfW and IRQL

“Mark Roddy” wrote in message news:xxxxx@ntdev…
> I’ve long considered the pageable unicode translation tables to be one
of
> the stupidest examples of misusing kernel pageable data.

So, is there a simple way to lock these tables in memory, at least
temporary?

–PA


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Is there a complicated way to do it? :slight_smile:

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, March 29, 2006 6:11 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] RtlStringCbVPrintfW and IRQL

No.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Wednesday, March 29, 2006 3:05 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] RtlStringCbVPrintfW and IRQL

“Mark Roddy” wrote in message news:xxxxx@ntdev…
> I’ve long considered the pageable unicode translation tables to be one
of
> the stupidest examples of misusing kernel pageable data.

So, is there a simple way to lock these tables in memory, at least
temporary?

–PA


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

no

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, March 29, 2006 3:24 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] RtlStringCbVPrintfW and IRQL

Is there a complicated way to do it? :slight_smile:

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, March 29, 2006 6:11 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] RtlStringCbVPrintfW and IRQL

No.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Wednesday, March 29, 2006 3:05 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] RtlStringCbVPrintfW and IRQL

“Mark Roddy” wrote in message news:xxxxx@ntdev…
> I’ve long considered the pageable unicode translation tables to be one
of
> the stupidest examples of misusing kernel pageable data.

So, is there a simple way to lock these tables in memory, at least
temporary?

–PA


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

I am not sure I understand the point of this discussion.
I have not seen non-ASCI in the kernel so far, so a
“converter” like

char* pSrc =
wchar_t* pDst =

// for non-zero terminated:
size_t Ctr =
for(size_t ctr = 0; ctr < Ctr; ++ctr) {
*pDst++ = *pSrc++; // char-> wchar_t, ok for ascii
}

// even simpler for zero-terminated source:
for(; *pSrc;) {
*pDst++ = *pSrc++; // char-> wchar_t, ok for ascii
}
*pDst = 0; // well, if you insist…

does the job at any irql.

Yes, it does not look logical to unicode everything
in the kernel on one hand and and limit irql’s for unicode-
related helper functions, but I can imagine how it happened
and it does not look like a major problem to me (that is,
until I decide to celebrate myself or my collegues and
name my devices in russian or polish or hindu or mandarin).

Am I missing something and in fact life w/o %wZ on dispatch
level is not worth living?

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, March 29, 2006 6:29 PM
Subject: RE: [ntdev] RtlStringCbVPrintfW and IRQL

no

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, March 29, 2006 3:24 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] RtlStringCbVPrintfW and IRQL

Is there a complicated way to do it? :slight_smile:

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, March 29, 2006 6:11 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] RtlStringCbVPrintfW and IRQL

No.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Wednesday, March 29, 2006 3:05 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] RtlStringCbVPrintfW and IRQL

“Mark Roddy” wrote in message news:xxxxx@ntdev…
> I’ve long considered the pageable unicode translation tables to be one
of
> the stupidest examples of misusing kernel pageable data.

So, is there a simple way to lock these tables in memory, at least
temporary?

–PA


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Well what there is of course a simple algorithmic solution to the %wZ or %S
debugprint problem: restrict the supported character set to ascii.
Translation is now just AND off the upper half of the WCHAR.

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, March 29, 2006 6:24 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] RtlStringCbVPrintfW and IRQL

Is there a complicated way to do it? :slight_smile:

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, March 29, 2006 6:11 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] RtlStringCbVPrintfW and IRQL

No.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Wednesday, March 29, 2006 3:05 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] RtlStringCbVPrintfW and IRQL

“Mark Roddy” wrote in message
> news:xxxxx@ntdev…
> > I’ve long considered the pageable unicode translation
> tables to be one
> of
> > the stupidest examples of misusing kernel pageable data.
>
> So, is there a simple way to lock these tables in memory, at
> least temporary?
>
>
> --PA
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online
> at http://www.osronline.com/page.cfm?name=ListServer
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online
> at http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online
> at http://www.osronline.com/page.cfm?name=ListServer
>