- Has Driver Verifier gone too far? bug check C4.81
- Posted by 440gtx on October 13th, 2003
First off, I love tools that can find problems in my code and driver
verifier with max settings is one of my favorites. Great tool!
However, I was surprised to see driver verifier reject a driver
because it uses MmMapLockedPages. It says MmMapLockedPagesSpecifyCache
should be used instead. The problem is the driver binary is designed
for all WDM environments; both Win9x & NT. Changing to the newer
function call breaks loading in all Win9x os's. It seems a real shame
for driver verifier to be the thing that breaks WDM binary
compatibility. If the OS no longer exports a function, that would be
fine. Why have verifier break the driver prematurely? I have a
suggestion to Microsoft. I think you can handle obsolete functions in
a smarter way without getting in the way of driver binary
compatibility. This is something that's going to be happening more and
more. So while now you are only rattling the cages of those evil few
still shipping product for Win9x, surely even todays "latest" drivers
designed for XP at some point are going to have what are considered
obsolete functions. Here are some options:
1. At compile time generate a deprecated warning when an obsolete
function is called. This is how Windows SDK works. The warnings would
be driven off 2 new preprocessor defines. WDM_MIN_VER=0x0100 and
WDM_MAX_VER=0x0130 (examples for a WDM driver needing compatibility
between Win98 and Win2003 based on the IoIsWdmVersionAvailable
values). These 2 defines would default to whatever Microsoft believes
is appropriate for the particular DDK release.
2. Have driver verifier check the version in the exe image in memory
to know which obsolete functions to bug check (i.e. key off -version
link flag).
The advantage of solution #1 is the developer discovers the problem
instantly. Driver verifier only detects it if that particular piece of
code actually gets run and maybe it doesn't if the test matrix does
not get code coverage over it. By the time driver verifier does see
it, engineering/QA may have invested a fair amount of time into
obsolete API's.
- Posted by Alexander Grigoriev on October 13th, 2003
Build two different binaries for Win9x and 2K/XP. It's easy to get the
proper binary installed, even if a single INF is used for both Win9x and
2K/XP.
There is a reason MMLP is deprecated - it causes a bugcheck on failure. You
don't want your driver to bugcheck in low resources conditions, do you?
"440gtx" <440gtx@email.com> wrote in message
news:3ae09baa.0310121917.4e151d81@posting.google.c om...
- Posted by Leo Havmøller on October 13th, 2003
"> There is a reason MMLP is deprecated - it causes a bugcheck on failure.
You
I certainly dont. I had the impression that setting MDL_MAPPING_CAN_FAIL in
the MdlFlags would prevent the bugcheck and make MmMapLockedPages just
return NULL instead?
Leo Havmøller.
- Posted by Maxim S. Shatskih on October 13th, 2003
Yes. I even wrote the MmGetSystemAddressForMdlSafe macro for NT4 this way.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com
- Posted by Callas on October 13th, 2003
alegr@earthlink.net wrote:
I thought you could bracket MMP&LP with __try/__except?
--
Callas
- Posted by Mark Roddy on October 13th, 2003
On Mon, 13 Oct 2003 08:30:03 +0100, Callas <callas@summerblue.net>
wrote:
Well you can, but that won't stop the bugcheck :-)
=====================
Mark Roddy
Windows XP/2000/NT Consulting, Microsoft DDK MVP
Hollis Technology Solutions 603-321-1032
www.hollistech.com
markr@hollistech.com
For Windows Device Driver Training: see www.azius.com
- Posted by Walter Oney on October 13th, 2003
440gtx wrote:
I describe a binary portable workaround for this problem on p. 424 of my
book. Verifier will accept a driver that uses this trick.
--
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com
