DDK Doc say tht RtlStringCchVPrintfA can be used at PASSIVE_LEVEL.I want to use it in my storminiport statio routine which runs at dispatch level.any substitue functions available for this?
thanks in advance,
BTW i found the function _vsnprintf which do same as RtlStringCchVPrintfA.This function is not properly documented.I used both the version of function at DISPATCH_LEVEL.surprisingly,no kernel panic.So,i am confused which function to use.
-
technically none of the string functions, safe or unsafe, are available
to standard storport or scsiport miniport drivers, although this glaring
lack of functionality results in just about every storage miniport driver I
have had the pleasure (or otherwise) to work on either ignoring the api
restrictions (which continue to be not enforced for WHQL, unlike NDIS
miniports) or worse, inventing home-grown string functions to replace the
missing functionality. -
the RtlString* IRQL restrictions are imprecise. As far as I know the real
restriction is ‘don’t use wchar strings at >= DISPATCH_LEVEL’ as they can
touch code page tables that are unfortunately paged.
The available unsafe string functions are fine to use except that they do
not do the buffer overflow checking that the safe string functions provide,
and that checking is Real Good Stuff, so it is unfortunate re (1) and (2).
Mark Roddy
On Mon, Sep 13, 2010 at 8:24 AM, wrote:
> BTW i found the function _vsnprintf which do same as
> RtlStringCchVPrintfA.This function is not properly documented.I used both
> the version of function at DISPATCH_LEVEL.surprisingly,no kernel panic.So,i
> am confused which function to use.
>
> —
> 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
>
Two things:
-
The underlying reason for the printf related functions to be documented
with an execution IRQL requirement of PASSIVE_LEVEL is because they *may*
perform character set translations which require the character mapping
tables (UNICODE -> ANSI for instance) to be touched, and these tables are in
paged memory. -
Just because it worked does not mean you did not break the rules. The
system does not ‘enforce’ IRQL checking as this would be very expensive.
And touching a page that is ‘pageable’ but that happens to be present does
not cause any page fault and thus no harm is done.
It may well be that if you can restrict any format specification usage to
avoid implicit or explicit conversion from UNICODE to ANSI that calling at
IRQL == DISPATCH_LEVEL is permitted.
The documentation for KdPrint() states it this way:
Format
Specifies a pointer to the format string to print. The Format string
supports all the printf-style formatting codes. However, the Unicode format
codes (%C, %S, %lc, %ls, %wc, %ws, and %wZ) can only be used with IRQL =
PASSIVE_LEVEL.
I am under the impression that this applies to the ‘sprintf’ related
functions (char* variety) as well so
sprintf()
_vsnprintf()
RtlStringCchPrintfA
RtlStringCbPrintfA
etc…
But please, don’t use the “it must be ok because it worked” line. This list
tends to generate untoward responses to such logic.
Good Luck,
Dave Cattley
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@rediffmail.com
Sent: Monday, September 13, 2010 8:24 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] RtlStringCchVPrintfA at DISPATCH_LEVEL
BTW i found the function _vsnprintf which do same as
RtlStringCchVPrintfA.This function is not properly documented.I used both
the version of function at DISPATCH_LEVEL.surprisingly,no kernel panic.So,i
am confused which function to use.
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
>
- Just because it worked does not mean you did not break the rules.
The
system does not ‘enforce’ IRQL checking as this would be very
expensive.
And touching a page that is ‘pageable’ but that happens to be present
does
not cause any page fault and thus no harm is done.
Does the verifier alone ‘enforce’ IRQL checking enough to ‘prove’ this
one way or the other, or would you require a checked kernel? (and
checked safe string library?) Or is it still not doing enough checking
(eg running in ‘English’ windows is okay but another locale might break
it)?
Sounds like too many questions doesn’t it 
James
I think (which is way different than “I know” 
) that verifier will do
some of that checking when IRQL Checking is enabled but I am not sure. I
recall at least one feature in verifier that marks paged memory as not
present to force page faults in an effort to catch this type of issue.
Cheers,
Dave Cattley
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Monday, September 13, 2010 9:25 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] RtlStringCchVPrintfA at DISPATCH_LEVEL
- Just because it worked does not mean you did not break the rules.
The
system does not ‘enforce’ IRQL checking as this would be very
expensive.
And touching a page that is ‘pageable’ but that happens to be present
does
not cause any page fault and thus no harm is done.
Does the verifier alone ‘enforce’ IRQL checking enough to ‘prove’ this
one way or the other, or would you require a checked kernel? (and
checked safe string library?) Or is it still not doing enough checking
(eg running in ‘English’ windows is okay but another locale might break
it)?
Sounds like too many questions doesn’t it
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
I just encountered this in the WFP driver I’ve been developing.
RtlStringCchVPrintfA fails with driver verifier enabled while in a WFP
callout, which are called at DISPATCH_LEVEL. I haven’t tested without
verifier since I do want to find things like this.
Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Monday, September 13, 2010 8:25 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] RtlStringCchVPrintfA at DISPATCH_LEVEL
- Just because it worked does not mean you did not break the rules.
The
system does not ‘enforce’ IRQL checking as this would be very
expensive.
And touching a page that is ‘pageable’ but that happens to be present
does
not cause any page fault and thus no harm is done.
Does the verifier alone ‘enforce’ IRQL checking enough to ‘prove’ this one
way or the other, or would you require a checked kernel? (and checked safe
string library?) Or is it still not doing enough checking (eg running in
‘English’ windows is okay but another locale might break it)?
Sounds like too many questions doesn’t it
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
> DDK Doc say tht RtlStringCchVPrintfA can be used at PASSIVE_LEVEL.I want to use it in my
storminiport statio routine which runs at dispatch level.any substitue functions available for this?
I would write my own string routine instead.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com