fopen problem, possibly LeaveCriticalSection

Hi,

We've been receiving bug reports from users.  The minidumps we've been
getting back say

Unhandled exception at 0x7c57e592 in CRASH.DMP: Microsoft C++ exception:
[rethrow] @ 0x00000000

and the following call stack:

KERNEL32.DLL	7c57e592()
KERNEL32.DLL	7c57e592()
msvcr71.dll	__unlock()  + 0x13
msvcr71.dll	__unlock_file()  + 0x22
msvcr71.dll	__fsopen()  + 0x5a

The kernel32.dll addresses seem to be that the call to __unlock() does this

LeaveCriticalSection( _locktable[locknum].lock );

Does anyone know what this is, and why it'd be failing?  It only happens
intermittently; never on my machine, always on a users'.

Thanks,
;) james.

"James Whitwell" <jams@NO_SPAMmomento.com.au> wrote in message
news:#XJkRSA2EHA.2600@TK2MSFTNGP09.phx.gbl...
> Hi,
>
> We've been receiving bug reports from users.  The minidumps we've been
> getting back say
>
> Unhandled exception at 0x7c57e592 in CRASH.DMP: Microsoft C++ exception:
> [rethrow] @ 0x00000000
>
> and the following call stack:
>
> KERNEL32.DLL 7c57e592()
> KERNEL32.DLL 7c57e592()
> msvcr71.dll __unlock()  + 0x13
> msvcr71.dll __unlock_file()  + 0x22
> msvcr71.dll __fsopen()  + 0x5a
>
> The kernel32.dll addresses seem to be that the call to __unlock() does
this
>
> LeaveCriticalSection( _locktable[locknum].lock );
>
> Does anyone know what this is, and why it'd be failing?  It only happens
> intermittently; never on my machine, always on a users'.
>
> Thanks,
> ;) james.

Hi James



Firstly I think you are tackling the problem in the wrong way. Your priority
should be to recreate the crash in your test environment. If you can't
future bugs will not be captured!



Secondly I think you are looking in the wrong place. I am guessing that the
LeaveCriticalSection() function is working but is being passed invalid
data/thread/object/pointer. I am also guessing that LeaveCriticalSection()
is a lot lower level than your code. So look further up the chain eg do you
check if the object has been created properly or if your locknum is going
out of bounds.

With out more information it is hard to offer more advice.



Some quick ideas



1) Get the user (the one who crashes the most) to talk you through how they
use your app (you will be surprised).  This might lead you thorough the
route to a crash



2) Ask to borrow one of users pcs to try and recreate the crash with real
data and settings.



3) Release a debug version which logs all the key events. I personally use a
debug function instead of comments in my files. All it does is write a line
to a text file if a debug environment variable has been defined. Create the
file name using the data and time for a unique name and if space is an issue
delete the file when the app closes that way you will only have records of
the crashes.



4) A good question to ask users is "I bet you get IT people down here a
lot?" , it gets a more honest answer than asking "what have you  changed on
the system?".



Hope that help



GS

Make sure all your components are linked against the same msvcr71.dll.
Also don't use catch(...). Use SetUnhandledExceptionFilter instead.

"James Whitwell" <jams@NO_SPAMmomento.com.au> wrote in message
news:%23XJkRSA2EHA.2600@TK2MSFTNGP09.phx.gbl...
> Hi,
>
> We've been receiving bug reports from users.  The minidumps we've been
> getting back say
>
> Unhandled exception at 0x7c57e592 in CRASH.DMP: Microsoft C++ exception:
> [rethrow] @ 0x00000000
>
> and the following call stack:
>
> KERNEL32.DLL 7c57e592()
> KERNEL32.DLL 7c57e592()
> msvcr71.dll __unlock()  + 0x13
> msvcr71.dll __unlock_file()  + 0x22
> msvcr71.dll __fsopen()  + 0x5a
>
> The kernel32.dll addresses seem to be that the call to __unlock() does
> this
>
> LeaveCriticalSection( _locktable[locknum].lock );
>
> Does anyone know what this is, and why it'd be failing?  It only happens
> intermittently; never on my machine, always on a users'.
>
> Thanks,
> ;) james.

Hi,

Thanks for a great reply.  It's always good to hear someone else's
debugging tips.

wh0cares wrote:
> Firstly I think you are tackling the problem in the wrong way. Your priori
ty
> should be to recreate the crash in your test environment. If you can't
> future bugs will not be captured!

That's the crux really: I can't figure out how to reproduce it.  When I
look at the call stack, it starts in my code with a call to fopen(),
which goes into msvcr71.dll as __fsopen, then __unlock_file(), then
__unlock(), and finally into kernel32.dll as LeaveCriticalSection().  So
the call to LeaveCriticalSection() isn't actually in my code.

What I'm wondering is if anyone has any ideas on how this bug might be
tripped.  The error that I see (from the minidump that's produced when
the program crashes on the user's machine) is

Unhandled exception at 0x7c57e592 in CRASH.DMP: Microsoft C++ exception:
[rethrow] @ 0x00000000.

Is it possible I'm eventually running out of something internal to the C
runtime library, by not closing all my open FILE handles, or something?
I tried opening as many filehandles as possible, then closing random
ones, then opening more, but I couldn't trip it up.

thanks,
;) james.

quote:
Originally posted by James Whitwell 
Hi,

We've been receiving bug reports from users.  The minidumps we've been
getting back say

Unhandled exception at 0x7c57e592 in CRASH.DMP: Microsoft C++ exception:
[rethrow] @ 0x00000000

and the following call stack:

KERNEL32.DLL	7c57e592()
KERNEL32.DLL	7c57e592()
msvcr71.dll	__unlock()  + 0x13
msvcr71.dll	__unlock_file()  + 0x22
msvcr71.dll	__fsopen()  + 0x5a

The kernel32.dll addresses seem to be that the call to __unlock() does this

LeaveCriticalSection( _locktable[locknum].lock );

Does anyone know what this is, and why it'd be failing?  It only happens
intermittently; never on my machine, always on a users'.

Thanks,
;) james. 
 

James,

You're getting this problem most likely due to the problem in Microsoft's ve
rsion of the C runtime stdio lib. I've found that fopen() and fgetc() someti
mes return EOF when in fact it's really NOT the end of the file and no error
 has occured. Your program probably called fopen with no error, but later ca
lled fgetc and it returned EOF for the first char. Yet your program thinks e
verything is OK since fopen returned success. This contradiction in return v
alues has caused my programs some problems. There are a couple ways to solve
 this:

1) I see you're using Microsoft's runtime lib - err, fopen() should NOT be c
alling _fsopen(), but MS does it anyway. Nothing much you can do about that 
except link your prog with Boreland's stdlib, and use MS for all the other l
ibs. This would only work if you're programming plain ANSI C, or plain C++.

2) If fgetc() returns EOF (-1) after fopen() returned success, close the fil
e handle with fclose() and try reopening the file again. When you call fgetc
() again, it will behave correctly.

The only time I've found this phenomenon occuring is when I open a file that
 is being written to by some other process at the same time. With the way fo
pen() should REALLY work, is it should give an error when you try to open a 
file that's already open by another process. The whole reason _fsopen() exis
ts is to do _shared_ file opening instead of regular file opening with fopen
(). Why Microsoft calls _fsopen() in their C runtime is beyond me. Besides, 
did you know _fsopen() is specific to DOS, while fopen() is ANSI C?

I wish I had a better solution for you, but at least now you probably know w
hy your problem is occuring.

-Greg Dolley