Endless loop of First Hand Exceptions

[chhenning]

Hi there, I realize that my question probably cannot being answered
from this forum. But what I'm looking for is some guidance on how to
tackle my problem.

For some reason I believe my c++ runtime is messed up. The reason I
say that is that I get an endless loop of the following message when
calling fflush(...):

First-chance exception at 0x8018c470 in WorkerHost.exe: 0xC0000005:
Access violation at location 0x000000008018c470.

The code I using to trigger this problem is simply this:

FILE* f = fopen( "c:\\remove.txt", "w" );
fwrite( "Hello", 1, 5, f );
fflush( f );


fflush() function never returns. I have tried using ofstream from the
STL but same thing in the end. Only when I use Win32 calls like
CreateFile(), WriteFile(), etc. I have no problems.

This only occurs in my debug build and not in my release build. Also,
the problem does not occur with a simple Hello World program. The
application I'm trying to debug is a rather big one. Basically a .net
executable is forking of a C++ com module to do some work.

I believe this problem started to occur when I upgraded my VS2005 with
the SP1. Since then I have rebuild all the dependencies of my
application to avoid potential problems with having to deal with
different runtime linked with different modules. But no luck.

Is there anyone out there who could give me some hints on what I can
do about this? Also, in case this is the wrong forum please refer me
to the correct one.

Thanks a lot,
Christian

[Ulrich Eckhardt]

This post might be inappropriate. Click to display it.

[chhenning]

Hi Uli,

Post by Ulrich Eckhardt

Post by chhenning
Access violation at location 0x000000008018c470.

So, for the record, you are on a 64-bit system.

Sorry, I forgot to state that. Yes I'm working on with 64bit code.

Post by Ulrich Eckhardt
Streams come from the IOStreams library, not from the STL. What you mean is
the C++ standard library. ;)

Details details. ;-)

Post by Ulrich Eckhardt

Post by chhenning
Only when I use Win32 calls like CreateFile(), WriteFile(), etc. I
have no problems.

fopen() and std::fstream are basically wrappers around CreateFile() etc, so
I share your guess that the runtime might cause it.

Post by chhenning
This only occurs in my debug build and not in my release build. Also,
the problem does not occur with a simple Hello World program.

That again speaks against the runtime but rather for the abuse of the
runtime.

Post by chhenning
The application I'm trying to debug is a rather big one. Basically a
.net executable is forking of a C++ com module to do some work.
I believe this problem started to occur when I upgraded my VS2005 with
the SP1. Since then I have rebuild all the dependencies of my
application to avoid potential problems with having to deal with
different runtime linked with different modules. But no luck.

* Revert to a known good state using the version control system (or a
backup) and try again. If that works, jump to a state in the middle and try
if it breaks there etc, until you have the commit that caused the problems.
* Deactivate stuff until it stops breaking, until you find the parts that
breaks things. Might be difficult in your case though.
* Check where the debug/release configurations differ.
* Verify that the e.g. the default alignment and packing and the default
calling convention isn't touched in the project settings or some headers.
* Try to create a thread using _beginthread and see if it works in that
thread. This would be a hint that some initialisations are not performed or
not performed correctly.

Thanks for all of these advises. I'll try them all. Once I'm done I'll
post a summary to this forum.

Post by Ulrich Eckhardt
Good luck!

Thanks!

Christian

[Tamas Demjen]

This post might be inappropriate. Click to display it.

[chhenning]

Thank you Tom and Brian.

I'm afraid to say that but my problem just disappeared. This is
somewhat unsatisfying since I know it will come back one day. These
problems always do. ;-) My last action was installing Application
Verifier and then I couldn't reproduce the error. Next time I'm having
this problem I'll save my debug output to compare to being able to
compare with the working state.

Christian

[chhenning]

Alright, here we go again. The problem reappeared. I was able to
create a simple console app ( x64 ) which loads my troubling COM DLL
into the memory. After this is done I use my debug code ( some very
basic file io ) and it fails when calling fflush. I get an endless
stream of

First-chance exception at 0x8018c480 in engine_harness_2.exe:
0xC0000005: Access violation at location 0x000000008018c480.


Now, I have learned somethings from the last time. I have installed
Application Verifier ( x64 version ) and trying to see what's going
on. Interestingly when I attach my troubling app to the AppVerifier it
runs through without any problems. This now is more than strange. Can
someone tell me what the AppVerifier does? BTW, all logs that
AppVerifier is suppose to create are all empty.

All I can see in the debug output is this:

'engine_harness_2.exe': Loaded 'C:\chh\projects
\engine_harness_2\x64\Debug\engine_harness_2.exe', Symbols loaded.
'engine_harness_2.exe': Loaded 'D:\WINDOWS\system32\ntdll.dll', No
symbols loaded.
Page heap: pid 0x1308: page heap enabled with flags 0x3.
AVRF: engine_harness_2.exe: pid 0x1308: flags 0x80443027: application
verifier enabled
'engine_harness_2.exe': Loaded 'D:\WINDOWS\system32\verifier.dll', No
symbols loaded.
AVRF: failed to initialize verifier logging (C000003A).
AVRF: verifier.dll provider initialized for engine_harness_2.exe with
flags 0x80443027
'engine_harness_2.exe': Loaded 'D:\WINDOWS\system32\vrfcore.dll', No
symbols loaded.
[snip]

I keep getting the message "AVRF: failed to initialize verifier
logging (C000003A)." Why is that? I'm debugging a x64 process with x64
AppVerifier.

Any help is more than welcome.

Thanks,
Christian

[chhenning]

OK, finally some movement! I have attached my program to WinDbg and it
seems the problem is with a function called DebuggerProbe from inside
MSVCR80D.DLL. This evidence led me directly to the following bug
report:

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=100319&wa=wsignin1.0

The problem described here is very similar to what I'm experiencing.
Besides the fact that the reporter's program is aborting and my
program is endlessly issuing these first hand exceptions. I'm not sure
what to do next. Any ideas?

Thanks,
Christian