If you can provide more information, it would be helpful:
- When the IoCreateDevice fails, what is the error/status code?
- What OS you are running on? XP? Does the same problem happen on other
OSs?
- What kind of driver is it? How/where do you call IoCreateDevice?
- Have you tried with a debugger to break in?


This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
Content-Class: urn:content-classes:message
From: "Eric" <errivera@praxiseng.com>
Sender: "Eric" <errivera@praxiseng.com>
Subject: IoCreateDevice fails
Date: Tue, 23 Sep 2003 06:33:45 -0700
Lines: 14
Message-ID: <146c01c381d7$5025eb80$a101280a@phx.gbl>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Newsreader: Microsoft CDO for Windows 2000
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Thread-Index: AcOB11AjA21V3hwKQniNcvAMOtnjqw==
Newsgroups: microsoft.public.development.device.drivers
Path: cpmsftngxa06.phx.gbl
Xref: cpmsftngxa06.phx.gbl microsoft.public.development.device.drivers:31313
NNTP-Posting-Host: TK2MSFTNGXA09 10.40.1.161
X-Tomcat-NG: microsoft.public.development.device.drivers

Hi,

My problem is the following:

A call to IoCreateDevice works fine on a driver built
using the "checked build environment" but fails on a the
same driver built using the "free build environment"

I'm using the "windows XP Service Pack 1 Driver
Development Kit"

Any Idea?

Eric

Looks like a pointer and not status code.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

My bad. That's true, it is a pointer.
Anyways, Do youy have any idea why my check build works
and the free build doesn't?

Eric
*************************************************

I made another change that could be a better solution:
set MSC_OPTIMIZATION=/Ox /Oi

This way my code is fully optimized, Debug is not enabled,
my .sys file is a way smaller than the checked version
andjust a litter larger than my free version.

So it seems that not using the /Oi flag when compiling was
causing the free build to create a driver where my
IoCreateDevice function was failing.

Although I'd still like to know the source of my error
Why it fails when /Oi is not used?

Eric

"Eric" <errivera@praxiseng.com> wrote in message
news:1f8801c38362$39850b40$a401280a@phx.gbl...
/Oi enables intrinsic functions, which means that some common functions like
strlen or memcpy can be inlined assembly, instead of a function call.
However, /Ox says it includes /Oi, so I'm a bit surprised that you need it.
If you get different binaries using /Ox with and without /Oi, that's a bug
in the compiler or the documentation, and you could have the pleasure of
reporting it to Microsoft.

There is some control over what gets inlined with the #pragma intrinsic()
directive.

Do you have any #pragma intrinsic() directives anywhere? I remember back in
2000 running into a problem with that. The pragma appears to affect the
linker more than the compiler, as the compiler never inlined the function in
the absence of /Oi. However, the linker didn't complain, because the pragma
told it not to. The function just "diappeared". You can find a lot of my
moaning about it in the NTDEV archive. At the time, I had no idea how to
submit such a thing to Microsoft as a bug, so if you find that this is still
the problem, please do submit it, will you?

Phil
--
Philip D. Barila Windows DDK MVP
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.
E-mail address is pointed at a domain squatter. Use reply-to instead.

If you would post your apparently failing IoCreateDevice operation,
along with everything reference by same, we might have a hope of
advising you.

Eric wrote:

--
If replying by e-mail, please remove "nospam." from the address.

James Antognini
Windows DDK MVP

Dear Eric:

One of the development people added this insight into what your problem
could be:

"String and memory functions supported by runtime library calls must be
replaced by the compiler since the DDK build environment does not support
calling or initializing the user mode runtime C library. The /Oi compiler
switch request that the compiler insert code to handle these functions
directly into the executable rather than creating a call to the support
library."

Some functions that are affected:

_disable _outp fabs strcmp
_enable _outpw labs strcpy
_inp _rotl memcmp strlen
_inpw _rotr memcpy
_lrotl _strset memset
_lrotr abs strcat

You may want to generate a MAP file and a source/assembly listing and then
compare the with and without /Oi versions.

Best Regards,

Dan

This posting is provided "AS IS" with no warranties, and confers no rights.

The primary suspect would be compiler's optimization of the string
initialization.
Actually, you don't need to initialize a string on stack. Just pass the
string constant to RtlInitUnicodeString.

"Eric" <errivera@praxiseng.com> wrote in message
news:1f8801c38362$39850b40$a401280a@phx.gbl...