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.
Can you send a callstack? And yes, it should return NULL and not blow
up. Just to verify, you are calling at IRQL==PASSIVE_LEVEL right?
Thx
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Wednesday, May 30, 2007 12:02 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] MmGetSystemRoutineAddress BugCheck?
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
Well, it better not blue screen… We use it heavily in several drivers.
What error code and what stack do you get on the BSOD?
You ARE calling it at IRQL PASSIVE_LEVEL, yes??
Peter
Bugcheck and Analysis:
*** Fatal System Error: 0x0000007e
(0xC0000005,0x805C9A77,0xF789E42C,0xF789E128)
Break instruction exception - code 80000003 (first chance)
A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.
A fatal system error has occurred.
Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE
Loading Kernel Symbols
.............................
Loading User Symbols
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 7E, {c0000005, 805c9a77, f789e42c, f789e128}
Probably caused by : MyDrv.sys ( MyDrv!MyDrvMethod+da )
nt!RtlpBreakWithStatusInstruction:
804e2a52 cc int 3
0: kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************
SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 805c9a77, The address that the exception occurred at
Arg3: f789e42c, Exception Record Address
Arg4: f789e128, Context Record Address
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx"
referenced memory at "0x%08lx". The memory could not be "%s".
FAULTING_IP:
nt!MiFindExportedRoutineByName+51
805c9a77 8b348a mov esi,dword ptr [edx+ecx*4]
EXCEPTION_RECORD: f789e42c -- (.exr fffffffff789e42c)
ExceptionAddress: 805c9a77 (nt!MiFindExportedRoutineByName+0x00000051)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 00718094
Attempt to read from address 00718094
CONTEXT: f789e128 -- (.cxr fffffffff789e128)
eax=e1021e28 ebx=80562443 ecx=1fffffff edx=80718098 esi=80705ab8
edi=3ffffffe
eip=805c9a77 esp=f789e4f4 ebp=f789e514 iopl=0 nv up ei pl nz na pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010206
nt!MiFindExportedRoutineByName+0x51:
805c9a77 8b348a mov esi,dword ptr [edx+ecx*4]
ds:0023:00718094=????????
Resetting default scope
DEFAULT_BUCKET_ID: DRIVER_FAULT
PROCESS_NAME: System
ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced
memory at "0x%08lx". The memory could not be "%s".
READ_ADDRESS: 00718094
BUGCHECK_STR: 0x7E
LAST_CONTROL_TRANSFER: from 805cb097 to 805c9a77
STACK_TEXT:
f789e514 805cb097 806fd000 e1021e28 f789e59e
nt!MiFindExportedRoutineByName+0x51
f789e550 f743ba2a f789e5bc 89be3fc8 00000000
nt!MmGetSystemRoutineAddress+0xab
f789e5c4 f743721d 89bb8530 00000000 002a0028 MyDrv!MyDrvMethod+0xda
f789e5ec 806b7b15 89bb8928 80095900 80095900 MyDrv!DriverEntry+0x20d
f789e62c 806b7c2a 89bb89dc 80095900 00000018
nt!IopInitializeBuiltinDriver+0x260
f789e690 806adfa1 80087000 f789e6ac 00034000
nt!IopInitializeBootDrivers+0x2d2
f789e838 806af012 80087000 00000000 89bfb5b8 nt!IoInitSystem+0x712
f789edac 80574128 80087000 00000000 00000000 nt!Phase1Initialization+0xac7
f789eddc 804ec791 806ae7bf 80087000 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
FOLLOWUP_IP:
MyDrv!MyDrvMethod+da
f743ba2a 8945f4 mov dword ptr [ebp-0Ch],eax
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: MyDrv!MyDrvMethod+da
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: MyDrv
IMAGE_NAME: MyDrv.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 465de0dd
STACK_COMMAND: .cxr 0xfffffffff789e128 ; kb
FAILURE_BUCKET_ID: 0x7E_MyDrv!MyDrvMethod+da
BUCKET_ID: 0x7E_MyDrv!MyDrvMethod+da
Code that caused it:
PCRED_CMREGISTERCALLBACKEX cmFunc;
WCHAR funcName =
L"CmRegisterCallbackEx";
UNICODE_STRING funcNameStr;
RtlInitUnicodeString(&funcNameStr, funcName);
ASSERT(KeGetCurrentIrql() == PASSIVE_LEVEL);
if (1) //(DeviceExtension->WindowsVersion >= WINVER_VISTA)
{
// Don't allow the following call on any system prior to Vista
// or a bugcheck will result. Nice huh?
if (cmFunc =
(PCRED_CMREGISTERCALLBACKEX)MmGetSystemRoutineAddress(&funcNameStr))
{
Bill M.
"Doron Holan" wrote in message
news:xxxxx@ntdev...
Can you send a callstack? And yes, it should return NULL and not blow
up. Just to verify, you are calling at IRQL==PASSIVE_LEVEL right?
Thx
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Wednesday, May 30, 2007 12:02 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] MmGetSystemRoutineAddress BugCheck?
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
ListServer/Forum
Ah, and now the reason for your question becomes clear. The first parameter to MiFindExportedRoutineByName is ZERO? Hmmm… That doesn’t look good to me.
In your crash, 0x00718094 should be a pointer to an ANSI_STRING. Does this point to a string containing “CmRegisterCallbackEx”??
Most puzzling,
Peter
Right…it looks like something went wrong between here and there. When I
call MmGetSystemRoutineAddress it has a valid PUNICODE_STRING paramter whose
Buffer does contain “CmRegisterCallbackEx”. In fact, if I break in the
debugger and shorten the unicode pointer, funcNameStr, Length parameter by 4
bytes making the unicode string contain “CmRegisterCallback” instead of
“CmRegisterCallbackEx”, everything works fine.
Bill M.
wrote in message news:xxxxx@ntdev…
> Ah, and now the reason for your question becomes clear. The first
> parameter to MiFindExportedRoutineByName is ZERO? Hmmm… That doesn’t
> look good to me.
>
> In your crash, 0x00718094 should be a pointer to an ANSI_STRING. Does
> this point to a string containing “CmRegisterCallbackEx”??
>
> Most puzzling,
>
> Peter
>
>
Oh, and to answer your question, I believe 0x00718094 is just garbage. I
can’t read from that location.
Bill M.
wrote in message news:xxxxx@ntdev…
> Ah, and now the reason for your question becomes clear. The first
> parameter to MiFindExportedRoutineByName is ZERO? Hmmm… That doesn’t
> look good to me.
>
> In your crash, 0x00718094 should be a pointer to an ANSI_STRING. Does
> this point to a string containing “CmRegisterCallbackEx”??
>
> Most puzzling,
>
> Peter
>
>
Bill McKenzie wrote:
STACK_TEXT:
f789e514 805cb097 806fd000 e1021e28 f789e59e
nt!MiFindExportedRoutineByName+0x51
f789e550 f743ba2a f789e5bc 89be3fc8 00000000
nt!MmGetSystemRoutineAddress+0xab
f789e5c4 f743721d 89bb8530 00000000 002a0028 MyDrv!MyDrvMethod+0xda
f789e5ec 806b7b15 89bb8928 80095900 80095900 MyDrv!DriverEntry+0x20d
f789e62c 806b7c2a 89bb89dc 80095900 00000018
nt!IopInitializeBuiltinDriver+0x260
f789e690 806adfa1 80087000 f789e6ac 00034000
nt!IopInitializeBootDrivers+0x2d2
f789e838 806af012 80087000 00000000 89bfb5b8 nt!IoInitSystem+0x712
f789edac 80574128 80087000 00000000 00000000 nt!Phase1Initialization+0xac7
f789eddc 804ec791 806ae7bf 80087000 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
So, this is a boot driver? Did we know that before? Does that make a
difference?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> So, this is a boot driver? Did we know that before? Does that make a
difference?
Why would that make a difference in this call?
It was a boot driver, I modified it not to be and same result.
It’s a real easy test if anyone would like to try this on their own. Just
call MmGetSystemRoutineAddress for “CmRegisterCallbackEx”. Actually, and I
haven’t had the bandwidth to test this out, I suspect this will crash for
any method name that doesn’t exist.
Bill M.
“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Bill McKenzie wrote:
>> STACK_TEXT:
>> f789e514 805cb097 806fd000 e1021e28 f789e59e
>> nt!MiFindExportedRoutineByName+0x51
>> f789e550 f743ba2a f789e5bc 89be3fc8 00000000
>> nt!MmGetSystemRoutineAddress+0xab
>> f789e5c4 f743721d 89bb8530 00000000 002a0028 MyDrv!MyDrvMethod+0xda
>> f789e5ec 806b7b15 89bb8928 80095900 80095900 MyDrv!DriverEntry+0x20d
>> f789e62c 806b7c2a 89bb89dc 80095900 00000018
>> nt!IopInitializeBuiltinDriver+0x260
>> f789e690 806adfa1 80087000 f789e6ac 00034000
>> nt!IopInitializeBootDrivers+0x2d2
>> f789e838 806af012 80087000 00000000 89bfb5b8 nt!IoInitSystem+0x712
>> f789edac 80574128 80087000 00000000 00000000
>> nt!Phase1Initialization+0xac7
>> f789eddc 804ec791 806ae7bf 80087000 00000000
>> nt!PspSystemThreadStartup+0x34
>> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>>
>
> So, this is a boot driver? Did we know that before? Does that make a
> difference?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
Just for kicks I tried a variation on it, and I it works as expected for
me on 6001-x64-CHK. The variation was necessary because
“CmRegisterCallbackEx” exists on Vista, so I called
MmGetSystemRoutineAddress() on "CmRegisterCallback,’
‘CmRegisterCallbackEx,’ and ‘NonOneHome.’ The first to were resolved,
and the last one returned NULL, without a blue screen.
I think you need to look at your own code, and perhaps post it, because
what you’re suggesting - that a call to MmGetSystemRoutineAddress() with
any invalid name causes a bluescreen and that no one has ever noticed
this before - is a little hasty, particularly as you provided almost no
information.
mm
>> xxxxx@sbcglobal.net 2007-05-30 21:48:22 >>>
So, this is a boot driver? Did we know that before? Does that make
a
difference?
Why would that make a difference in this call?
It was a boot driver, I modified it not to be and same result.
It’s a real easy test if anyone would like to try this on their own.
Just
call MmGetSystemRoutineAddress for “CmRegisterCallbackEx”. Actually,
and I
haven’t had the bandwidth to test this out, I suspect this will crash
for
any method name that doesn’t exist.
Bill M.
“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Bill McKenzie wrote:
>> STACK_TEXT:
>> f789e514 805cb097 806fd000 e1021e28 f789e59e
>> nt!MiFindExportedRoutineByName+0x51
>> f789e550 f743ba2a f789e5bc 89be3fc8 00000000
>> nt!MmGetSystemRoutineAddress+0xab
>> f789e5c4 f743721d 89bb8530 00000000 002a0028 MyDrv!MyDrvMethod+0xda
>> f789e5ec 806b7b15 89bb8928 80095900 80095900
MyDrv!DriverEntry+0x20d
>> f789e62c 806b7c2a 89bb89dc 80095900 00000018
>> nt!IopInitializeBuiltinDriver+0x260
>> f789e690 806adfa1 80087000 f789e6ac 00034000
>> nt!IopInitializeBootDrivers+0x2d2
>> f789e838 806af012 80087000 00000000 89bfb5b8 nt!IoInitSystem+0x712
>> f789edac 80574128 80087000 00000000 00000000
>> nt!Phase1Initialization+0xac7
>> f789eddc 804ec791 806ae7bf 80087000 00000000
>> nt!PspSystemThreadStartup+0x34
>> 00000000 00000000 00000000 00000000 00000000
nt!KiThreadStartup+0x16
>>
>
> So, this is a boot driver? Did we know that before? Does that make
a
> difference?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
—
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
I am only seeing this on XP SP2…sorry to not provide this info before, but
I wasn’t sure this is the only place I was going to see it. I haven’t
tested previous XP versions or any 2000 versions, but Vista definitely does
NOT exhibit this behavior.
I think you need to look at your own code, and perhaps post it, because
what you’re suggesting - that a call to MmGetSystemRoutineAddress() with
any invalid name causes a bluescreen and that no one has ever noticed
this before - is a little hasty, particularly as you provided almost no
information.
Thanks, but did that. Perhaps you haven’t followed the complete thread.
Perhaps you should try this on XP SP2 and report back??
Bill M.
“Martin O’Brien” wrote in message
news:xxxxx@ntdev…
> Just for kicks I tried a variation on it, and I it works as expected for
> me on 6001-x64-CHK. The variation was necessary because
> “CmRegisterCallbackEx” exists on Vista, so I called
> MmGetSystemRoutineAddress() on "CmRegisterCallback,'
> ‘CmRegisterCallbackEx,’ and ‘NonOneHome.’ The first to were resolved,
> and the last one returned NULL, without a blue screen.
>
> I think you need to look at your own code, and perhaps post it, because
> what you’re suggesting - that a call to MmGetSystemRoutineAddress() with
> any invalid name causes a bluescreen and that no one has ever noticed
> this before - is a little hasty, particularly as you provided almost no
> information.
>
> mm
>
>
>
>>>> xxxxx@sbcglobal.net 2007-05-30 21:48:22 >>>
>> So, this is a boot driver? Did we know that before? Does that make
> a
>> difference?
>
> Why would that make a difference in this call?
>
> It was a boot driver, I modified it not to be and same result.
>
> It’s a real easy test if anyone would like to try this on their own.
> Just
> call MmGetSystemRoutineAddress for “CmRegisterCallbackEx”. Actually,
> and I
> haven’t had the bandwidth to test this out, I suspect this will crash
> for
> any method name that doesn’t exist.
>
> Bill M.
>
> “Tim Roberts” wrote in message news:xxxxx@ntdev…
>> Bill McKenzie wrote:
>>> STACK_TEXT:
>>> f789e514 805cb097 806fd000 e1021e28 f789e59e
>>> nt!MiFindExportedRoutineByName+0x51
>>> f789e550 f743ba2a f789e5bc 89be3fc8 00000000
>>> nt!MmGetSystemRoutineAddress+0xab
>>> f789e5c4 f743721d 89bb8530 00000000 002a0028 MyDrv!MyDrvMethod+0xda
>>> f789e5ec 806b7b15 89bb8928 80095900 80095900
> MyDrv!DriverEntry+0x20d
>>> f789e62c 806b7c2a 89bb89dc 80095900 00000018
>>> nt!IopInitializeBuiltinDriver+0x260
>>> f789e690 806adfa1 80087000 f789e6ac 00034000
>>> nt!IopInitializeBootDrivers+0x2d2
>>> f789e838 806af012 80087000 00000000 89bfb5b8 nt!IoInitSystem+0x712
>>> f789edac 80574128 80087000 00000000 00000000
>>> nt!Phase1Initialization+0xac7
>>> f789eddc 804ec791 806ae7bf 80087000 00000000
>>> nt!PspSystemThreadStartup+0x34
>>> 00000000 00000000 00000000 00000000 00000000
> nt!KiThreadStartup+0x16
>>>
>>
>> So, this is a boot driver? Did we know that before? Does that make
> a
>> difference?
>>
>> –
>> Tim Roberts, xxxxx@probo.com
>> Providenza & Boekelheide, Inc.
>>
>>
>
>
>
> —
> 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
>
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.
>
>
BTW I am not sure it got fixed, this is just a speculation based on the fact
that I could not reproduce the problems I got with it before. Not until
there is a service packs which deals with all the problems with this
function on all the OSes or there is a way to detect you got a good version
I think it should not be used at all.
/Daniel
“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.
>>
>>
>
>
Don’t post a link or anything 
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?
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.
>>
>>
>
>
>
Don’t post a link or anything
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?
It is possible :-).
Lets say, OCA gathered 1Million crashes. Lets further say, that every
crash that occured using this api had been tagged on the OCa database. Now
out of these crashes lets say 50% is for the right use of API and 50% due
to passing bad args or bad irql. Now if the percentage of this is quite
low, and we take the half of it, it would be pretty insignificant. At a
casino, I would bet that it is insignificant
-pro
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
>
I am almost speechless. Microsoft has been lecturing us (and for good
reasons) for years now regarding the shitty quality of our drivers. They
consequently have an obligation (that operates outside of cost benefit
analysis for triaging bug fix resources) to not increase that shittiness
by having shitty apis that cause our shitty drivers to crash even when
they are doing things right.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@garlic.com
Sent: Thursday, May 31, 2007 10:11 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] MmGetSystemRoutineAddress BugCheck?
Don’t post a link or anything
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?
It is possible :-).
Lets say, OCA gathered 1Million crashes. Lets further say, that every
crash that occured using this api had been tagged on the OCa database.
Now
out of these crashes lets say 50% is for the right use of API and 50%
due
to passing bad args or bad irql. Now if the percentage of this is quite
low, and we take the half of it, it would be pretty insignificant. At a
casino, I would bet that it is insignificant
-pro
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
>
—
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
Here some references from ntfsd group …
http://www.osronline.com/showThread.cfm?link=80593
http://www.osronline.com/showThread.cfm?link=101536
“Roddy, Mark” wrote in message news:xxxxx@ntdev…
I am almost speechless. Microsoft has been lecturing us (and for good
reasons) for years now regarding the shitty quality of our drivers. They
consequently have an obligation (that operates outside of cost benefit
analysis for triaging bug fix resources) to not increase that shittiness
by having shitty apis that cause our shitty drivers to crash even when
they are doing things right.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@garlic.com
Sent: Thursday, May 31, 2007 10:11 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] MmGetSystemRoutineAddress BugCheck?
>
> Don’t post a link or anything
>
> 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?
It is possible :-).
Lets say, OCA gathered 1Million crashes. Lets further say, that every
crash that occured using this api had been tagged on the OCa database.
Now
out of these crashes lets say 50% is for the right use of API and 50%
due
to passing bad args or bad irql. Now if the percentage of this is quite
low, and we take the half of it, it would be pretty insignificant. At a
casino, I would bet that it is insignificant
-pro
>
> 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
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Bill McKenzie wrote:
I am only seeing this on XP SP2…sorry to not provide this info before, but
I wasn’t sure this is the only place I was going to see it. I haven’t
tested previous XP versions or any 2000 versions, but Vista definitely does
NOT exhibit this behavior.
A quick web search shows this exact problem being reported against
Windows 2000 SP4 on this very mailing list in June of 2005.
http://www.osronline.com/showThread.cfm?link=101536
The responder suggests that it was fixed in “some service pack” to XP,
although your evidence suggests this is not the case.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
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)
>>(in the meantime, I think I’ll pass this along to Hector to write a memo
about)
Throw’n down the gloves, eh?
-dc