I just encountered this nice bug. I’m using WDK 6000; is it already fixed in the latest 6001 build?
Fortunately, searching list archives quickly confirmed what I see in disassembly isn’t because I’m too tired or crazy. I only wonder if Wdmlib implementation was ever tested 
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, November 06, 2007 12:33 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] RtlIsServicePackVersionInstalled issue?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.