MmGetSystemRoutineAddress BugCheck?

OSR_Community_User · June 5, 2007, 12:58pm

Won’t answer the speculations (do your own reverse engineering ;), but as for this, I’ll give a hint:

>
But what would happen if it queries for a routine that starts with _Aux?
<<

Assuming that it did do that, this is the part of the picture I could predict- it would be the world I live in today (if the assumption were correct):

No KMDF driver works on Win2K, WinXP, or WS03 RTM. Beginning with the release of KMDF 1.0. Our entire team across the span of several years, somehow manages to miss a bug that is readily reproduced on these platforms under these circumstances and then ships a product that crashes the moment ANYONE tries to use it on any of those platforms.

Like I said early on, we use MmGetSystemRoutineAddress routinely and have for years (and not just what’s in the lib), and we NEVER saw this bug, because we never have had reason to go near any of the broken cases. If we had, the whole tenor of this thread would have been different- Doron would already know how you could get a fix and even I would know what all the appropriate workarounds are, because we would of necessity be using them in KMDF.

OSR_Community_User · June 5, 2007, 1:20pm

Just in case anyone misinterprets my last reply…

That is not the name it is looking for… (makes eye contact, then an odd hand gesture to divert your attention while skillfully using “the Force” to make you forget you ever wondered about it)…

We use this call every time the loader loads a KMDF driver. I don’t know for sure how many times that has happened on these OSes, but it can’t be a particularly small number…

(Hmm, should have been “the world I would be living in today”- just can’t get things right in that first draft…)

-----Original Message-----
From: Bob Kjelgaard
Sent: Tuesday, June 05, 2007 9:58 AM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] MmGetSystemRoutineAddress BugCheck?

Won’t answer the speculations (do your own reverse engineering ;), but as for this, I’ll give a hint:

>
But what would happen if it queries for a routine that starts with _Aux?
<<

Assuming that it did do that, this is the part of the picture I could predict- it would be the world I live in today (if the assumption were correct):

No KMDF driver works on Win2K, WinXP, or WS03 RTM. Beginning with the release of KMDF 1.0. Our entire team across the span of several years, somehow manages to miss a bug that is readily reproduced on these platforms under these circumstances and then ships a product that crashes the moment ANYONE tries to use it on any of those platforms.

Like I said early on, we use MmGetSystemRoutineAddress routinely and have for years (and not just what’s in the lib), and we NEVER saw this bug, because we never have had reason to go near any of the broken cases. If we had, the whole tenor of this thread would have been different- Doron would already know how you could get a fix and even I would know what all the appropriate workarounds are, because we would of necessity be using them in KMDF.

OSR_Community_User · June 5, 2007, 3:23pm

Bob Kjelgaard wrote:

That is not the name it is looking for…
…
(Hmm, should have been “the world I would be living in today”-

That’s precisely what I meant. I assumed it doesn’t look for any aux* names (which could possibly be used as a valid method), precisely because otherwise we would be living in a different world. That was the meaning of the smiley

It is trivial to see which name is looking for, no need to actually reverse engineer…there seems to be a single UNICODE string in the library…

Maxim_S_Shatskih · June 5, 2007, 6:44pm

ZwQuerySystemInformation to get the kernel base, then parse the PE format.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

“Bill McKenzie” wrote in message news:xxxxx@ntdev…
> Curious to know how you did this. Without that non-exported module list
> lock, it seems pretty ugly anyway you try to go about it safely.
>
> Bill M.
>
>
> wrote in message news:xxxxx@ntdev…
> >

> >
> > Of course not.
> >
> > The lock is used to lock the loaded module list to find the base of the
> > kernel and hal export tables.
> >
> > You’re right, though, Maxim: It’s not hard to write your own version of
> > this DDI. That’s exactly what we at OSR decided to do on Friday.
> >
> > Peter
> >
> >
>
>
>

Maxim_S_Shatskih · June 5, 2007, 6:45pm

> According to the docs it works all the way down to Win95!

MmGetSystemRoutineAddress is w2k and later.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com

Bill_McKenzie-3 · June 5, 2007, 7:45pm

Bad kernel developer…no…lol

ZwQuerySystemInformation is not documented and as the docs say:

“ZwQuerySystemInformation may be altered or unavailable in subsequent
versions of Windows. Applications should use the alternate functions”

Thus why I used the word “safely”.

Bill M.

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
> ZwQuerySystemInformation to get the kernel base, then parse the PE
> format.
>
> –
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> “Bill McKenzie” wrote in message
> news:xxxxx@ntdev…
>> Curious to know how you did this. Without that non-exported module list
>> lock, it seems pretty ugly anyway you try to go about it safely.
>>
>> Bill M.
>>
>>
>> wrote in message news:xxxxx@ntdev…
>> >

>> >
>> > Of course not.
>> >
>> > The lock is used to lock the loaded module list to find the base of the
>> > kernel and hal export tables.
>> >
>> > You’re right, though, Maxim: It’s not hard to write your own version
>> > of
>> > this DDI. That’s exactly what we at OSR decided to do on Friday.
>> >
>> > Peter
>> >
>> >
>>
>>
>>
>
>

Maxim_S_Shatskih · June 5, 2007, 7:53pm

Works for me from NT4 to Vista in the same binary for all these OSes.

When MS will release the next OS, then I will possibly design the next way
of doing this.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

“Bill McKenzie” wrote in message news:xxxxx@ntdev…
> Bad kernel developer…no…lol
>
> ZwQuerySystemInformation is not documented and as the docs say:
>
> “ZwQuerySystemInformation may be altered or unavailable in subsequent
> versions of Windows. Applications should use the alternate functions”
>
> Thus why I used the word “safely”.
>
> Bill M.
>
> “Maxim S. Shatskih” wrote in message
> news:xxxxx@ntdev…
> > ZwQuerySystemInformation to get the kernel base, then parse the PE
> > format.
> >
> > –
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> > “Bill McKenzie” wrote in message
> > news:xxxxx@ntdev…
> >> Curious to know how you did this. Without that non-exported module list
> >> lock, it seems pretty ugly anyway you try to go about it safely.
> >>
> >> Bill M.
> >>
> >>
> >> wrote in message news:xxxxx@ntdev…
> >> >

> >> >
> >> > Of course not.
> >> >
> >> > The lock is used to lock the loaded module list to find the base of the
> >> > kernel and hal export tables.
> >> >
> >> > You’re right, though, Maxim: It’s not hard to write your own version
> >> > of
> >> > this DDI. That’s exactly what we at OSR decided to do on Friday.
> >> >
> >> > Peter
> >> >
> >> >
> >>
> >>
> >>
> >
> >
>
>
>

OSR_Community_User · June 5, 2007, 8:14pm

Maxim S. Shatskih wrote:

> According to the docs it works all the way down to Win95!

MmGetSystemRoutineAddress is w2k and later.

Well, that’s what Microsoft claims, not me. Actually it claims even more:

“This library works on all 32-bit and 64-bit editions of Windows.”

It seems there are multiple versions of the library. One version doesn’t use MmGetSystemRoutineAddress at all, guess it just calls ZwQuerySystemInformation. Probably this version is intended for “older” OSes where ZwQuerySystemInformation is known to work. What I don’t know is how you could make a single binary that would work in every OS. Guess it isn’t possible.

Bill_McKenzie-3 · June 5, 2007, 8:42pm

Well, AuxKlibQueryModuleInformation, as suggested by Doron & Bob, is
reported to work, haven’t tested it yet, down to at least 2000 and it is a
documented and suggested function for this purpose. But, to each their own.

Bill M.

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
> Works for me from NT4 to Vista in the same binary for all these OSes.
>
> When MS will release the next OS, then I will possibly design the next
> way
> of doing this.
>
> –
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> “Bill McKenzie” wrote in message
> news:xxxxx@ntdev…
>> Bad kernel developer…no…lol
>>
>> ZwQuerySystemInformation is not documented and as the docs say:
>>
>> “ZwQuerySystemInformation may be altered or unavailable in subsequent
>> versions of Windows. Applications should use the alternate functions”
>>
>> Thus why I used the word “safely”.
>>
>> Bill M.
>>
>> “Maxim S. Shatskih” wrote in message
>> news:xxxxx@ntdev…
>> > ZwQuerySystemInformation to get the kernel base, then parse the PE
>> > format.
>> >
>> > –
>> > Maxim Shatskih, Windows DDK MVP
>> > StorageCraft Corporation
>> > xxxxx@storagecraft.com
>> > http://www.storagecraft.com
>> >
>> > “Bill McKenzie” wrote in message
>> > news:xxxxx@ntdev…
>> >> Curious to know how you did this. Without that non-exported module
>> >> list
>> >> lock, it seems pretty ugly anyway you try to go about it safely.
>> >>
>> >> Bill M.
>> >>
>> >>
>> >> wrote in message news:xxxxx@ntdev…
>> >> >

>> >> >
>> >> > Of course not.
>> >> >
>> >> > The lock is used to lock the loaded module list to find the base of
>> >> > the
>> >> > kernel and hal export tables.
>> >> >
>> >> > You’re right, though, Maxim: It’s not hard to write your own
>> >> > version
>> >> > of
>> >> > this DDI. That’s exactly what we at OSR decided to do on Friday.
>> >> >
>> >> > Peter
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>>
>
>

OSR_Community_User · June 5, 2007, 10:34pm

> “This library works on all 32-bit and 64-bit editions of Windows.”

It seems the statement is misleading. There is an “User Mode” auxiliary library in addition to the kernel mode one. That Ms claim about universal compatibility probably refers to the user mode library only, not to the kernel mode one.

The two kernel libraries seem to be one for NT4, and the other for W2k and later. Still won’t allow for a single binary that would work in NT4 and later.

OSR_Community_User · June 6, 2007, 6:56am

NdisGetRoutineAddress() is not affected on XP SP2, right?

Looking at the ndis.sys, it does not seem to import MmGetSystemRoutineAddress, instead it imports
the RtlImageDirectoryEntryToData …

Regards,
–PA

OSR_Community_User · June 6, 2007, 4:27pm

Ok, nobody has asked this yet so I’ll take the dangerous leap.

Vista WHQL now requires submission of the PreFast output. PreFast puts
out a warning for the use of PsGetVersion. So in our drivers I was
thinking of (excuse the pseudo code):

if (pRtlGetVersion = MmGetSystemRoutineAddress (“RtlGetVersion”)) //
Yeah, I know, I gotta use UNICODE_STRINGS

else
if (pPsGetVersion = MmGetSystemRoutineAddress (“PsGetVersion”))

(We’d only be using this on 32-bit operating systems. All the 64-bit
systems support RtlGetVersion.)
(And we want a single binary to support Win 2k through Vista.)

1. Since both of these XxxGetVersion routines are not alphabetically
before any exports in either ntoskrnl or hal, this should not bug check,
so this should be OK. But it might be an overkill. So …

2. Will Microsoft accept a WHQL submission for a driver that uses the
obsolete PsGetVersion? I know, you can #pragma the warning, but Microsoft
might inspect my import table. I’d sure like to know the answer to this
before we go through a couple of weeks running the tests and submitting
them to find that we gotta recode, rebuild and run 'em over again.

Thanks,

Jerry.

Doron Holan
Sent by: xxxxx@lists.osr.com
06/04/2007 02:25 PM
Please respond to
“Windows System Software Devs Interest List”

To
“Windows System Software Devs Interest List”
cc

Subject
RE: [ntdev] RE:MmGetSystemRoutineAddress BugCheck?

That is exactly what I was trying to state as a solution, perhaps not as
clearly. Thanks for reiterating ;).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Monday, June 04, 2007 10:34 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] RE:MmGetSystemRoutineAddress BugCheck?

Alternatively, you could always check the OS version before calling
MmGetSystemRoutineAddress and circumvent the problem entirely. Call
PsGetVersion, if that reports XP or later, then you can link to
RtlGetVersion and use that for even service-pack-level granularity
before
making further MmGetSystemRoutineAddress calls.

I’d prefer that to relying on an SEH; seems rather more bulletproof than

swallowing foreign access violations…

–
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
I looked into this as soon as I first heard of it this morning (had to,
I
use this function a lot past and present). But I’d rather not be deemed

“official”, since I don’t own this part of the code. So I’ve been
waiting,
but I’ll offer this info as is.

It is fixed in Vista. It will be fixed in XP SP3. Couldn’t find
anything
about Server SP1. It was not accepted for XP SP2 because there wasn’t
sufficient justification (OCA /customer complaints, etc). Don’t shoot
the
messenger- everything I can see says it was proactively fixed when
internally identified, and the owner did his best to get it ported as
far
back as acceptable. Because of this, and the time I spent on those
efforts,
my guess would be that Server SP1 (and thus “64-bit XP”) has probably
got
the fix.

IMO, it won’t get fixed for Win2K, as that OS is unsupported.

FURTHERMORE:

* You need to be looking for a non-existent DDI name starting near the
front
of the ANSI sort order (basically alphabetical order) to hit this-
DbgPrintEx was the furthest in I saw any report of. Might be any name
before the first name in the HAL (but that’s a wild guess, and there’ve
been
too many of them already).

* It appears that you can readily use an exception handler to work
around
it.

—
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

Doron_Holan · June 6, 2007, 5:12pm

KMDF directly imports PsGetVersion to work on Win2k and then uses
MmGetSystemRoutineAddress to get RtlGetVersion for later platforms, I am
pretty sure you can do the same w/out issue.

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@attotech.com
Sent: Wednesday, June 06, 2007 1:26 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] MmGetSystemRoutineAddress BugCheck?

Ok, nobody has asked this yet so I’ll take the dangerous leap.

Vista WHQL now requires submission of the PreFast output. PreFast puts
out a warning for the use of PsGetVersion. So in our drivers I was
thinking of (excuse the pseudo code):

if (pRtlGetVersion = MmGetSystemRoutineAddress (“RtlGetVersion”)) //
Yeah, I know, I gotta use UNICODE_STRINGS

else
if (pPsGetVersion = MmGetSystemRoutineAddress (“PsGetVersion”))

(We’d only be using this on 32-bit operating systems. All the 64-bit
systems support RtlGetVersion.)
(And we want a single binary to support Win 2k through Vista.)

1. Since both of these XxxGetVersion routines are not alphabetically
before any exports in either ntoskrnl or hal, this should not bug check,
so this should be OK. But it might be an overkill. So …

2. Will Microsoft accept a WHQL submission for a driver that uses the
obsolete PsGetVersion? I know, you can #pragma the warning, but
Microsoft might inspect my import table. I’d sure like to know the
answer to this before we go through a couple of weeks running the tests
and submitting them to find that we gotta recode, rebuild and run 'em
over again.

Thanks,

Jerry.

Doron Holan
Sent by: xxxxx@lists.osr.com

06/04/2007 02:25 PM

Please respond to
“Windows System Software Devs Interest List”

To

“Windows System Software Devs Interest List”

cc

Subject

RE: [ntdev] RE:MmGetSystemRoutineAddress BugCheck?

That is exactly what I was trying to state as a solution, perhaps not as
clearly. Thanks for reiterating ;).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Monday, June 04, 2007 10:34 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] RE:MmGetSystemRoutineAddress BugCheck?

Alternatively, you could always check the OS version before calling
MmGetSystemRoutineAddress and circumvent the problem entirely. Call
PsGetVersion, if that reports XP or later, then you can link to
RtlGetVersion and use that for even service-pack-level granularity
before
making further MmGetSystemRoutineAddress calls.

I’d prefer that to relying on an SEH; seems rather more bulletproof than

swallowing foreign access violations…

–
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
I looked into this as soon as I first heard of it this morning (had to,
I
use this function a lot past and present). But I’d rather not be deemed

“official”, since I don’t own this part of the code. So I’ve been
waiting,
but I’ll offer this info as is.

It is fixed in Vista. It will be fixed in XP SP3. Couldn’t find
anything
about Server SP1. It was not accepted for XP SP2 because there wasn’t
sufficient justification (OCA /customer complaints, etc). Don’t shoot
the
messenger- everything I can see says it was proactively fixed when
internally identified, and the owner did his best to get it ported as
far
back as acceptable. Because of this, and the time I spent on those
efforts,
my guess would be that Server SP1 (and thus “64-bit XP”) has probably
got
the fix.

IMO, it won’t get fixed for Win2K, as that OS is unsupported.

FURTHERMORE:

* You need to be looking for a non-existent DDI name starting near the
front
of the ANSI sort order (basically alphabetical order) to hit this-
DbgPrintEx was the furthest in I saw any report of. Might be any name
before the first name in the HAL (but that’s a wild guess, and there’ve
been
too many of them already).

* It appears that you can readily use an exception handler to work
around
it.

—
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

Bill_McKenzie-3 · June 6, 2007, 6:32pm

Why was this changed btw? Did whoever changed it think of the implications. It seems a bad idea to change, from platform to platform, the routines used to determine the platform. It seems to me anyway??

Bill M.
“Doron Holan” wrote in message news:xxxxx@ntdev…
KMDF directly imports PsGetVersion to work on Win2k and then uses MmGetSystemRoutineAddress to get RtlGetVersion for later platforms, I am pretty sure you can do the same w/out issue.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@attotech.com
Sent: Wednesday, June 06, 2007 1:26 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] MmGetSystemRoutineAddress BugCheck?

Ok, nobody has asked this yet so I’ll take the dangerous leap.

Vista WHQL now requires submission of the PreFast output. PreFast puts out a warning for the use of PsGetVersion. So in our drivers I was thinking of (excuse the pseudo code):

if (pRtlGetVersion = MmGetSystemRoutineAddress (“RtlGetVersion”)) // Yeah, I know, I gotta use UNICODE_STRINGS

else
if (pPsGetVersion = MmGetSystemRoutineAddress (“PsGetVersion”))

(We’d only be using this on 32-bit operating systems. All the 64-bit systems support RtlGetVersion.)
(And we want a single binary to support Win 2k through Vista.)

1. Since both of these XxxGetVersion routines are not alphabetically before any exports in either ntoskrnl or hal, this should not bug check, so this should be OK. But it might be an overkill. So …

2. Will Microsoft accept a WHQL submission for a driver that uses the obsolete PsGetVersion? I know, you can #pragma the warning, but Microsoft might inspect my import table. I’d sure like to know the answer to this before we go through a couple of weeks running the tests and submitting them to find that we gotta recode, rebuild and run 'em over again.

Thanks,

Jerry.

Doron Holan
Sent by: xxxxx@lists.osr.com

06/04/2007 02:25 PM

Please respond to
“Windows System Software Devs Interest List”

To
“Windows System Software Devs Interest List”

cc

Subject
RE: [ntdev] RE:MmGetSystemRoutineAddress BugCheck?

That is exactly what I was trying to state as a solution, perhaps not as
clearly. Thanks for reiterating ;).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Monday, June 04, 2007 10:34 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] RE:MmGetSystemRoutineAddress BugCheck?

Alternatively, you could always check the OS version before calling
MmGetSystemRoutineAddress and circumvent the problem entirely. Call
PsGetVersion, if that reports XP or later, then you can link to
RtlGetVersion and use that for even service-pack-level granularity
before
making further MmGetSystemRoutineAddress calls.

I’d prefer that to relying on an SEH; seems rather more bulletproof than

swallowing foreign access violations…

–
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
I looked into this as soon as I first heard of it this morning (had to,
I
use this function a lot past and present). But I’d rather not be deemed

“official”, since I don’t own this part of the code. So I’ve been
waiting,
but I’ll offer this info as is.

It is fixed in Vista. It will be fixed in XP SP3. Couldn’t find
anything
about Server SP1. It was not accepted for XP SP2 because there wasn’t
sufficient justification (OCA /customer complaints, etc). Don’t shoot
the
messenger- everything I can see says it was proactively fixed when
internally identified, and the owner did his best to get it ported as
far
back as acceptable. Because of this, and the time I spent on those
efforts,
my guess would be that Server SP1 (and thus “64-bit XP”) has probably
got
the fix.

IMO, it won’t get fixed for Win2K, as that OS is unsupported.

FURTHERMORE:

* You need to be looking for a non-existent DDI name starting near the
front
of the ANSI sort order (basically alphabetical order) to hit this-
DbgPrintEx was the furthest in I saw any report of. Might be any name
before the first name in the HAL (but that’s a wild guess, and there’ve
been
too many of them already).

* It appears that you can readily use an exception handler to work
around
it.

—
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

Doron_Holan · June 6, 2007, 6:44pm

Are you asking why RtlGetVersion was introduced? It reports more
information and is the same as the UM version (GetVersion(Ex)).

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Wednesday, June 06, 2007 3:32 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] MmGetSystemRoutineAddress BugCheck?

Why was this changed btw? Did whoever changed it think of the
implications. It seems a bad idea to change, from platform to platform,
the routines used to determine the platform. It seems to me anyway??

Bill M.

“Doron Holan” wrote in message
news:xxxxx@ntdev…

KMDF directly imports PsGetVersion to work on Win2k and then
uses MmGetSystemRoutineAddress to get RtlGetVersion for later platforms,
I am pretty sure you can do the same w/out issue.

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@attotech.com
Sent: Wednesday, June 06, 2007 1:26 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] MmGetSystemRoutineAddress BugCheck?

Ok, nobody has asked this yet so I’ll take the dangerous leap.

Vista WHQL now requires submission of the PreFast output.
PreFast puts out a warning for the use of PsGetVersion. So in our
drivers I was thinking of (excuse the pseudo code):

if (pRtlGetVersion = MmGetSystemRoutineAddress
(“RtlGetVersion”)) // Yeah, I know, I gotta use UNICODE_STRINGS

else
if (pPsGetVersion = MmGetSystemRoutineAddress (“PsGetVersion”))

(We’d only be using this on 32-bit operating systems. All the
64-bit systems support RtlGetVersion.)
(And we want a single binary to support Win 2k through Vista.)

1. Since both of these XxxGetVersion routines are not
alphabetically before any exports in either ntoskrnl or hal, this should
not bug check, so this should be OK. But it might be an overkill. So
…

2. Will Microsoft accept a WHQL submission for a driver that
uses the obsolete PsGetVersion? I know, you can #pragma the warning,
but Microsoft might inspect my import table. I’d sure like to know the
answer to this before we go through a couple of weeks running the tests
and submitting them to find that we gotta recode, rebuild and run 'em
over again.

Thanks,

Jerry.

Doron Holan
Sent by: xxxxx@lists.osr.com

06/04/2007 02:25 PM

Please respond to
“Windows System Software Devs Interest List”

To

“Windows System Software Devs Interest List”

cc

Subject

RE: [ntdev] RE:MmGetSystemRoutineAddress BugCheck?

That is exactly what I was trying to state as a solution,
perhaps not as
clearly. Thanks for reiterating ;).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Monday, June 04, 2007 10:34 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] RE:MmGetSystemRoutineAddress BugCheck?

Alternatively, you could always check the OS version before
calling
MmGetSystemRoutineAddress and circumvent the problem entirely.
Call
PsGetVersion, if that reports XP or later, then you can link to
RtlGetVersion and use that for even service-pack-level
granularity
before
making further MmGetSystemRoutineAddress calls.

I’d prefer that to relying on an SEH; seems rather more
bulletproof than

swallowing foreign access violations…

–
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
I looked into this as soon as I first heard of it this morning
(had to,
I
use this function a lot past and present). But I’d rather not
be deemed

“official”, since I don’t own this part of the code. So I’ve
been
waiting,
but I’ll offer this info as is.

It is fixed in Vista. It will be fixed in XP SP3. Couldn’t
find
anything
about Server SP1. It was not accepted for XP SP2 because there
wasn’t
sufficient justification (OCA /customer complaints, etc). Don’t
shoot
the
messenger- everything I can see says it was proactively fixed
when
internally identified, and the owner did his best to get it
ported as
far
back as acceptable. Because of this, and the time I spent on
those
efforts,
my guess would be that Server SP1 (and thus “64-bit XP”) has
probably
got
the fix.

IMO, it won’t get fixed for Win2K, as that OS is unsupported.

FURTHERMORE:

* You need to be looking for a non-existent DDI name starting
near the
front
of the ANSI sort order (basically alphabetical order) to hit
this-
DbgPrintEx was the furthest in I saw any report of. Might be
any name
before the first name in the HAL (but that’s a wild guess, and
there’ve
been
too many of them already).

* It appears that you can readily use an exception handler to
work
around
it.

—
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

OSR_Community_User · June 6, 2007, 6:59pm

Yeah, but … why obsolete the older function?
I don’t care as long as I can still get my drivers certified using the old
one. The PreFast warning just scared us.
Thanks,
Jerry.

Doron Holan
Sent by: xxxxx@lists.osr.com
06/06/2007 06:45 PM
Please respond to
“Windows System Software Devs Interest List”

To
“Windows System Software Devs Interest List”
cc

Subject
RE: [ntdev] MmGetSystemRoutineAddress BugCheck?

Are you asking why RtlGetVersion was introduced? It reports more
information and is the same as the UM version (GetVersion(Ex)).

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Wednesday, June 06, 2007 3:32 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] MmGetSystemRoutineAddress BugCheck?

Why was this changed btw? Did whoever changed it think of the
implications. It seems a bad idea to change, from platform to platform,
the routines used to determine the platform. It seems to me anyway??

Bill M.
“Doron Holan” wrote in message
news:xxxxx@ntdev…
KMDF directly imports PsGetVersion to work on Win2k and then uses
MmGetSystemRoutineAddress to get RtlGetVersion for later platforms, I am
pretty sure you can do the same w/out issue.

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@attotech.com
Sent: Wednesday, June 06, 2007 1:26 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] MmGetSystemRoutineAddress BugCheck?

Ok, nobody has asked this yet so I’ll take the dangerous leap.

Vista WHQL now requires submission of the PreFast output. PreFast puts
out a warning for the use of PsGetVersion. So in our drivers I was
thinking of (excuse the pseudo code):

if (pRtlGetVersion = MmGetSystemRoutineAddress (“RtlGetVersion”)) //
Yeah, I know, I gotta use UNICODE_STRINGS

else
if (pPsGetVersion = MmGetSystemRoutineAddress (“PsGetVersion”))

(We’d only be using this on 32-bit operating systems. All the 64-bit
systems support RtlGetVersion.)
(And we want a single binary to support Win 2k through Vista.)

1. Since both of these XxxGetVersion routines are not alphabetically
before any exports in either ntoskrnl or hal, this should not bug check,
so this should be OK. But it might be an overkill. So …

2. Will Microsoft accept a WHQL submission for a driver that uses the
obsolete PsGetVersion? I know, you can #pragma the warning, but Microsoft
might inspect my import table. I’d sure like to know the answer to this
before we go through a couple of weeks running the tests and submitting
them to find that we gotta recode, rebuild and run 'em over again.

Thanks,

Jerry.

Doron Holan
Sent by: xxxxx@lists.osr.com
06/04/2007 02:25 PM

Please respond to
“Windows System Software Devs Interest List”

To
“Windows System Software Devs Interest List”
cc

Subject
RE: [ntdev] RE:MmGetSystemRoutineAddress BugCheck?

That is exactly what I was trying to state as a solution, perhaps not as
clearly. Thanks for reiterating ;).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Monday, June 04, 2007 10:34 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] RE:MmGetSystemRoutineAddress BugCheck?

Alternatively, you could always check the OS version before calling
MmGetSystemRoutineAddress and circumvent the problem entirely. Call
PsGetVersion, if that reports XP or later, then you can link to
RtlGetVersion and use that for even service-pack-level granularity
before
making further MmGetSystemRoutineAddress calls.

I’d prefer that to relying on an SEH; seems rather more bulletproof than

swallowing foreign access violations…

–
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
I looked into this as soon as I first heard of it this morning (had to,
I
use this function a lot past and present). But I’d rather not be deemed

“official”, since I don’t own this part of the code. So I’ve been
waiting,
but I’ll offer this info as is.

It is fixed in Vista. It will be fixed in XP SP3. Couldn’t find
anything
about Server SP1. It was not accepted for XP SP2 because there wasn’t
sufficient justification (OCA /customer complaints, etc). Don’t shoot
the
messenger- everything I can see says it was proactively fixed when
internally identified, and the owner did his best to get it ported as
far
back as acceptable. Because of this, and the time I spent on those
efforts,
my guess would be that Server SP1 (and thus “64-bit XP”) has probably
got
the fix.

IMO, it won’t get fixed for Win2K, as that OS is unsupported.

FURTHERMORE:

* You need to be looking for a non-existent DDI name starting near the
front
of the ANSI sort order (basically alphabetical order) to hit this-
DbgPrintEx was the furthest in I saw any report of. Might be any name
before the first name in the HAL (but that’s a wild guess, and there’ve
been
too many of them already).

* It appears that you can readily use an exception handler to work
around
it.

—
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

—
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

Mark_Roddy · June 6, 2007, 8:53pm

I’m okay with having a new improved PsGetVersionEx, but not with obsolescing
the existing PsGetVersion while the platforms that only provide that version
are still out there, especially in light of this discussion.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Wednesday, June 06, 2007 6:32 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] MmGetSystemRoutineAddress BugCheck?

Why was this changed btw? Did whoever changed it think of the implications.
It seems a bad idea to change, from platform to platform, the routines used
to determine the platform. It seems to me anyway??

Bill M.

“Doron Holan” wrote in message
news:xxxxx@ntdev…

KMDF directly imports PsGetVersion to work on Win2k and then uses
MmGetSystemRoutineAddress to get RtlGetVersion for later platforms, I am
pretty sure you can do the same w/out issue.

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@attotech.com
Sent: Wednesday, June 06, 2007 1:26 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] MmGetSystemRoutineAddress BugCheck?

Ok, nobody has asked this yet so I’ll take the dangerous leap.

Vista WHQL now requires submission of the PreFast output. PreFast puts out
a warning for the use of PsGetVersion. So in our drivers I was thinking of
(excuse the pseudo code):

if (pRtlGetVersion = MmGetSystemRoutineAddress (“RtlGetVersion”)) // Yeah,
I know, I gotta use UNICODE_STRINGS

else
if (pPsGetVersion = MmGetSystemRoutineAddress (“PsGetVersion”))

(We’d only be using this on 32-bit operating systems. All the 64-bit
systems support RtlGetVersion.)
(And we want a single binary to support Win 2k through Vista.)

1. Since both of these XxxGetVersion routines are not alphabetically before
any exports in either ntoskrnl or hal, this should not bug check, so this
should be OK. But it might be an overkill. So …

2. Will Microsoft accept a WHQL submission for a driver that uses the
obsolete PsGetVersion? I know, you can #pragma the warning, but Microsoft
might inspect my import table. I’d sure like to know the answer to this
before we go through a couple of weeks running the tests and submitting them
to find that we gotta recode, rebuild and run 'em over again.

Thanks,

Jerry.

Doron Holan
Sent by: xxxxx@lists.osr.com

06/04/2007 02:25 PM

Please respond to
“Windows System Software Devs Interest List”

To

“Windows System Software Devs Interest List”

cc

Subject

RE: [ntdev] RE:MmGetSystemRoutineAddress BugCheck?

That is exactly what I was trying to state as a solution, perhaps not as
clearly. Thanks for reiterating ;).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Monday, June 04, 2007 10:34 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] RE:MmGetSystemRoutineAddress BugCheck?

Alternatively, you could always check the OS version before calling
MmGetSystemRoutineAddress and circumvent the problem entirely. Call
PsGetVersion, if that reports XP or later, then you can link to
RtlGetVersion and use that for even service-pack-level granularity
before
making further MmGetSystemRoutineAddress calls.

I’d prefer that to relying on an SEH; seems rather more bulletproof than

swallowing foreign access violations…

–
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
I looked into this as soon as I first heard of it this morning (had to,
I
use this function a lot past and present). But I’d rather not be deemed

“official”, since I don’t own this part of the code. So I’ve been
waiting,
but I’ll offer this info as is.

It is fixed in Vista. It will be fixed in XP SP3. Couldn’t find
anything
about Server SP1. It was not accepted for XP SP2 because there wasn’t
sufficient justification (OCA /customer complaints, etc). Don’t shoot
the
messenger- everything I can see says it was proactively fixed when
internally identified, and the owner did his best to get it ported as
far
back as acceptable. Because of this, and the time I spent on those
efforts,
my guess would be that Server SP1 (and thus “64-bit XP”) has probably
got
the fix.

IMO, it won’t get fixed for Win2K, as that OS is unsupported.

FURTHERMORE:

* You need to be looking for a non-existent DDI name starting near the
front
of the ANSI sort order (basically alphabetical order) to hit this-
DbgPrintEx was the furthest in I saw any report of. Might be any name
before the first name in the HAL (but that’s a wild guess, and there’ve
been
too many of them already).

* It appears that you can readily use an exception handler to work
around
it.

—
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

Bill_McKenzie-3 · June 6, 2007, 11:36pm

Yes…what he said…ditto.

Bill M.
“Mark Roddy” wrote in message news:xxxxx@ntdev…
I’m okay with having a new improved PsGetVersionEx, but not with obsolescing the existing PsGetVersion while the platforms that only provide that version are still out there, especially in light of this discussion.

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Wednesday, June 06, 2007 6:32 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] MmGetSystemRoutineAddress BugCheck?

Why was this changed btw? Did whoever changed it think of the implications. It seems a bad idea to change, from platform to platform, the routines used to determine the platform. It seems to me anyway??

Bill M.

“Doron Holan” wrote in message news:xxxxx@ntdev…

KMDF directly imports PsGetVersion to work on Win2k and then uses MmGetSystemRoutineAddress to get RtlGetVersion for later platforms, I am pretty sure you can do the same w/out issue.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@attotech.com
Sent: Wednesday, June 06, 2007 1:26 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] MmGetSystemRoutineAddress BugCheck?

Ok, nobody has asked this yet so I’ll take the dangerous leap.

Vista WHQL now requires submission of the PreFast output. PreFast puts out a warning for the use of PsGetVersion. So in our drivers I was thinking of (excuse the pseudo code):

if (pRtlGetVersion = MmGetSystemRoutineAddress (“RtlGetVersion”)) // Yeah, I know, I gotta use UNICODE_STRINGS

else
if (pPsGetVersion = MmGetSystemRoutineAddress (“PsGetVersion”))

(We’d only be using this on 32-bit operating systems. All the 64-bit systems support RtlGetVersion.)
(And we want a single binary to support Win 2k through Vista.)

1. Since both of these XxxGetVersion routines are not alphabetically before any exports in either ntoskrnl or hal, this should not bug check, so this should be OK. But it might be an overkill. So …

2. Will Microsoft accept a WHQL submission for a driver that uses the obsolete PsGetVersion? I know, you can #pragma the warning, but Microsoft might inspect my import table. I’d sure like to know the answer to this before we go through a couple of weeks running the tests and submitting them to find that we gotta recode, rebuild and run 'em over again.

Thanks,

Jerry.

Doron Holan
Sent by: xxxxx@lists.osr.com

06/04/2007 02:25 PM

Please respond to
“Windows System Software Devs Interest List”

To
“Windows System Software Devs Interest List”

cc

Subject
RE: [ntdev] RE:MmGetSystemRoutineAddress BugCheck?

That is exactly what I was trying to state as a solution, perhaps not as
clearly. Thanks for reiterating ;).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Monday, June 04, 2007 10:34 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] RE:MmGetSystemRoutineAddress BugCheck?

Alternatively, you could always check the OS version before calling
MmGetSystemRoutineAddress and circumvent the problem entirely. Call
PsGetVersion, if that reports XP or later, then you can link to
RtlGetVersion and use that for even service-pack-level granularity
before
making further MmGetSystemRoutineAddress calls.

I’d prefer that to relying on an SEH; seems rather more bulletproof than

swallowing foreign access violations…

–
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
I looked into this as soon as I first heard of it this morning (had to,
I
use this function a lot past and present). But I’d rather not be deemed

“official”, since I don’t own this part of the code. So I’ve been
waiting,
but I’ll offer this info as is.

It is fixed in Vista. It will be fixed in XP SP3. Couldn’t find
anything
about Server SP1. It was not accepted for XP SP2 because there wasn’t
sufficient justification (OCA /customer complaints, etc). Don’t shoot
the
messenger- everything I can see says it was proactively fixed when
internally identified, and the owner did his best to get it ported as
far
back as acceptable. Because of this, and the time I spent on those
efforts,
my guess would be that Server SP1 (and thus “64-bit XP”) has probably
got
the fix.

IMO, it won’t get fixed for Win2K, as that OS is unsupported.

FURTHERMORE:

* You need to be looking for a non-existent DDI name starting near the
front
of the ANSI sort order (basically alphabetical order) to hit this-
DbgPrintEx was the furthest in I saw any report of. Might be any name
before the first name in the HAL (but that’s a wild guess, and there’ve
been
too many of them already).

* It appears that you can readily use an exception handler to work
around
it.

—
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

Doron_Holan · June 7, 2007, 12:15am

We pushed back on the warning for PsGetVersion, we get warned too ;).
The idea is to encourage those driver writers who do not target win2k to
use the newer API, PFD has no way of knowing what the minimum targeted
OS is to turn off warnings selectively…

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Wednesday, June 06, 2007 8:36 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] MmGetSystemRoutineAddress BugCheck?

Yes…what he said…ditto.

Bill M.

“Mark Roddy” wrote in message
news:xxxxx@ntdev…

I’m okay with having a new improved PsGetVersionEx, but not with
obsolescing the existing PsGetVersion while the platforms that only
provide that version are still out there, especially in light of this
discussion.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Wednesday, June 06, 2007 6:32 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] MmGetSystemRoutineAddress BugCheck?

Why was this changed btw? Did whoever changed it think of the
implications. It seems a bad idea to change, from platform to platform,
the routines used to determine the platform. It seems to me anyway??

Bill M.

“Doron Holan” wrote in
message news:xxxxx@ntdev…

KMDF directly imports PsGetVersion to work on Win2k and
then uses MmGetSystemRoutineAddress to get RtlGetVersion for later
platforms, I am pretty sure you can do the same w/out issue.

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@attotech.com
Sent: Wednesday, June 06, 2007 1:26 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] MmGetSystemRoutineAddress BugCheck?

Ok, nobody has asked this yet so I’ll take the dangerous
leap.

Vista WHQL now requires submission of the PreFast
output. PreFast puts out a warning for the use of PsGetVersion. So in
our drivers I was thinking of (excuse the pseudo code):

if (pRtlGetVersion = MmGetSystemRoutineAddress
(“RtlGetVersion”)) // Yeah, I know, I gotta use UNICODE_STRINGS

else
if (pPsGetVersion = MmGetSystemRoutineAddress
(“PsGetVersion”))

(We’d only be using this on 32-bit operating systems.
All the 64-bit systems support RtlGetVersion.)
(And we want a single binary to support Win 2k through
Vista.)

1. Since both of these XxxGetVersion routines are not
alphabetically before any exports in either ntoskrnl or hal, this should
not bug check, so this should be OK. But it might be an overkill. So
…

2. Will Microsoft accept a WHQL submission for a driver
that uses the obsolete PsGetVersion? I know, you can #pragma the
warning, but Microsoft might inspect my import table. I’d sure like to
know the answer to this before we go through a couple of weeks running
the tests and submitting them to find that we gotta recode, rebuild and
run 'em over again.

Thanks,

Jerry.

Doron Holan
Sent by: xxxxx@lists.osr.com

06/04/2007 02:25 PM

Please respond to
“Windows System Software Devs Interest List”

To

“Windows System Software Devs Interest List”

cc

Subject

RE: [ntdev] RE:MmGetSystemRoutineAddress BugCheck?

That is exactly what I was trying to state as a
solution, perhaps not as
clearly. Thanks for reiterating ;).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
Skywing
Sent: Monday, June 04, 2007 10:34 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] RE:MmGetSystemRoutineAddress
BugCheck?

Alternatively, you could always check the OS version
before calling
MmGetSystemRoutineAddress and circumvent the problem
entirely. Call
PsGetVersion, if that reports XP or later, then you can
link to
RtlGetVersion and use that for even service-pack-level
granularity
before
making further MmGetSystemRoutineAddress calls.

I’d prefer that to relying on an SEH; seems rather more
bulletproof than

swallowing foreign access violations…

–
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
“Bob Kjelgaard” wrote in
message
news:xxxxx@ntdev…
I looked into this as soon as I first heard of it this
morning (had to,
I
use this function a lot past and present). But I’d
rather not be deemed

“official”, since I don’t own this part of the code. So
I’ve been
waiting,
but I’ll offer this info as is.

It is fixed in Vista. It will be fixed in XP SP3.
Couldn’t find
anything
about Server SP1. It was not accepted for XP SP2
because there wasn’t
sufficient justification (OCA /customer complaints,
etc). Don’t shoot
the
messenger- everything I can see says it was proactively
fixed when
internally identified, and the owner did his best to get
it ported as
far
back as acceptable. Because of this, and the time I
spent on those
efforts,
my guess would be that Server SP1 (and thus “64-bit XP”)
has probably
got
the fix.

IMO, it won’t get fixed for Win2K, as that OS is
unsupported.

FURTHERMORE:

* You need to be looking for a non-existent DDI name
starting near the
front
of the ANSI sort order (basically alphabetical order) to
hit this-
DbgPrintEx was the furthest in I saw any report of.
Might be any name
before the first name in the HAL (but that’s a wild
guess, and there’ve
been
too many of them already).

* It appears that you can readily use an exception
handler to work
around
it.

—
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

—
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

Bill_McKenzie-3 · June 7, 2007, 10:03am

Well, that is part of the problem. Why does it matter if I don’t want the new functionality and just want to use PsGetVersion? It works and has worked for a good long time. Is there something wrong with using that function on Vista? I want to use that function because I know it works everywhere and I don’t have to worry about what my driver is targeting or what it might target tomorrow. I just don’t understand, unless there is a technical problem, why a function like that would ever be obsoleted.

Bill M.
“Doron Holan” wrote in message news:xxxxx@ntdev…
We pushed back on the warning for PsGetVersion, we get warned too ;). The idea is to encourage those driver writers who do not target win2k to use the newer API, PFD has no way of knowing what the minimum targeted OS is to turn off warnings selectively.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Wednesday, June 06, 2007 8:36 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] MmGetSystemRoutineAddress BugCheck?

Yes…what he said…ditto.

Bill M.

“Mark Roddy” wrote in message news:xxxxx@ntdev…

I’m okay with having a new improved PsGetVersionEx, but not with obsolescing the existing PsGetVersion while the platforms that only provide that version are still out there, especially in light of this discussion.

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Wednesday, June 06, 2007 6:32 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] MmGetSystemRoutineAddress BugCheck?

Why was this changed btw? Did whoever changed it think of the implications. It seems a bad idea to change, from platform to platform, the routines used to determine the platform. It seems to me anyway??

Bill M.

“Doron Holan” wrote in message news:xxxxx@ntdev…

KMDF directly imports PsGetVersion to work on Win2k and then uses MmGetSystemRoutineAddress to get RtlGetVersion for later platforms, I am pretty sure you can do the same w/out issue.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@attotech.com
Sent: Wednesday, June 06, 2007 1:26 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] MmGetSystemRoutineAddress BugCheck?

Ok, nobody has asked this yet so I’ll take the dangerous leap.

Vista WHQL now requires submission of the PreFast output. PreFast puts out a warning for the use of PsGetVersion. So in our drivers I was thinking of (excuse the pseudo code):

if (pRtlGetVersion = MmGetSystemRoutineAddress (“RtlGetVersion”)) // Yeah, I know, I gotta use UNICODE_STRINGS

else
if (pPsGetVersion = MmGetSystemRoutineAddress (“PsGetVersion”))

(We’d only be using this on 32-bit operating systems. All the 64-bit systems support RtlGetVersion.)
(And we want a single binary to support Win 2k through Vista.)

1. Since both of these XxxGetVersion routines are not alphabetically before any exports in either ntoskrnl or hal, this should not bug check, so this should be OK. But it might be an overkill. So …

2. Will Microsoft accept a WHQL submission for a driver that uses the obsolete PsGetVersion? I know, you can #pragma the warning, but Microsoft might inspect my import table. I’d sure like to know the answer to this before we go through a couple of weeks running the tests and submitting them to find that we gotta recode, rebuild and run 'em over again.

Thanks,

Jerry.

Doron Holan
Sent by: xxxxx@lists.osr.com

06/04/2007 02:25 PM

Please respond to
“Windows System Software Devs Interest List”

To
“Windows System Software Devs Interest List”

cc

Subject
RE: [ntdev] RE:MmGetSystemRoutineAddress BugCheck?

That is exactly what I was trying to state as a solution, perhaps not as
clearly. Thanks for reiterating ;).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Monday, June 04, 2007 10:34 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] RE:MmGetSystemRoutineAddress BugCheck?

Alternatively, you could always check the OS version before calling
MmGetSystemRoutineAddress and circumvent the problem entirely. Call
PsGetVersion, if that reports XP or later, then you can link to
RtlGetVersion and use that for even service-pack-level granularity
before
making further MmGetSystemRoutineAddress calls.

I’d prefer that to relying on an SEH; seems rather more bulletproof than

swallowing foreign access violations…

–
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
I looked into this as soon as I first heard of it this morning (had to,
I
use this function a lot past and present). But I’d rather not be deemed

“official”, since I don’t own this part of the code. So I’ve been
waiting,
but I’ll offer this info as is.

It is fixed in Vista. It will be fixed in XP SP3. Couldn’t find
anything
about Server SP1. It was not accepted for XP SP2 because there wasn’t
sufficient justification (OCA /customer complaints, etc). Don’t shoot
the
messenger- everything I can see says it was proactively fixed when
internally identified, and the owner did his best to get it ported as
far
back as acceptable. Because of this, and the time I spent on those
efforts,
my guess would be that Server SP1 (and thus “64-bit XP”) has probably
got
the fix.

IMO, it won’t get fixed for Win2K, as that OS is unsupported.

FURTHERMORE:

* You need to be looking for a non-existent DDI name starting near the
front
of the ANSI sort order (basically alphabetical order) to hit this-
DbgPrintEx was the furthest in I saw any report of. Might be any name
before the first name in the HAL (but that’s a wild guess, and there’ve
been
too many of them already).

* It appears that you can readily use an exception handler to work
around
it.

—
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

—
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