RE: INACCESSIBLE_BOOT_DEVICE using diskperf.sys DDK sampl e

Yes indeed. Why actually try to find out what the problem is when you can
just substitute random compilers until the problem magically disappears?
Thanks for clearing that up for me Alberto, I’m chucking the ddk tools into
the trashcan right now.

=====================
Mark Roddy

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alberto Moreira
Sent: Tuesday, May 17, 2005 8:50 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] INACCESSIBLE_BOOT_DEVICE using diskperf.sys DDK sample

But the OP is saying that /Oi fixes the problem, no ? It’s odd that /Oi and
/Od seem to row in opposite directions, and yet both apparently solve the
issue.

The /Oi switch generates inline code for a few selected functions, rather
than calling their library function counterparts; it’s a performance
optimization. If you lookup your MSVC help for “pragma intrinsic” or for
“/Oi” you’ll see them listed in the “intrinsic” document. If the driver
doesn’t load without /Oi, it could be that the code is generating a call to
some of those functions, and the function(s) are doing something in their
library code that is avoided by the compiler-generated inline code.

Now, it looks like /Od should aggravate the problem, unless of course some
optimization is generating questionable code in the vicinity of that
function call, and /Od avoids the pitfall altogether; it may also be the
case that /Oi generates inline code which changes the optimization landscape
in that general vicinity, and the problem is also avoided altogether.

I’d be tempted to call it a compiler bug, but I’d dig till I find the real
reason.

The OP can disable linker lookups of the standard C libraries and look at
what symbols are left unresolved; match them against the list of functions
in that “intrinsic” document, and try to write code that avoids calling
those functions.

Another thing to do: compile without /Oi and /Od and link against the debug
libraries (for example, msvcrtd.lib) and see if the problem goes away.
Or, once you identify the offending function, see if you can get the source
code from the CRT directory, tweak it, and again, see if you can make the
problem go away.

Also, one heretical suggestion: if possible, build the code with
(1) MSVC version 6 plus SP6, (2) MSVC.NET 2003 compiler, (3) MSVC.NET 2005
compiler, and see if the problem evolves and how.
You see, it’s in situations like this that being able to build one’s code
with more than one development environment may make the difference between
an unstable driver and a stable one.

Alberto.

----- Original Message -----
From: “Gary G. Little”
To: “Windows System Software Devs Interest List”

Sent: Monday, May 16, 2005 11:26 PM
Subject: RE: [ntdev] INACCESSIBLE_BOOT_DEVICE using diskperf.sys DDK sample

Driver’s have problems with optimizing compilers, or maybe it’s optimizing
compilers have problems building drivers. I’ve gotten to the point that I
only set Oi if I set anything at all.

Gary

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Fred
Sent: Monday, May 16, 2005 6:39 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] INACCESSIBLE_BOOT_DEVICE using diskperf.sys DDK sample

Follow up information: I can get my filter driver to load if I add either
/Oi or /Od to the MSC_OPTIMIZATION environment variable in the DDK’s
setenv.bat for a ‘fre’ build.

/Oi - Enable intrinsic functions
/Od - Disable optimization (default)

Any ideas on why including these settings “fix” my driver load issues?

Thanks!

“Fred” wrote in message news:xxxxx@ntdev…
> I’ve created an upper-filter driver based on the diskperf.sys sample
> in the DDK. For some reason, the free version of my driver will not
> load on Windows 2000; although checked version works fine and both the
> checked and

> free versions work fine on Windows XP. I ran dumpbin on both the
> checked and free versions of my driver and the free version doesn’t
> contain any imports which are not in the checked vesion (it appears to
> be a subset).
> So, I don’t see any dependencies that would cause the load to fail.
>
> I’ve compiled both the free and checked versions of the original
> diskperf.sys sample and they load okay on Windows 2000. So this load
> error is specific to my driver.
>
> Windbg doesn’t appear to give me much detail: I can see the name of
> the primary boot device (which my driver is attached to) which failed
> to load.

> And using “lm” I can see that my driver never loaded. But, my
> DriverEntry

> routine was never called.
>
> I assume this is an import dependency issue…but don’t see any.
>
> Any ideas?
> Thanks!
>
>
>
>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: glittle@mn.rr.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

NOD32 1.1099 (20050516) Information

This message was checked by NOD32 antivirus system.
http://www.nod32.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com