file opening in a mixed-mode solution

[Lee Crabtree]

I've got a solution that has a C++ project that compiles to a DLL, and a
C# project that is the main piece of the program.

The DLL is managed C++ on top of regular C++. In one of the native
functions, I make a call that looks a little like this:

file = _fsopen(path, mode, SH_DENYNO);

That call generates a System.NullReferenceException, which makes
ABSOLUTELY no sense, since it's happening in unmanaged code. On top of
all that, both the path and mode are correctly set.

What am I doing wrong?

Lee

 

[Lee Crabtree]

I've got a solution that has a C++ project that compiles to a DLL, and a
C# project that is the main piece of the program.

The DLL is managed C++ on top of regular C++. In one of the native
functions, I make a call that looks a little like this:

file = _fsopen(path, mode, SH_DENYNO);

That call generates a System.NullReferenceException, which makes
ABSOLUTELY no sense, since it's happening in unmanaged code. On top of
all that, both the path and mode are correctly set.

What am I doing wrong?

Lee

Some experimentation has shown that it's got something to do with where
the file is located. If it's in the same directory as the executable
(so that the path is ".\\file.ext"), it works. Likewise, if the file is
in the root (so that the path is "c:\\file.ext"), there's no problem.
However, in any other folder (where the path is something like
"c:\\dir\\file.ext"), there's a System.NullReferenceException.

I've checked permissions already, so that's not it. I'm completely at a
loss here.

Lee

 

[Carl Daniel [VC++ MVP]]

I've got a solution that has a C++ project that compiles to a DLL, and a
C# project that is the main piece of the program.

The DLL is managed C++ on top of regular C++. In one of the native
functions, I make a call that looks a little like this:

file = _fsopen(path, mode, SH_DENYNO);

That call generates a System.NullReferenceException, which makes
ABSOLUTELY no sense, since it's happening in unmanaged code. On top of
all that, both the path and mode are correctly set.

What am I doing wrong?

Just a guess... but most likely, you've misdiagnosed where the exception is
coming from, because you're absolutely right - getting a managed exception
out of a native library function makes no sense.

Are you absolutely 100% sure that's where the exception is coming from?

-cd

 

[Lee Crabtree]

Just a guess... but most likely, you've misdiagnosed where the exception is
coming from, because you're absolutely right - getting a managed exception
out of a native library function makes no sense.

Are you absolutely 100% sure that's where the exception is coming from?

-cd

I'm stepping through one at a time, and that line is what always
triggers it.

Lee

 

[Carl Daniel [VC++ MVP]]

I'm stepping through one at a time, and that line is what always triggers
it.

Interesting. Have you tried doing something like using CreateFile to open
the file instead? I can't think of any reason why it should make any
difference, but you're in wierd territory here.

-cd

 

[Lee Crabtree]

Interesting. Have you tried doing something like using CreateFile to open
the file instead? I can't think of any reason why it should make any
difference, but you're in wierd territory here.

-cd

Not yet. I put a wee test app together to try and see if managed C++
got in the way of fopen or something. It's never been the case in the
past, but when you have no other options... Anyway, it was no good. It
worked just like it always has (that's odd...the fact that it worked is
somehow BAD).

I'm getting a flat forehead.

Lee

 

[Arnaud Debaene]

I'm stepping through one at a time, and that line is what always
triggers it.

Is the offending line compiled to native or CLR?

Make sure you debug in mixed or native mode. My guess is that there is
something wrong with the native code (though you haven't shown enough code
for us to spot it), whoses neat effect is to generate a
NullReferenceException when switching back from nativeto managed. But what
you are seing is probably the symptom, not the cause.

Arnaud
MVP - VC

 

[Lee Crabtree]

Is the offending line compiled to native or CLR?

Make sure you debug in mixed or native mode. My guess is that there is
something wrong with the native code (though you haven't shown enough code
for us to spot it), whoses neat effect is to generate a
NullReferenceException when switching back from nativeto managed. But what
you are seing is probably the symptom, not the cause.

Arnaud
MVP - VC

I've done some more testing, and it's the act of opening a file that's
causing the exception. Anywhere in my unmanaged code, I can do
something like

FILE* file = fopen("C:\\file", "rb");

and I generate an exception. What gives?

Lee

 

[Lee Crabtree]

Okay, I have officially coded myself into a straitjacket.

I have two projects in this solution (as I said). One is a C# form app,
and the other is a mixed-mode DLL. When I set the debugging mode of the
C# app to allow unmanaged debugging, the fopen executes without a hitch.
When I turn off unmanaged debugging, I get the NullReferenceException.

Lee

 

[Arnaud Debaene]

Okay, I have officially coded myself into a straitjacket.

I have two projects in this solution (as I said). One is a C# form
app, and the other is a mixed-mode DLL. When I set the debugging
mode of the C# app to allow unmanaged debugging, the fopen executes
without a hitch. When I turn off unmanaged debugging, I get the
NullReferenceException.

What happens without any debugger?

Also, if you debug with "allow unmanaged" turned on, are you sure, it's not
some native code *after* the file opening that triggers the exception? Can
you debug step-by-step the unmanaged code until you go back to the managed
caller?

Arnaud
MVP - VC

 

[Lee Crabtree]

What happens without any debugger?

Also, if you debug with "allow unmanaged" turned on, are you sure, it's not
some native code *after* the file opening that triggers the exception? Can
you debug step-by-step the unmanaged code until you go back to the managed
caller?

Arnaud
MVP - VC

I found it, finally. I turned on the "allow unmanaged" debugger and
went looking for some other possible problem. I found out that my
predecessor had used a strcpy to copy the entirety of a file into a
buffer. The problem was, you guessed it, that the buffer wasn't always
big enough. That wasn't a problem for them, because the files they were
working with were always small. I, however, had to enlarge the size of
said file, and boom.

In the end, a liberal usage of asserts and some pointer arithmetic saved
the day.

Let this be a lesson to us all - never trust the debugger. It's handy,
it points out a lot of things, but it'll never be able to track things
down to your satisfaction. If I'd stopped and used my gray matter, I
might have found this earlier and saved myself several hours of pain.
Oh well. We live and learn. At any rate, we live.

Lee

P.S. Thanks for the debugger setting. I'd never even noticed that one.

 

[Arnaud Debaene]

I found it, finally. I turned on the "allow unmanaged" debugger and
went looking for some other possible problem. I found out that my
predecessor had used a strcpy to copy the entirety of a file into a
buffer. The problem was, you guessed it, that the buffer wasn't
always big enough. That wasn't a problem for them, because the files
they were working with were always small. I, however, had to enlarge
the size of said file, and boom.

In the end, a liberal usage of asserts and some pointer arithmetic
saved the day.

Let this be a lesson to us all - never trust the debugger. It's
handy, it points out a lot of things, but it'll never be able to
track things down to your satisfaction. If I'd stopped and used my
gray matter, I might have found this earlier and saved myself several
hours of pain. Oh well. We live and learn. At any rate, we live.

Ah, the good ol'one stack overflow !!!! ;-) I milit for an internal code
policy that FORBIDS strcpy, raw pointer arithmetic and the like... STL gives
you about the same flexibility but is much more secure...

Arnaud
MVP - VC