I am having a problem calling this function on Win2K SP4. I have code
that looks like this:
// if we are running on pre-WinXP (i.e. Win2K)
if (!RtlIsNtDdiVersionAvailable(NTDDI_WINXP))
{
// if we are running on pre-SP4
if (!RtlIsServicePackVersionInstalled(NTDDI_WIN2KSP4))
{
bPre2KSP4 = TRUE;
}
}
The boolean then gets used to conditionally call
MmGetSystemRoutineAddress() on Win2K SP4 and later platforms. I did
this to avoid the MmGetSystemRoutineAddress() bug but now I seem to be
hitting something else equally problematic.
The call to RtlIsNtDdiVersionAvailable() succeeds without issue,
however the call to RtlIsServicePackVersionInstalled() call blue
screens.
Disassembling the routine reveals that it first calls
MmGetSystemRoutineAddress(“RtlIsServicePackVersionInstalled”) itself
which correctly returns null at least. It immediately branches due to
this null and grabs the dword at fs:[00000018h]:
mov eax, dword ptr fs:[00000018h]
This value is null but two instructions later (the middle instruction
is “push esi”) it dereferences it with:
mov esi, dword ptr [eax+30h]
This is where the blue screen occurs for obvious reasons.
So my question is, am I completely off in my understanding of how to
use this routine or does it have a bug as well? I am using the ver
6000 DDK and doing a Win2K build (XP builds under that same DDK
produced the same results).
It’s just part of the MmGetSys… bug. It can crash but it can also just
return NULL when it wants. This is what happened to you, we should make a
catalog of anything that makes use of it.
/Daniel
“Jason T.” wrote in message news:xxxxx@ntdev… > Hello, > > I am having a problem calling this function on Win2K SP4. I have code > that looks like this: > > // if we are running on pre-WinXP (i.e. Win2K) > if (!RtlIsNtDdiVersionAvailable(NTDDI_WINXP)) > { > // if we are running on pre-SP4 > if (!RtlIsServicePackVersionInstalled(NTDDI_WIN2KSP4)) > { > bPre2KSP4 = TRUE; > } > } > > The boolean then gets used to conditionally call > MmGetSystemRoutineAddress() on Win2K SP4 and later platforms. I did > this to avoid the MmGetSystemRoutineAddress() bug but now I seem to be > hitting something else equally problematic. > > The call to RtlIsNtDdiVersionAvailable() succeeds without issue, > however the call to RtlIsServicePackVersionInstalled() call blue > screens. > > Disassembling the routine reveals that it first calls > MmGetSystemRoutineAddress(“RtlIsServicePackVersionInstalled”) itself > which correctly returns null at least. It immediately branches due to > this null and grabs the dword at fs:[00000018h]: > > mov eax, dword ptr fs:[00000018h] > > This value is null but two instructions later (the middle instruction > is “push esi”) it dereferences it with: > > mov esi, dword ptr [eax+30h] > > This is where the blue screen occurs for obvious reasons. > > So my question is, am I completely off in my understanding of how to > use this routine or does it have a bug as well? I am using the ver > 6000 DDK and doing a Win2K build (XP builds under that same DDK > produced the same results). > > Thank you for reading. >
I thought that if MmGetSystemRoutineAddress returned null then you
were in the clear. My crash does not occur during the call to
MmGetSystemRoutineAddress, but rather in the logic that executes if
that call returns null. After doing some more checks, the issue is
that the TEB pointer is null (fs:18). The routine was attempting to
dereference that pointer in order to get the
TEB->ProcessEnvironmentBlock pointer and that’s when it crashes. This
seems independent of anything that MmGetSystemRoutineAddress could
have done, isn’t it? From what I can tell, the TEB will always be
null if you are called from a system thread (in this case the problem
code is in my DriverEntry) so I don’t see how this could have ever
worked.
Daniel wrote:
It’s just part of the MmGetSys… bug. It can crash but it can also just
return NULL when it wants. This is what happened to you, we should make a
catalog of anything that makes use of it.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jason T.
Sent: Monday, November 05, 2007 8:50 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] RtlIsServicePackVersionInstalled issue?
I thought that if MmGetSystemRoutineAddress returned null then you
were in the clear. My crash does not occur during the call to
MmGetSystemRoutineAddress, but rather in the logic that executes if
that call returns null. After doing some more checks, the issue is
that the TEB pointer is null (fs:18). The routine was attempting to
dereference that pointer in order to get the
TEB->ProcessEnvironmentBlock pointer and that’s when it crashes. This
seems independent of anything that MmGetSystemRoutineAddress could
have done, isn’t it? From what I can tell, the TEB will always be
null if you are called from a system thread (in this case the problem
code is in my DriverEntry) so I don’t see how this could have ever
worked.
Daniel wrote:
It’s just part of the MmGetSys… bug. It can crash but it can also just
return NULL when it wants. This is what happened to you, we should make a
catalog of anything that makes use of it.
I am not following some of your logic. If you enter
RtlIsServicePackVersionInstalled how could MmGetSystemRoutineAddress for
that very routine CORRECTLY return NULL ? It wants to check the address for
itself which of course can never be NULL. That alone should be enough of an
indication that it is failing and this behavior is consistent with its known
problem of voluntarily crashing or returning NULL when it shouldn’t.
According to your description it just assumes a valid pointer which is then
further used without validity checking.
But above all, anything which relies on MmGetSystemRoutineAddress (or
MiFindExportedRoutineByName) is deprecated from the very beginning.
/Daniel
“Jason T.” wrote in message news:xxxxx@ntdev… > “…however the call to RtlIsServicePackVersionInstalled() call blue screens.Disassembling the routine reveals that it first calls MmGetSystemRoutineAddress(“RtlIsServicePackVersionInstalled”) itself which correctly returns null at least.” > > … >I thought that if MmGetSystemRoutineAddress returned null then you > were in the clear. My crash does not occur during the call to > MmGetSystemRoutineAddress, but rather in the logic that executes if > that call returns null. After doing some more checks, the issue is > that the TEB pointer is null (fs:18). The routine was attempting to > dereference that pointer in order to get the > TEB->ProcessEnvironmentBlock pointer and that’s when it crashes. This > seems independent of anything that MmGetSystemRoutineAddress could > have done, isn’t it? From what I can tell, the TEB will always be > null if you are called from a system thread (in this case the problem > code is in my DriverEntry) so I don’t see how this could have ever > worked. > > > Daniel wrote: > >>It’s just part of the MmGetSys… bug. It can crash but it can also just >>return NULL when it wants. This is what happened to you, we should make a >>catalog of anything that makes use of it. >> >>/Daniel >
RtlIsServicePackVersionInstalled is a funny function. It tries to be available on all downlevel platforms. This happens with macro magic. You link against WdmlibRtlIsServicePackVersionInstalled which is contained in a lib and it internally tries to find “RtlIsServicePackVersionInstalled”. If not found, you get the version check as a part of the lib.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Daniel Terhell
Sent: Monday, November 05, 2007 9:34 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] RtlIsServicePackVersionInstalled issue?
I am not following some of your logic. If you enter
RtlIsServicePackVersionInstalled how could MmGetSystemRoutineAddress for
that very routine CORRECTLY return NULL ? It wants to check the address for
itself which of course can never be NULL. That alone should be enough of an
indication that it is failing and this behavior is consistent with its known
problem of voluntarily crashing or returning NULL when it shouldn’t.
According to your description it just assumes a valid pointer which is then
further used without validity checking.
But above all, anything which relies on MmGetSystemRoutineAddress (or
MiFindExportedRoutineByName) is deprecated from the very beginning.
/Daniel
“Jason T.” wrote in message news:xxxxx@ntdev… > “…however the call to RtlIsServicePackVersionInstalled() call blue screens.Disassembling the routine reveals that it first calls MmGetSystemRoutineAddress(“RtlIsServicePackVersionInstalled”) itself which correctly returns null at least.” > > … >I thought that if MmGetSystemRoutineAddress returned null then you > were in the clear. My crash does not occur during the call to > MmGetSystemRoutineAddress, but rather in the logic that executes if > that call returns null. After doing some more checks, the issue is > that the TEB pointer is null (fs:18). The routine was attempting to > dereference that pointer in order to get the > TEB->ProcessEnvironmentBlock pointer and that’s when it crashes. This > seems independent of anything that MmGetSystemRoutineAddress could > have done, isn’t it? From what I can tell, the TEB will always be > null if you are called from a system thread (in this case the problem > code is in my DriverEntry) so I don’t see how this could have ever > worked. > > > Daniel wrote: > >>It’s just part of the MmGetSys… bug. It can crash but it can also just >>return NULL when it wants. This is what happened to you, we should make a >>catalog of anything that makes use of it. >> >>/Daniel >
I confirmed this is a bug for an OS which does not export RtlIsServicePackVersionInstalled and when this function is called in the context of a system thread. We logged a bug to track and are working on a ship vehicle for the fix. Thanks for reporting the issue.
On a side note, are you avoiding calling MmGetSystemRoutineAddress because of the theoretical issues it has for an unexported query or you are seeing it bugcheck on you?
d
-----Original Message-----
From: Doron Holan
Sent: Monday, November 05, 2007 9:14 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] RtlIsServicePackVersionInstalled issue?
I poke around and let you know
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jason T.
Sent: Monday, November 05, 2007 8:50 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] RtlIsServicePackVersionInstalled issue?
I thought that if MmGetSystemRoutineAddress returned null then you
were in the clear. My crash does not occur during the call to
MmGetSystemRoutineAddress, but rather in the logic that executes if
that call returns null. After doing some more checks, the issue is
that the TEB pointer is null (fs:18). The routine was attempting to
dereference that pointer in order to get the
TEB->ProcessEnvironmentBlock pointer and that’s when it crashes. This
seems independent of anything that MmGetSystemRoutineAddress could
have done, isn’t it? From what I can tell, the TEB will always be
null if you are called from a system thread (in this case the problem
code is in my DriverEntry) so I don’t see how this could have ever
worked.
Daniel wrote:
It’s just part of the MmGetSys… bug. It can crash but it can also just
return NULL when it wants. This is what happened to you, we should make a
catalog of anything that makes use of it.
I confirmed this is a bug for an OS which does not export
RtlIsServicePackVersionInstalled and when this function is called in
the context
of a system thread. We logged a bug to track and are working on a
ship vehicle
for the fix. Thanks for reporting the issue.
No problem. Glad you were able to confirm it and I’m not just crazy.
On a side note, are you avoiding calling MmGetSystemRoutineAddress because >of
the theoretical issues it has for an unexported query or you are seeing it
bugcheck on you?
I was trying to avoid problems (specifically, having
MmGetSystemRoutineAddress blue screen) but ended up running squarely
into one. I had not actually hit a blue screen, I just coded it this
way from the beginning due to advice I had seen on OSR’s and MS’s
sites. During development I honestly not tested it on Win2K so this
never came up until recently. The function in question is
IoAttachDeviceToDeviceStackSafe, whenever possible, and
IoAttachDeviceToDeviceStack on versions prior to Win2K SP4.
What would you suggest as the best way to proceed at this time?
>>
The function in question is
IoAttachDeviceToDeviceStackSafe, whenever possible, and
IoAttachDeviceToDeviceStack on versions prior to Win2K SP4.
<<
You are not at risk of the MmGetSystemRoutineAddress bug with these DDI names [assuming they are the real names and not redefined via macro].
The risk is confined to names alphabetically before the first Halxxx DDI (e.g., Cm…Ex…, Dbg…). More precisely, a non-existent name before the first export from the target machine’s HAL (in same cases I looked at in a small and random sample they had names earlier in alphabetic sequence).
Also, the bug will NOT return NULL on names that are real exports. It CAN return NULL if you don’t do your homework- for instance, if you read your header files you will see some DDI are macros in some or even all cases (e.g. look aside lists), others have name shifts (e.g. IoCallDriver is IofCallDriver), and still others are actualy linked into the binary via libraries [such as the one you were using- WdmRtlIsServicePackVersionInstalled) and thus aren’t really exported anywhere.
Finally, the most exposed OSes are Win2K and XP (for which SP3 will fix it)- there was going to be a QFE for XP, IIRC. Win2K3 is fixed beginning with SP1, and Vista from the beginning. x64 never had this bug in a shipping version (betas maybe- didn’t check and don’t care).
Sorry if there are any typos- I quit using email for replies because they never made it, and web interface doesn’t have a spell checker nor much preview space…
wrote in message news:xxxxx@ntdev… >>> > The function in question is > IoAttachDeviceToDeviceStackSafe, whenever possible, and > IoAttachDeviceToDeviceStack on versions prior to Win2K SP4. > << > > The risk is confined to names alphabetically before the first Halxxx DDI > (e.g., Cm…Ex…, Dbg…). More precisely, a non-existent name before > the first export from the target machine’s HAL (in same cases I looked at > in a small and random sample they had names earlier in alphabetic > sequence).
Wrong, it can crash with existent names as well.
> Also, the bug will NOT return NULL on names that are real exports. It CAN > return NULL if you don’t do your homework- for instance, if you read your > header files you will see some DDI are macros in some or even all cases > (e.g. look aside lists), others have name shifts (e.g. IoCallDriver is > IofCallDriver), and still others are actualy linked into the binary via > libraries [such as the one you were using- > WdmRtlIsServicePackVersionInstalled) and thus aren’t really exported > anywhere. >
Wrong again, it can crash or return NULL with perfeclty legal exported function names. The problem has been tracked down to high, mid and low variables in a binary search algorithm which inadvertently have been declared as unsigned while they should have been signed but we have had this discussion before. Talking about homework, it’s been five years this bug has been known. Why don’t you provide a service pack and why don’t you provide a list of functions which internally call this to prevent disaster ? I can provide examples which demonstrate both of these cases. But better I invite you to step aside for once from your rigid policies, make an exception and publish the faulty source code so we can make a comprehensive analysis.
Daniel, making assertions is not constructive. If you have cases where calls to MmGetSystemRoutineAddress exhibit the behaviors yiou insist exist (crashing or returning NULL on names which REALLY are exported from the kernel or hal ON THE MACHINE IN WHICH THIS IS HAPPENING), then report them. I’ve already revealed more about the code underlying this than I should have.
Service packs are and continue to be provided with this fix.
If you want policy changes, direct your remarks to someone who can do something about them. You will need to start somewhere a heck of a lot closer to the board of directors than I am now or ever intend to be. they are not MY policies (not that I necessarily disagree with them)- they are corporate policies I agreed to adhere to when I signed my employment contract.
I am NOT an official spokesperson and I am not even responsible for that code- but I did read the code [mutiple versions of it] and conducted quite a few experiments [particularly in response to these same concerns, which you kept raising the last time this was discussed] because I have to use this routine extensively myself and I could not understand why neither I nor anyone I worked with [such as Doron at the time] was aware of it. Based on that reading and those experiments I am confident that what I claimed previously is fact. If you have evidence to the contrary, then present it.
On a side note, are you avoiding calling MmGetSystemRoutineAddress because of the theoretical issues it has for an unexported query or you are seeing it bugcheck on you?
I thought the MmGetSystemRoutineAddress bug only affected unknown entry
points that started with letters early in the alphabet?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Let’s have a gentlemen’s bet. I provide the samples (crashing or returning
NULL on names which REALLY are exported from the kernel or hal ON THE
MACHINE IN WHICH THIS IS HAPPENING) otherwise you provide me MVP status
which doesn’t mean a thing.
/Daniel
wrote in message news:xxxxx@ntdev… > Daniel, making assertions is not constructive. If you have cases where > calls to MmGetSystemRoutineAddress exhibit the behaviors yiou insist exist > (crashing or returning NULL on names which REALLY are exported from the > kernel or hal ON THE MACHINE IN WHICH THIS IS HAPPENING), then report > them. I’ve already revealed more about the code underlying this than I > should have. > > Service packs are and continue to be provided with this fix. > > If you want policy changes, direct your remarks to someone who can do > something about them. You will need to start somewhere a heck of a lot > closer to the board of directors than I am now or ever intend to be. they > are not MY policies (not that I necessarily disagree with them)- they are > corporate policies I agreed to adhere to when I signed my employment > contract. > > I am NOT an official spokesperson and I am not even responsible for that > code- but I did read the code [mutiple versions of it] and conducted quite > a few experiments [particularly in response to these same concerns, which > you kept raising the last time this was discussed] because I have to use > this routine extensively myself and I could not understand why neither I > nor anyone I worked with [such as Doron at the time] was aware of it. > Based on that reading and those experiments I am confident that what I > claimed previously is fact. If you have evidence to the contrary, then > present it. >
Correct. I wanted to know if he was using this function defensively against the potential of hitting the bug or the actuality of hitting this bug and using this function as a workaround.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, November 06, 2007 9:43 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] RtlIsServicePackVersionInstalled issue?
Doron Holan wrote:
On a side note, are you avoiding calling MmGetSystemRoutineAddress because of the theoretical issues it has for an unexported query or you are seeing it bugcheck on you?
I thought the MmGetSystemRoutineAddress bug only affected unknown entry
points that started with letters early in the alphabet?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
We can’t grant MVP access, that goes through a nomination and vetting process that is someone else’s domain. And it does mean something (for instance you can get access to windows source) ;), ask don or maxim.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Daniel Terhell
Sent: Tuesday, November 06, 2007 10:01 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] RtlIsServicePackVersionInstalled issue?
Let’s have a gentlemen’s bet. I provide the samples (crashing or returning
NULL on names which REALLY are exported from the kernel or hal ON THE
MACHINE IN WHICH THIS IS HAPPENING) otherwise you provide me MVP status
which doesn’t mean a thing.
/Daniel
wrote in message news:xxxxx@ntdev… > Daniel, making assertions is not constructive. If you have cases where > calls to MmGetSystemRoutineAddress exhibit the behaviors yiou insist exist > (crashing or returning NULL on names which REALLY are exported from the > kernel or hal ON THE MACHINE IN WHICH THIS IS HAPPENING), then report > them. I’ve already revealed more about the code underlying this than I > should have. > > Service packs are and continue to be provided with this fix. > > If you want policy changes, direct your remarks to someone who can do > something about them. You will need to start somewhere a heck of a lot > closer to the board of directors than I am now or ever intend to be. they > are not MY policies (not that I necessarily disagree with them)- they are > corporate policies I agreed to adhere to when I signed my employment > contract. > > I am NOT an official spokesperson and I am not even responsible for that > code- but I did read the code [mutiple versions of it] and conducted quite > a few experiments [particularly in response to these same concerns, which > you kept raising the last time this was discussed] because I have to use > this routine extensively myself and I could not understand why neither I > nor anyone I worked with [such as Doron at the time] was aware of it. > Based on that reading and those experiments I am confident that what I > claimed previously is fact. If you have evidence to the contrary, then > present it. >
Sorry for the confusion I had a couple of beers by now, it’s time to meat
the children and ex-wife for me. I meant (I provide you the samples AND you
give me source access) or (you can scandalize my name AND I won’t
participate in any kernel group for twelve months).
/Daniel
“Doron Holan” wrote in message news:xxxxx@ntdev… We can’t grant MVP access, that goes through a nomination and vetting process that is someone else’s domain. And it does mean something (for instance you can get access to windows source) ;), ask don or maxim.
d
-----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Daniel Terhell Sent: Tuesday, November 06, 2007 10:01 AM To: Windows System Software Devs Interest List Subject: Re:[ntdev] RtlIsServicePackVersionInstalled issue?
Let’s have a gentlemen’s bet. I provide the samples (crashing or returning NULL on names which REALLY are exported from the kernel or hal ON THE MACHINE IN WHICH THIS IS HAPPENING) otherwise you provide me MVP status which doesn’t mean a thing.
/Daniel
wrote in message news:xxxxx@ntdev… > Daniel, making assertions is not constructive. If you have cases where > calls to MmGetSystemRoutineAddress exhibit the behaviors yiou insist exist > (crashing or returning NULL on names which REALLY are exported from the > kernel or hal ON THE MACHINE IN WHICH THIS IS HAPPENING), then report > them. I’ve already revealed more about the code underlying this than I > should have. > > Service packs are and continue to be provided with this fix. > > If you want policy changes, direct your remarks to someone who can do > something about them. You will need to start somewhere a heck of a lot > closer to the board of directors than I am now or ever intend to be. they > are not MY policies (not that I necessarily disagree with them)- they are > corporate policies I agreed to adhere to when I signed my employment > contract. > > I am NOT an official spokesperson and I am not even responsible for that > code- but I did read the code [mutiple versions of it] and conducted quite > a few experiments [particularly in response to these same concerns, which > you kept raising the last time this was discussed] because I have to use > this routine extensively myself and I could not understand why neither I > nor anyone I worked with [such as Doron at the time] was aware of it. > Based on that reading and those experiments I am confident that what I > claimed previously is fact. If you have evidence to the contrary, then > present it. >
>>
Let’s have a gentlemen’s bet. I provide the samples (crashing or returning
NULL on names which REALLY are exported from the kernel or hal ON THE
MACHINE IN WHICH THIS IS HAPPENING) otherwise you provide me MVP status
which doesn’t mean a thing.
<<
Perhaps I shouldn’t respond but I will. First off, I can’t do anything about an MVP status for anyone.
I do try to provide accurate advice when I bother to provide advice. I welcome feedback where I’m wrong, no matter how unfavorably delivbered- or at least I try to [sometimes I’m not as good about it as I ought to be].
The bug occurs if the name occurs alphabeticaly before the first name in an alphabetically sorted lsit of names. The way names are distributed between HAL and kernel, and knowing people generally try to use names that are supposed to exist, the best advice is to watch out for names before the first name in the HAL. At the very worst that will be one of the Halxxx routines.
But a name on the list will be found [it is, after all, an exit criterion for a search algorithm]. And a name alphabetically after the first one won’t hit the wrap at table inde 0 due to a unsigned arithmetic underflow.
I’m not making assertions in my view- anyone with some driver code and time on their hands can verify these things to their heart’s content. If I missed something, I don’t have a problem with knowing about it [even though it really isn’t my problem to deal with- I’ve satisfied myself that this is the case and continue to use this DDI even though I have alternatives if I need them, and nobody here has indicated I’m wrong in doing so].
Ok, it appears you were right and I was wrong. In my experiment I was taking
the exports from ntdll and not from ntoskrnl, this is why it crashed. And I
swear I have seen this I have seen this function return NULL at random but I
am not able to reproduce it. And yes it crashes with non-existent names that
start from A-H only. I was being arrogant and was looking for an outlet for
my frustration with MS. Now because there was no gentlemen’s agreement you
may not scandalize my name but as a suitable punishment I will refrain from
posting in the kernel groups (except for this thread) until the end of the
year only.
/Daniel
wrote in message news:xxxxx@ntdev… > Daniel, making assertions is not constructive. If you have cases where > calls to MmGetSystemRoutineAddress exhibit the behaviors yiou insist exist > (crashing or returning NULL on names which REALLY are exported from the > kernel or hal ON THE MACHINE IN WHICH THIS IS HAPPENING), then report > them. I’ve already revealed more about the code underlying this than I > should have. > > Service packs are and continue to be provided with this fix. > > If you want policy changes, direct your remarks to someone who can do > something about them. You will need to start somewhere a heck of a lot > closer to the board of directors than I am now or ever intend to be. they > are not MY policies (not that I necessarily disagree with them)- they are > corporate policies I agreed to adhere to when I signed my employment > contract. > > I am NOT an official spokesperson and I am not even responsible for that > code- but I did read the code [mutiple versions of it] and conducted quite > a few experiments [particularly in response to these same concerns, which > you kept raising the last time this was discussed] because I have to use > this routine extensively myself and I could not understand why neither I > nor anyone I worked with [such as Doron at the time] was aware of it. > Based on that reading and those experiments I am confident that what I > claimed previously is fact. If you have evidence to the contrary, then > present it. >
First off, I can’t do anything about an MVP status for anyone.
Just curious, but how does this work. I was under the impression that when
an individual was nominated, you guys/girls in the core services group voted
on an individual…
As a novice, I’ve found that when a DDK MVP speaks (or someone from
Micorsoft), generally everyone should listen. However, how does Microsoft
evaluate MVP’s as experts on driver writing if you guys that own the kernel
don’t have input on who is certified?
I admit this is slightly off topic, but I learn a lot from just reading this
list. When two different people that both sound knowledgeable are speaking
about something and have different views, what sets the MVP above the other.
Don’t be silly. Oh well, you got emotional about a bug that has been
frustrating you for a while. In the meantime lots of good information
was exchanged and people searching this list may find some clues to
solve their related problems. I don’t think exile is required.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Daniel Terhell
Sent: Wednesday, November 07, 2007 5:26 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] RtlIsServicePackVersionInstalled issue?
Ok, it appears you were right and I was wrong. In my experiment I was
taking
the exports from ntdll and not from ntoskrnl, this is why it crashed.
And I
swear I have seen this I have seen this function return NULL at random
but I
am not able to reproduce it. And yes it crashes with non-existent names
that
start from A-H only. I was being arrogant and was looking for an outlet
for
my frustration with MS. Now because there was no gentlemen’s agreement
you
may not scandalize my name but as a suitable punishment I will refrain
from
posting in the kernel groups (except for this thread) until the end of
the
year only.
/Daniel
wrote in message news:xxxxx@ntdev… > Daniel, making assertions is not constructive. If you have cases where > calls to MmGetSystemRoutineAddress exhibit the behaviors yiou insist exist > (crashing or returning NULL on names which REALLY are exported from the > kernel or hal ON THE MACHINE IN WHICH THIS IS HAPPENING), then report > them. I’ve already revealed more about the code underlying this than I > should have. > > Service packs are and continue to be provided with this fix. > > If you want policy changes, direct your remarks to someone who can do > something about them. You will need to start somewhere a heck of a lot > closer to the board of directors than I am now or ever intend to be. they > are not MY policies (not that I necessarily disagree with them)- they are > corporate policies I agreed to adhere to when I signed my employment > contract. > > I am NOT an official spokesperson and I am not even responsible for that > code- but I did read the code [mutiple versions of it] and conducted quite > a few experiments [particularly in response to these same concerns, which > you kept raising the last time this was discussed] because I have to use > this routine extensively myself and I could not understand why neither I > nor anyone I worked with [such as Doron at the time] was aware of it. > Based on that reading and those experiments I am confident that what I
> claimed previously is fact. If you have evidence to the contrary, then > present it. >