MmGetSystemRoutineAddress BugCheck?

NTDEV
21

I confirmed with landy that this is the same issue. Definitely fixed in
vista, definitely a bug in xpsp2 without a QFE. Working on determining
if a QFE already exists, and if not, getting one spun up. I will ask to
see what server OS this was addressed on as well.

Thx
d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Thursday, May 31, 2007 11:12 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MmGetSystemRoutineAddress BugCheck?

It’s certainly a legit bug. Bill’s case is about as clear and isolated
as one could hope for. AND, by inspection, the code appears to be fixed
in Vista (also see the previously cited post by Konstantin at
http://www.osronline.com/showThread.cfm?link=101536).

Can we PLEASE hear from a Softie what OS versions this bug appears in
and if this problem is scheduled to be fixed in a SP or HF??

Peter
(in the meantime, I think I’ll pass this along to Hector to write a memo
about)

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

22

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.

23

Bob Kjelgaard wrote:

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).

This is a fascinating glimpse into the inner workings of Microsoft. I
say this without making any value judgments whatsoever. I simply think
it is revealing that the “powers that be” would make the decision to
ship with a proven bug when a fix was available, because the customer
complaints didn’t justify the testing effort, even though the fix was
likely to be well contained and perhaps even provably correct.

It just demonstrates how many times Microsoft has been burned by having
a simple fix break two more things.

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

24

This is interesting. I certainly was wrong.

mm

>> xxxxx@sbcglobal.net 2007-05-31 09:40 >>>

Don’t post a link or anything :slight_smile:

Apparently this bug has been around a while:

http://www.osronline.com/showThread.cfm?link=56329

Interesting!! If this is legit that makes this function pretty
useless.
YIKES!!

I have always avoided this function because I guess working in NDIS I
got
trained away from it. But geeze a LOT of drivers use this call on
platforms
where it could fail. I wonder if these bugchecks would contribute
evidence
of bad 3rd party drivers? :slight_smile:

Bill M.

“Daniel Terhell” wrote in message
news:xxxxx@ntdev…
> On 32 bit XP SP2 it just blue screens. Search this list and you can
find
> somebody who has explained exactly why with bug check and everything,

> there is a bug when it does a binary search for a routine address.
This
> bug got fixed in a hotfix or so somewhere along the way, it does not
blue
> screen with the latest windows updates installed. On 64 bit
SP2/Windows
> Server 2003 x64edition, there is another problem that it returns just
NULL
> for many valid exported kernel functions.
>
> /Daniel
>
>
>
> “Bill McKenzie” wrote in message
> news:xxxxx@ntdev…
>> Am I crazy, or is MmGetSystemRoutineAddress supposed to return NULL
when
>> it does not find the requested system routine name and NOT blue
screen?
>> On XP SP2, looking for CmRegisterCallbackEx using
>> MmGetSystemRoutineAddress it blue screens everytime. Change the
>> requested system routine name to CmRegisterCallback and no problem.
>>
>> This is a bug no? Makes MmGetSystemRoutineAddress rather useless or

>> actually harmful.
>>
>> Bill M.
>>
>>
>
>

—
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

25

Thank you, both Bob and Doron, for taking the time to follow-up and let us know what’s up. I know that it’s not your job to do this, either of you, and we all certainly appreciate it greatly.

Peter
OSR

26

Well, to be fair, timing was also probably an issue. Eventually the question as “the powers” see it looks more like “are we going to delay shipping fixes we know work and we know people want [even need] so that we can take one that nobody wants or seems to have a problem with?”. That’s why I suspect the server product (which was a few months later) would have it- still some “bake time” available, so more flexibility in accepting changes. We had similar choices to make in audio [I can’t recall the details now, though- nothing as serious as this, probably].

It’s one reason why problem reports and “send this report to Microsoft” are needed, even though they can seem to be a waste [and I’ve been as critical of the company in that respect as anyone here- I can remember one time a few years back when I realized I had loudly ranted about Microsoft’s customer attitude and was drawing dirty glances from the entire restaurant where I was having lunch with a colleague. I’m also sure I said at the time I’d never work here again. Not terribly prescient- but seriously, my experience has been different this time around…].

My own take as a QA guy is ‘why didn’t someone test it with “Aaa” or something of the sort to begin with?’. IMO, that should have been part of a unit test (hence a dev responsibility, although QA still has to cover if it isn’t there). But that’s mostly an object lesson for us to remember for the next test plan and the next feature, because again- I don’t own this issue…

I suspect someone somewhere has spent at least a bit of time beating themselves up [or wondering about a predecessor, as the case may be] over it {I sure would have].

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, May 31, 2007 12:30 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] MmGetSystemRoutineAddress BugCheck?

Bob Kjelgaard wrote:

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).

This is a fascinating glimpse into the inner workings of Microsoft. I
say this without making any value judgments whatsoever. I simply think
it is revealing that the “powers that be” would make the decision to
ship with a proven bug when a fix was available, because the customer
complaints didn’t justify the testing effort, even though the fix was
likely to be well contained and perhaps even provably correct.

It just demonstrates how many times Microsoft has been burned by having
a simple fix break two more things.

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

27

You obviously haven’t found bugs in the MSFT 1394 bus drivers very often :slight_smile:
They ship LOTS of proven bugs with known simple fixes.

Bill M.

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Bob Kjelgaard wrote:
>> 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).
>
> This is a fascinating glimpse into the inner workings of Microsoft. I
> say this without making any value judgments whatsoever. I simply think
> it is revealing that the “powers that be” would make the decision to
> ship with a proven bug when a fix was available, because the customer
> complaints didn’t justify the testing effort, even though the fix was
> likely to be well contained and perhaps even provably correct.
>
> It just demonstrates how many times Microsoft has been burned by having
> a simple fix break two more things.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

28

Ditto…thanks a lot for the info and confirmation!!

Bill M.

wrote in message news:xxxxx@ntdev…
> Thank you, both Bob and Doron, for taking the time to follow-up and let us
> know what’s up. I know that it’s not your job to do this, either of you,
> and we all certainly appreciate it greatly.
>
> Peter
> OSR
>
>

29

To confirm RobertKj’s guess, this bug DOES appear to be fixed in S03 SP1.

So the bug is in XP SP2, is fixed in S03 SP1 and later, and is slated for XP SP3.

The work-around is to always call MmGetSystemRoutineAddress from within a try/except block. If you get the exception, I guess you can assume the routine you’re seeking isn’t there…

Peter

30

FYI, using SEH to recover from this bug is *NOT* recommended. SEH is
not a formal contract for this API and as such, we (MSFT) cannot
guarantee that the OS is still in a stable state after you have caught
the exception. I am working on a better solution, but for now, SEH is
not the answer.

Thx
d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Thursday, May 31, 2007 1:29 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MmGetSystemRoutineAddress BugCheck?

Thank you, both Bob and Doron, for taking the time to follow-up and let
us know what’s up. I know that it’s not your job to do this, either of
you, and we all certainly appreciate it greatly.

Peter
OSR

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

31

Sorry… did I read that right?

try/except isn’t the ULTIMATE anwer? OK, I get that, thank you.

But as of today our options are:

a) BSOD the machine
b) try/except which MIGHT NOT BSOD the machine

…and we should take option A?

Surely I’m missing something,

Peter

32

From the description of the problem it would seem to say that you’re fine as long as you ask for a DDI which comes alphabetically after “CmZ”.

In the cases where you are asking for a CM function, could you use RtlIsNtDdiVersionAvailable and or RtlIsServicePackVersionAvailable to figure out if there’s a chance in hell the call would succeed and then call MmGetSystemRoutineAddress to get the pointer if it is available?

Just a thought.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Thursday, May 31, 2007 6:45 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MmGetSystemRoutineAddress BugCheck?

Sorry… did I read that right?

try/except isn’t the ULTIMATE anwer? OK, I get that, thank you.

But as of today our options are:

a) BSOD the machine
b) try/except which MIGHT NOT BSOD the machine

…and we should take option A?

Surely I’m missing something,

Peter

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

33

Except that RobertKj said that he saw a report of DbgPrintEx.

A really good description of the details of this bug would be a nice thing for the community to have, if somebody from MSFT would like to share.

Peter

34

My apology for the bad advice on using SEH. I composed and discarded posts on the issue this morning, and began with a “maybe you can do this but it hasn’t been verified” and moved to “it appears you can”, as the day wore on- partly based upon the fact that I’ve done my own code for locating kernel exports and didn’t remember any unwindable state in that solution, and partly on an over-optimistic reading of what information I could glean on the subject myself (not having ready access to or time to sift through all that legacy source).

35

Bad advice my ass.

Every indication I’ve seen indicates that this would be caught by try/except
(and I expect that several people on this list have already verified this).
And if not, it wouldn’t make it any worse.

I have a huge amount of respect for Doron, his knowledge and abilities, and
his selfless and abundant help on this list. But I think his last post was
irresponsible.

However, it is in keeping with Microsoft’s “response” to this problem.
Microsoft has for years been actively pushing the use of
MmGetSystemRoutineAddress in response to the community’s complaint’s that
API x is not available on Windows version y. Now we discover that it
crashes the system and blames your driver for 20% of the valid range of
inputs.

What is the response to that? Is it a Windows Update hotfix to EVERY
affected system regardless of whether or not it is still officially
supported? No, it’s don’t worry, it’s been fixed in some random assortment
of operating systems that we can’t really define. And don’t try to protect
yourself against it, because that’s “not recommended”, and “not in the
formal contract”.

If I’m not mistaken, the “formal contract” indicates that
MmGetSystemRoutineAddress will not BSOD if given valid inputs. You can
throw the “formal contract” out the window at this point.

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@microsoft.com
Sent: Thursday, May 31, 2007 8:49 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MmGetSystemRoutineAddress BugCheck?

My apology for the bad advice on using SEH. I composed and discarded posts
on the issue this morning, and began with a “maybe you can do this but it
hasn’t been verified” and moved to “it appears you can”, as the day wore on-
partly based upon the fact that I’ve done my own code for locating kernel
exports and didn’t remember any unwindable state in that solution, and
partly on an over-optimistic reading of what information I could glean on
the subject myself (not having ready access to or time to sift through all
that legacy source).

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

36

Bob. You’re taking this way too seriously. You gave your opinion,
which is all anyone on this list does, and all anyone should expect.
It’s nice to see commitment, but, in my opinion, you have nothing about
which to feel bad or for which to apologize, without even figuring in
that I agree with Dan and Peter (I think he said something about it
being better than a bluescreen). Even if you did in this case, which
you don’t, in the big picture, you answer so much, so well, so
thoroughly and patiently (the vast majority of the time; like anyone,
you do of course have your bad moments) - not to minimize your
knowledge, but the later is what makes you really commendable on this
list; look how many technically correct responses involve the word
“stupid” - somehow I think people would be willing to overlook whatever
it is you feel you did or should have done.

Keep up the good work,

mm

>> xxxxx@privtek.com 2007-05-31 23:59 >>>
Bad advice my ass.

Every indication I’ve seen indicates that this would be caught by
try/except
(and I expect that several people on this list have already verified
this).
And if not, it wouldn’t make it any worse.

I have a huge amount of respect for Doron, his knowledge and abilities,
and
his selfless and abundant help on this list. But I think his last post
was
irresponsible.

However, it is in keeping with Microsoft’s “response” to this problem.
Microsoft has for years been actively pushing the use of
MmGetSystemRoutineAddress in response to the community’s complaint’s
that
API x is not available on Windows version y. Now we discover that it
crashes the system and blames your driver for 20% of the valid range
of
inputs.

What is the response to that? Is it a Windows Update hotfix to EVERY
affected system regardless of whether or not it is still officially
supported? No, it’s don’t worry, it’s been fixed in some random
assortment
of operating systems that we can’t really define. And don’t try to
protect
yourself against it, because that’s “not recommended”, and “not in the
formal contract”.

If I’m not mistaken, the “formal contract” indicates that
MmGetSystemRoutineAddress will not BSOD if given valid inputs. You
can
throw the “formal contract” out the window at this point.

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@microsoft.com
Sent: Thursday, May 31, 2007 8:49 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MmGetSystemRoutineAddress BugCheck?

My apology for the bad advice on using SEH. I composed and discarded
posts
on the issue this morning, and began with a “maybe you can do this but
it
hasn’t been verified” and moved to “it appears you can”, as the day
wore on-
partly based upon the fact that I’ve done my own code for locating
kernel
exports and didn’t remember any unwindable state in that solution, and
partly on an over-optimistic reading of what information I could glean
on
the subject myself (not having ready access to or time to sift through
all
that legacy source).

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

37

There is a workaround that does not involve SEH. Yes, it is a bit
painful and iterative, but like peter Wieland said, you can use the
current OS version with some built in knowledge to know whether to make
the call or not until we can provide a real solution that does not
require every driver to hack around the bug. Essentially, you can do
this

If (TheCurrentVersionExportsThisDDI()) { MmGetSystemRoutineAddress() }

Instead of a blind call to MmGetSystemRoutineAddress on all platforms.
Kinda ugly? Yeah, but not that bad compared to other workarounds, esp
b/c the knowledge here is static and you will encounter the issue well
before you ship.

no need to be snide and create a straw man about a bug in the API vs SEH
and contracts. My point about contracts is that while it appears to
work, you can very well leave the OS in an unknown state (locks still
held or worse, a random address that was touched and we now have
corrupted some other structure or UM process, etc). You use SEH where
it is documented to be used, not to trap bugs (in your code, some other
driver, or the OS).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Thursday, May 31, 2007 9:00 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] MmGetSystemRoutineAddress BugCheck?

Bad advice my ass.

Every indication I’ve seen indicates that this would be caught by
try/except
(and I expect that several people on this list have already verified
this).
And if not, it wouldn’t make it any worse.

I have a huge amount of respect for Doron, his knowledge and abilities,
and
his selfless and abundant help on this list. But I think his last post
was
irresponsible.

However, it is in keeping with Microsoft’s “response” to this problem.
Microsoft has for years been actively pushing the use of
MmGetSystemRoutineAddress in response to the community’s complaint’s
that
API x is not available on Windows version y. Now we discover that it
crashes the system and blames your driver for 20% of the valid range of
inputs.

What is the response to that? Is it a Windows Update hotfix to EVERY
affected system regardless of whether or not it is still officially
supported? No, it’s don’t worry, it’s been fixed in some random
assortment
of operating systems that we can’t really define. And don’t try to
protect
yourself against it, because that’s “not recommended”, and “not in the
formal contract”.

If I’m not mistaken, the “formal contract” indicates that
MmGetSystemRoutineAddress will not BSOD if given valid inputs. You can
throw the “formal contract” out the window at this point.

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@microsoft.com
Sent: Thursday, May 31, 2007 8:49 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MmGetSystemRoutineAddress BugCheck?

My apology for the bad advice on using SEH. I composed and discarded
posts
on the issue this morning, and began with a “maybe you can do this but
it
hasn’t been verified” and moved to “it appears you can”, as the day wore
on-
partly based upon the fact that I’ve done my own code for locating
kernel
exports and didn’t remember any unwindable state in that solution, and
partly on an over-optimistic reading of what information I could glean
on
the subject myself (not having ready access to or time to sift through
all
that legacy source).

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

38

nice to see this bug getting the kind of response it should have got
years ago when it was first reported

while i searched why it was happening i happened to find that

it would not crash if i passed SHIT D******* etc as api names :slight_smile:
but would crash on some legitimate Api Names

i queried here in ntfsd but actually recieved no answers

http://www.osronline.com/showThread.cfm?link=99143

i actually got to learn windbg and vpc a little bit intimately with this bug

so i like this bug :slight_smile:

regards

raj_r

On 6/1/07, Doron Holan wrote:
> There is a workaround that does not involve SEH. Yes, it is a bit
> painful and iterative, but like peter Wieland said, you can use the
> current OS version with some built in knowledge to know whether to make
> the call or not until we can provide a real solution that does not
> require every driver to hack around the bug. Essentially, you can do
> this
>
> If (TheCurrentVersionExportsThisDDI()) { MmGetSystemRoutineAddress() }
>
> Instead of a blind call to MmGetSystemRoutineAddress on all platforms.
> Kinda ugly? Yeah, but not that bad compared to other workarounds, esp
> b/c the knowledge here is static and you will encounter the issue well
> before you ship.
>
> no need to be snide and create a straw man about a bug in the API vs SEH
> and contracts. My point about contracts is that while it appears to
> work, you can very well leave the OS in an unknown state (locks still
> held or worse, a random address that was touched and we now have
> corrupted some other structure or UM process, etc). You use SEH where
> it is documented to be used, not to trap bugs (in your code, some other
> driver, or the OS).
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
> Sent: Thursday, May 31, 2007 9:00 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] MmGetSystemRoutineAddress BugCheck?
>
> Bad advice my ass.
>
> Every indication I’ve seen indicates that this would be caught by
> try/except
> (and I expect that several people on this list have already verified
> this).
> And if not, it wouldn’t make it any worse.
>
> I have a huge amount of respect for Doron, his knowledge and abilities,
> and
> his selfless and abundant help on this list. But I think his last post
> was
> irresponsible.
>
> However, it is in keeping with Microsoft’s “response” to this problem.
> Microsoft has for years been actively pushing the use of
> MmGetSystemRoutineAddress in response to the community’s complaint’s
> that
> API x is not available on Windows version y. Now we discover that it
> crashes the system and blames your driver for 20% of the valid range of
> inputs.
>
> What is the response to that? Is it a Windows Update hotfix to EVERY
> affected system regardless of whether or not it is still officially
> supported? No, it’s don’t worry, it’s been fixed in some random
> assortment
> of operating systems that we can’t really define. And don’t try to
> protect
> yourself against it, because that’s “not recommended”, and “not in the
> formal contract”.
>
> If I’m not mistaken, the “formal contract” indicates that
> MmGetSystemRoutineAddress will not BSOD if given valid inputs. You can
> throw the “formal contract” out the window at this point.
>
> - Dan.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@microsoft.com
> Sent: Thursday, May 31, 2007 8:49 PM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] MmGetSystemRoutineAddress BugCheck?
>
>
> My apology for the bad advice on using SEH. I composed and discarded
> posts
> on the issue this morning, and began with a “maybe you can do this but
> it
> hasn’t been verified” and moved to “it appears you can”, as the day wore
> on-
> partly based upon the fact that I’ve done my own code for locating
> kernel
> exports and didn’t remember any unwindable state in that solution, and
> partly on an over-optimistic reading of what information I could glean
> on
> the subject myself (not having ready access to or time to sift through
> all
> that legacy source).
>
> —
> 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
>

39

That is actually what I already did. I actually ran into this about a week
and a half ago, but put off looking at the bugcheck until a couple of days
ago as I had a perfectly reasonable workaround. I know the method I am
looking for in this case is Vista or later only…so no problem.

I would, as Peter V. suggested, really like a more detailed characterization
of this bug. Like exactly why do some method names fail and some do not and
exactly where is the cutoff and why. It is just good to know right? It
makes me very uneasy coding in potential catastrophic failures in my code.
The more I can understand why this failed, the better I can make sure it
never happens again.

Bill M.

“Peter Wieland” wrote in message
news:xxxxx@ntdev…
From the description of the problem it would seem to say that you’re fine as
long as you ask for a DDI which comes alphabetically after “CmZ”.

In the cases where you are asking for a CM function, could you use
RtlIsNtDdiVersionAvailable and or RtlIsServicePackVersionAvailable to figure
out if there’s a chance in hell the call would succeed and then call
MmGetSystemRoutineAddress to get the pointer if it is available?

Just a thought.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Thursday, May 31, 2007 6:45 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MmGetSystemRoutineAddress BugCheck?

Sorry… did I read that right?

try/except isn’t the ULTIMATE anwer? OK, I get that, thank you.

But as of today our options are:

a) BSOD the machine
b) try/except which MIGHT NOT BSOD the machine

…and we should take option A?

Surely I’m missing something,

Peter

—
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

40

I got a little program with a driver somewhere which takes all ntdll.dll
exports and then try to finds the routine addresses in kernel (that is
ntoskrnl). From my experience, exception handling is not possible to catch
this bug, it will crash all the same. It’s been a while ago but maybe it
occasionally creates other bugchecks than 0x1E which cannot be handled by an
exception handler so I agree with you about the SEH.

Apart from the bug that is discussed here, if you run this on a x64 platform
you will see that at random MmGetSystemRoutineAddresss will just return NULL
for a perfectly legal exproted function while if you run it a next time it
may return its address or it may return NULL again, this also needs to be
fixed.

/Daniel

“Doron Holan” wrote in message
news:xxxxx@ntdev…
There is a workaround that does not involve SEH. Yes, it is a bit
painful and iterative, but like peter Wieland said, you can use the
current OS version with some built in knowledge to know whether to make
the call or not until we can provide a real solution that does not
require every driver to hack around the bug. Essentially, you can do
this

If (TheCurrentVersionExportsThisDDI()) { MmGetSystemRoutineAddress() }

Instead of a blind call to MmGetSystemRoutineAddress on all platforms.
Kinda ugly? Yeah, but not that bad compared to other workarounds, esp
b/c the knowledge here is static and you will encounter the issue well
before you ship.

no need to be snide and create a straw man about a bug in the API vs SEH
and contracts. My point about contracts is that while it appears to
work, you can very well leave the OS in an unknown state (locks still
held or worse, a random address that was touched and we now have
corrupted some other structure or UM process, etc). You use SEH where
it is documented to be used, not to trap bugs (in your code, some other
driver, or the OS).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Thursday, May 31, 2007 9:00 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] MmGetSystemRoutineAddress BugCheck?

Bad advice my ass.

Every indication I’ve seen indicates that this would be caught by
try/except
(and I expect that several people on this list have already verified
this).
And if not, it wouldn’t make it any worse.

I have a huge amount of respect for Doron, his knowledge and abilities,
and
his selfless and abundant help on this list. But I think his last post
was
irresponsible.

However, it is in keeping with Microsoft’s “response” to this problem.
Microsoft has for years been actively pushing the use of
MmGetSystemRoutineAddress in response to the community’s complaint’s
that
API x is not available on Windows version y. Now we discover that it
crashes the system and blames your driver for 20% of the valid range of
inputs.

What is the response to that? Is it a Windows Update hotfix to EVERY
affected system regardless of whether or not it is still officially
supported? No, it’s don’t worry, it’s been fixed in some random
assortment
of operating systems that we can’t really define. And don’t try to
protect
yourself against it, because that’s “not recommended”, and “not in the
formal contract”.

If I’m not mistaken, the “formal contract” indicates that
MmGetSystemRoutineAddress will not BSOD if given valid inputs. You can
throw the “formal contract” out the window at this point.

- Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@microsoft.com
Sent: Thursday, May 31, 2007 8:49 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MmGetSystemRoutineAddress BugCheck?

My apology for the bad advice on using SEH. I composed and discarded
posts
on the issue this morning, and began with a “maybe you can do this but
it
hasn’t been verified” and moved to “it appears you can”, as the day wore
on-
partly based upon the fact that I’ve done my own code for locating
kernel
exports and didn’t remember any unwindable state in that solution, and
partly on an over-optimistic reading of what information I could glean
on
the subject myself (not having ready access to or time to sift through
all
that legacy source).

—
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