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
> The lock is used to lock the loaded module list to find the base of the
kernel and
hal export tables.
Why not save these 2 to global variables at boot to avoid any locks in
MmGetSystemRoutineAddress?
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Look- I believe there’s a bigger problem with the x64 reports (can’t believe it took so long for it to sink in). Two x64 OS versions have shipped. BOTH are not supposed to have this bug.
I’m on my way to do a repro with an SP1 RTM build shortly.
Less important and probably not entirely constructive blathering…
The tables are described in the Platform SDK and probably any good article discussing the PE format. They are not strings (strings are variable length, how can you do such a search directly?)- they are conceptually pointers to strings (more precisely they are offsets from the point in memory at which the image is loaded (image base) to the string, which the linker also has to place int he memory image).
So, yes, the first bad value is 0x7FFFFFFF- but that’s an index to an array of ULONGS. To translate that to an effective address, you shift it left 2 bits (because they are 4 bytes in size) meaning you look at base + 0xFFFFFFFC
in the above posted disassembly, it occurs HERE:
MOV ESI, DWORD PTR DS:[EDX+ECX*4]
EDX is the start of the table, and ECX is the index. When you multiply ECX by 4 (surely you see it by now, this time isn’t getting me my repro).
That’s the same offset as you would get for ECX =-1, as I said, so it’s still an entry in the binary’s memory image.
The next time you are not so fortunate if you’re falling off the botom- the index for 3FFFFFFF is 7FFFFFFC, which on an x86 machine (kernel usually sits far enough above 0x80000000 that in adding THAT offset you will wrap far enough, just use your debugger to verify) is going to be an address normally used by a user process. Which is why I’m so sure the mechanism I described is the most likely (except that that first offset just has to point to one valid byte smaller than the first character you are looking for SOMEHWERE in a valid address- I used the binary’s image as an example because it is much less likely to chang eon you, and I was thinking primarily of “code as data” at that point) way to ever get a NULL (once things break).
If you want to be purely theoretcial, then fine, you could always fall off the bottom and manage to hit without page faulting the 30 some addresses this loop will then try, scattered all across the machine’s address space and never changing, and they could never later go invalid and those offsets either never change or always manage themselves to still point to valid data that again somehow never changes or always change to a value [remember one of these comparands is a constant) that would still force middle down and you could just loop forever and never return.
But I’d bet it’s never actually happened to anyone. If it did, they might want meteor insurance!
Well, I’ve satisfied myself that 64-bit XP at RTM is fine for this. I’ve hit valid and invalid cases and (e.g.) the invalid case “AxAllocatePoolWithBag” (well before either name in either binary) was NULL and I also checked several names that were valid, and I got the matching routine addresses.
If somebody’s got an x64 repro where it returns NULL for a valid name or crashes, fine. Give me details I can hang something on (which OS and which name would really be good to have).
I was going to hack together from my existing bag of code something to collect all the exports from both, pass them up to UM for a cheap conversion to Unicode, then back to KM so I could call the API for each, and check for null vs non-null returns (and also perturb each name so it would hit the before and after misses on each and every entry). If I owned this, that’d be my idea of a good black box test for it- or at least a starting place. But really, it’s a nice weekend, it would take most of the day [or longer] even though I’ve already got most of the pieces I’d need to start with, there’s plenty to do next week, and I’m finding it hard to believe this was ever broken there,
I also waded through the revision control database to ferret out where the fix was made and where it went [not always easy, but usually possible if you’re persistent], and it was in server SP1 (which was the first x64 OS) well before it shipped. Vista was spun from that codebase, so unless someone was running the super-old Longhorn alphas [and I’m not sure they ever wandered outside the walls], I don’t see how that could have happened.
Now I’ve been burned myself a few too many times by being flat-out wrong saying I had no repro without going to something like I described above [there might have been a compiler bug that only crops up on some particular call for some reason]. But I suspect that even the test holes were probably plugged a long time back by something like I just described, and nobody really needs me reinventing that wheel.
I’m not saying the reports of this crashing on x64 aren’t real. But I don’t think there’s anything else that I or anyone else here can do without getting our hands on something that’s broken.
Doron has already said he was trying to get QFE info for people who need it- I think that message got lost in all the noise. That might take a while (it would take me even longer, though, I’m sure).
Bob, I ran my test program and driver which takes all ntoskrnl exports and
tested it with Mm and I can confirm that on XP x64 SP2 and Server 2003 x64
SP2 with latest updates it gives consistent and meaningful addresses for all
ntoskrnl exports and it doesn’t on SP1. So this must have got fixed either
between SP1 and SP2 or by a Windows update. After that I wrote another test
driver which throws garbage names at Mm, first a million times with alphanum
chars only, then a million times with complety garbage unicode strings and
also this test runs fine. It is worthwhile to test because millions of
computers are relying on this code.
Anyway, if you want a repro to test on SP1, it only takes five minutes to
dump all exports from a module using tdump or depends and use a text editor
to do a search and replace to create a test driver which DbgPrints all the
routine names and addresses.
/Daniel
“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
Well, I’ve satisfied myself that 64-bit XP at RTM is fine for this. I’ve
hit valid and invalid cases and (e.g.) the invalid case
“AxAllocatePoolWithBag” (well before either name in either binary) was NULL
and I also checked several names that were valid, and I got the matching
routine addresses.
If somebody’s got an x64 repro where it returns NULL for a valid name or
crashes, fine. Give me details I can hang something on (which OS and which
name would really be good to have).
I was going to hack together from my existing bag of code something to
collect all the exports from both, pass them up to UM for a cheap conversion
to Unicode, then back to KM so I could call the API for each, and check for
null vs non-null returns (and also perturb each name so it would hit the
before and after misses on each and every entry). If I owned this, that’d
be my idea of a good black box test for it- or at least a starting place.
But really, it’s a nice weekend, it would take most of the day [or longer]
even though I’ve already got most of the pieces I’d need to start with,
there’s plenty to do next week, and I’m finding it hard to believe this was
ever broken there,
I also waded through the revision control database to ferret out where the
fix was made and where it went [not always easy, but usually possible if
you’re persistent], and it was in server SP1 (which was the first x64 OS)
well before it shipped. Vista was spun from that codebase, so unless
someone was running the super-old Longhorn alphas [and I’m not sure they
ever wandered outside the walls], I don’t see how that could have happened.
Now I’ve been burned myself a few too many times by being flat-out wrong
saying I had no repro without going to something like I described above
[there might have been a compiler bug that only crops up on some particular
call for some reason]. But I suspect that even the test holes were probably
plugged a long time back by something like I just described, and nobody
really needs me reinventing that wheel.
I’m not saying the reports of this crashing on x64 aren’t real. But I don’t
think there’s anything else that I or anyone else here can do without
getting our hands on something that’s broken.
Doron has already said he was trying to get QFE info for people who need it-
I think that message got lost in all the noise. That might take a while (it
would take me even longer, though, I’m sure).
Update: I found a virtual machine with Win2003 x64 SP1 and my thorough tests
did not show any problem either. So it must be SP0 where this problem
occured. I have no SP0 available here now. I’m sure this problem was there
before but it seems to have resolved in the service packs so it is of little
interest now and anyway it didn’t bugcheck, it only returned NULL on
exported functions so it wasn’t a major problem anyway. Drivers should be
able to handle these cases, otherwise why would they test for it anyway ? At
the time it was an annoyance because I couldn’t write the software I wanted
but the worst that could happen is that a driver on x64 SP0 is missing some
features or won’t work, it isn’t worth my time.
/Daniel
“Daniel Terhell” wrote in message
news:xxxxx@ntdev…
> Bob, I ran my test program and driver which takes all ntoskrnl exports and
> tested it with Mm and I can confirm that on XP x64 SP2 and Server 2003 x64
> SP2 with latest updates it gives consistent and meaningful addresses for
> all ntoskrnl exports and it doesn’t on SP1. So this must have got fixed
> either between SP1 and SP2 or by a Windows update. After that I wrote
> another test driver which throws garbage names at Mm, first a million
> times with alphanum chars only, then a million times with complety garbage
> unicode strings and also this test runs fine. It is worthwhile to test
> because millions of computers are relying on this code.
>
> Anyway, if you want a repro to test on SP1, it only takes five minutes to
> dump all exports from a module using tdump or depends and use a text
> editor to do a search and replace to create a test driver which DbgPrints
> all the routine names and addresses.
>
> /Daniel
>
>
>
> “Bob Kjelgaard” wrote in message
> news:xxxxx@ntdev…
> Well, I’ve satisfied myself that 64-bit XP at RTM is fine for this. I’ve
> hit valid and invalid cases and (e.g.) the invalid case
> “AxAllocatePoolWithBag” (well before either name in either binary) was
> NULL and I also checked several names that were valid, and I got the
> matching routine addresses.
>
> If somebody’s got an x64 repro where it returns NULL for a valid name or
> crashes, fine. Give me details I can hang something on (which OS and
> which name would really be good to have).
>
> I was going to hack together from my existing bag of code something to
> collect all the exports from both, pass them up to UM for a cheap
> conversion to Unicode, then back to KM so I could call the API for each,
> and check for null vs non-null returns (and also perturb each name so it
> would hit the before and after misses on each and every entry). If I
> owned this, that’d be my idea of a good black box test for it- or at least
> a starting place. But really, it’s a nice weekend, it would take most of
> the day [or longer] even though I’ve already got most of the pieces I’d
> need to start with, there’s plenty to do next week, and I’m finding it
> hard to believe this was ever broken there,
>
> I also waded through the revision control database to ferret out where the
> fix was made and where it went [not always easy, but usually possible if
> you’re persistent], and it was in server SP1 (which was the first x64 OS)
> well before it shipped. Vista was spun from that codebase, so unless
> someone was running the super-old Longhorn alphas [and I’m not sure they
> ever wandered outside the walls], I don’t see how that could have
> happened.
>
> Now I’ve been burned myself a few too many times by being flat-out wrong
> saying I had no repro without going to something like I described above
> [there might have been a compiler bug that only crops up on some
> particular call for some reason]. But I suspect that even the test holes
> were probably plugged a long time back by something like I just described,
> and nobody really needs me reinventing that wheel.
>
> I’m not saying the reports of this crashing on x64 aren’t real. But I
> don’t think there’s anything else that I or anyone else here can do
> without getting our hands on something that’s broken.
>
> Doron has already said he was trying to get QFE info for people who need
> it- I think that message got lost in all the noise. That might take a
> while (it would take me even longer, though, I’m sure).
>
>
I know that people who can actually do something about the issue are indeed working on it. So I’m going to leave any response in their much more capable hands. “I am so not helping…”
I rather believe that if I had been as well-rested and relaxed Thursday as I am today, I probably would have been wise enough to start from that position, but no time machine being available…
Hope to be smarter next time, I guess.
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.
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
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
>
>
How we would write our own version of MmGetSystemRoutineAddress you mean??
You need the lock to run the loaded module list, but YOU don’t need to take it out.
Consider ZwQuerySystemInformation for LoadedModuleInformation. It’ll take the lock, and return the loaded module list to the caller. Simplicity itself. Not reason to optimize code that’s rarely called, I say.
Peter
Please consider using AuxKlibQueryModuleInformation instead. It is documented and available in the WDK (library and header file).
Using ZwQuerySystemInformation’s undocumented features could result in problems for you in future versions (so I was warned by Doron himself [rather sternly, I might add] when I did exactly what you just said you’re going to do).
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Monday, June 04, 2007 7:35 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MmGetSystemRoutineAddress BugCheck?
How we would write our own version of MmGetSystemRoutineAddress you mean??
You need the lock to run the loaded module list, but YOU don’t need to take it out.
Consider ZwQuerySystemInformation for LoadedModuleInformation. It’ll take the lock, and return the loaded module list to the caller. Simplicity itself. Not reason to optimize code that’s rarely called, I say.
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
>>
Update: I found a virtual machine with Win2003 x64 SP1 and my thorough tests
did not show any problem either. So it must be SP0 where this problem
occured. I have no SP0 available here now. I’m sure this problem was there
before but it seems to have resolved in the service packs so it is of little
interest now and anyway it didn’t bugcheck, it only returned NULL on
exported functions so it wasn’t a major problem anyway. Drivers should be
able to handle these cases, otherwise why would they test for it anyway ? At
the time it was an annoyance because I couldn’t write the software I wanted
but the worst that could happen is that a driver on x64 SP0 is missing some
features or won’t work, it isn’t worth my time.
<<
There is no SP0 (RTM is our usual term) for x64- WS03 SP1 was the first x64 OS. An IA-64 machine with the RTM build will have this, though.
While I am not involved with the team working this, I did happen to have a brief e-mail exchange with one of its members earlier today, and it was confirmed (again) that WS03 SP1 and SP2 both have the proper fix.
But as I said earlier, my further involvement just muddies things- when they have their workaround recommendations and other guidance and such ready and reviewed, we’ll all know what it is.
Right, that is exactly why I did not want to use ZwQuerySystemInformation.
I didn’t know about AuxKlibQueryModuleInformation though. Thanks for the
info!!
Bill M.
“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
Please consider using AuxKlibQueryModuleInformation instead. It is
documented and available in the WDK (library and header file).
Using ZwQuerySystemInformation’s undocumented features could result in
problems for you in future versions (so I was warned by Doron himself
[rather sternly, I might add] when I did exactly what you just said you’re
going to do).
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Monday, June 04, 2007 7:35 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MmGetSystemRoutineAddress BugCheck?
How we would write our own version of MmGetSystemRoutineAddress you mean??
You need the lock to run the loaded module list, but YOU don’t need to take
it out.
Consider ZwQuerySystemInformation for LoadedModuleInformation. It’ll take
the lock, and return the loaded module list to the caller. Simplicity
itself. Not reason to optimize code that’s rarely called, I say.
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
Hmm…That’s a new one.
Appears to only be available in the Vista build environments though. So we
can only use it on Vista, where we don’t need the workaround 
-scott
–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Bill McKenzie” wrote in message
news:xxxxx@ntdev…
> Right, that is exactly why I did not want to use ZwQuerySystemInformation.
> I didn’t know about AuxKlibQueryModuleInformation though. Thanks for the
> info!!
>
> Bill M.
>
> “Bob Kjelgaard” wrote in message
> news:xxxxx@ntdev…
> Please consider using AuxKlibQueryModuleInformation instead. It is
> documented and available in the WDK (library and header file).
>
> Using ZwQuerySystemInformation’s undocumented features could result in
> problems for you in future versions (so I was warned by Doron himself
> [rather sternly, I might add] when I did exactly what you just said you’re
> going to do).
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
> Sent: Monday, June 04, 2007 7:35 PM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] MmGetSystemRoutineAddress BugCheck?
>
> How we would write our own version of MmGetSystemRoutineAddress you mean??
>
> You need the lock to run the loaded module list, but YOU don’t need to
> take it out.
>
> Consider ZwQuerySystemInformation for LoadedModuleInformation. It’ll take
> the lock, and return the loaded module list to the caller. Simplicity
> itself. Not reason to optimize code that’s rarely called, I say.
>
> 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
>
>
>
The library works downlevel just fine, the framework uses it all the way back to win2k.
D
-----Original Message-----
From: “Scott Noone”
To: “Windows System Software Devs Interest List”
Sent: 06/05/07 6:29 AM
Subject: Re:[ntdev] RE:MmGetSystemRoutineAddress BugCheck?
Hmm…That’s a new one.
Appears to only be available in the Vista build environments though. So we
can only use it on Vista, where we don’t need the workaround
-scott
–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Bill McKenzie” wrote in message
news:xxxxx@ntdev…
> Right, that is exactly why I did not want to use ZwQuerySystemInformation.
> I didn’t know about AuxKlibQueryModuleInformation though. Thanks for the
> info!!
>
> Bill M.
>
> “Bob Kjelgaard” wrote in message
> news:xxxxx@ntdev…
> Please consider using AuxKlibQueryModuleInformation instead. It is
> documented and available in the WDK (library and header file).
>
> Using ZwQuerySystemInformation’s undocumented features could result in
> problems for you in future versions (so I was warned by Doron himself
> [rather sternly, I might add] when I did exactly what you just said you’re
> going to do).
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
> Sent: Monday, June 04, 2007 7:35 PM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] MmGetSystemRoutineAddress BugCheck?
>
> How we would write our own version of MmGetSystemRoutineAddress you mean??
>
> You need the lock to run the loaded module list, but YOU don’t need to
> take it out.
>
> Consider ZwQuerySystemInformation for LoadedModuleInformation. It’ll take
> the lock, and return the loaded module list to the caller. Simplicity
> itself. Not reason to optimize code that’s rarely called, I say.
>
> 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
>
>
>
—
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
Hmmm… I’d never even HEARD of AuxKlibXxxx. Ya learn something every day.
Clearly, using something that’s documented is better than using something that’s not documented, if it does indeed work all the way back to Win2K Gold.
Peter
OSR
Peter Viscarola (OSR) wrote:
Hmmm… I’d never even HEARD of AuxKlibXxxx. Ya learn something every day.
Very interesting! This must be the most “sub-documented” (in luck of a better term) feature in Windows. If Peter didn’t know it, certainly it is almost unknown outside Microsoft.
In my installed copy of the MSDN Library, it is documented in Development Guides->Developer Notes->General. No wonder nobody found it In the on-line version it is now correctly part of the WDK reference section. (Weren’t we talking about nobody using the on-line version Unfortunately I don’t have older versions of the docs installed. It would be interesting to know when it appeared first (my guess is that very recently). My guess (please correct me if I am wrong) is that KMDF needed this feature and then it was officially implemented and documented.
According to the docs it works all the way down to Win95! Yes, it is possible that it is misplaced in the latest WDK, the library is located only in the Vista tree. But this is actually a static library implementation. I didn’t verify, but by using DUMPBIN on the library, it seems internally it uses ZwQuerySystemInformation.
Being a static library (which means an update won’t help for drivers already shipped), and internally still using undocumented features, I wonder how Ms will deal with this in the future. The library imports MmGetSystemRoutineAddress, guess this is somehow used for this purpose. Didn’t check exactly which names are passed to it. But what would happen if it queries for a routine that starts with _Aux?
Auxklib existed before KMDF, although there were functions added to it
that the KMDF team asked for.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@rahul.net
Sent: Tuesday, June 05, 2007 9:01 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MmGetSystemRoutineAddress BugCheck?
Peter Viscarola (OSR) wrote:
Hmmm… I’d never even HEARD of AuxKlibXxxx. Ya learn something every
day.
Very interesting! This must be the most “sub-documented” (in luck of a
better term) feature in Windows. If Peter didn’t know it, certainly it
is almost unknown outside Microsoft.
In my installed copy of the MSDN Library, it is documented in
Development Guides->Developer Notes->General. No wonder nobody found it
In the on-line version it is now correctly part of the WDK reference
section. (Weren’t we talking about nobody using the on-line version
Unfortunately I don’t have older versions of the docs installed. It
would be interesting to know when it appeared first (my guess is that
very recently). My guess (please correct me if I am wrong) is that KMDF
needed this feature and then it was officially implemented and
documented.
According to the docs it works all the way down to Win95! Yes, it is
possible that it is misplaced in the latest WDK, the library is located
only in the Vista tree. But this is actually a static library
implementation. I didn’t verify, but by using DUMPBIN on the library, it
seems internally it uses ZwQuerySystemInformation.
Being a static library (which means an update won’t help for drivers
already shipped), and internally still using undocumented features, I
wonder how Ms will deal with this in the future. The library imports
MmGetSystemRoutineAddress, guess this is somehow used for this purpose.
Didn’t check exactly which names are passed to it. But what would happen
if it queries for a routine that starts with _Aux?
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
aux_klib.h says the following: “Kernel mode shim to access system
functionality that is not properly exposed to applications in currently
shipping operating systems.” however there’s not written in which module we
can find these functions, they are not ntoskrnl exports.
/Daniel
“Scott Noone” wrote in message news:xxxxx@ntdev…
> Hmm…That’s a new one.
>
> Appears to only be available in the Vista build environments though. So we
> can only use it on Vista, where we don’t need the workaround
>
> -scott
>
> –
> Scott Noone
> Software Engineer
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
>
> “Bill McKenzie” wrote in message
> news:xxxxx@ntdev…
>> Right, that is exactly why I did not want to use
>> ZwQuerySystemInformation. I didn’t know about
>> AuxKlibQueryModuleInformation though. Thanks for the info!!
>>
>> Bill M.
>>
>> “Bob Kjelgaard” wrote in message
>> news:xxxxx@ntdev…
>> Please consider using AuxKlibQueryModuleInformation instead. It is
>> documented and available in the WDK (library and header file).
>>
>> Using ZwQuerySystemInformation’s undocumented features could result in
>> problems for you in future versions (so I was warned by Doron himself
>> [rather sternly, I might add] when I did exactly what you just said
>> you’re going to do).
>>
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
>> Sent: Monday, June 04, 2007 7:35 PM
>> To: Windows System Software Devs Interest List
>> Subject: RE:[ntdev] MmGetSystemRoutineAddress BugCheck?
>>
>> How we would write our own version of MmGetSystemRoutineAddress you
>> mean??
>>
>> You need the lock to run the loaded module list, but YOU don’t need to
>> take it out.
>>
>> Consider ZwQuerySystemInformation for LoadedModuleInformation. It’ll
>> take the lock, and return the loaded module list to the caller.
>> Simplicity itself. Not reason to optimize code that’s rarely called, I
>> say.
>>
>> 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
>>
>>
>>
>
>
>