views:

97

answers:

5

I currently am witnessing an error that only happens on "Release" mode of my exe.

Therefore, I have no debugger attached, and the application only goes "... has stopped working.".

My initial reflex was to catch any and all exception in my main loop and display its message, but turns out none is thrown, the program just crashes. (My program is single threaded).

This might be related to the fact that I integrate unmanaged code, but even then, why would it be different on release mode? Is there any way for me to catch that exception?

I suspect it to be one of those errors that go "Cannot show stack trace/find code" when run in the debugger, (and don't actually throw an exception), but I honestly can't test it. Suggestions SO?

A: 

The layout of memory will be different between Release and Debug. Also the layout of the stack may be different. If you have a buggy piece of unmanaged code trashing memory, then it's going to have random effects.

John Saunders
And unfortunately in .NET, it doesn't matter whether you have a Debug or Release project configuration, only whether the debugger is attached, because the compiler runs just-in-time and knows if there's a debugger.
Ben Voigt
A: 

You can still step debug a Release build from VS; try that first.

If the mixing of managed and unmanaged code makes it tricky for some reason, you could try using WinDbg with the SOS and SOSEX extensions. See my answer here for the basic steps required - and check you are generating PDB symbols for Release builds too.

Sean Fausett
Yes, but you have to attach the debugger after the program starts running. If the debugger is attached at startup, the CLR detects this and uses the debug JIT compiler instead of the release (optimized) one.
Ben Voigt
If a quick test debugging from startup under VS doesn't work, then yes, time to attach after the program has started (with some sort of delay if necessary), or just let it crash then load the crash dump into VS 2010 or WinDbg.
Sean Fausett
+4  A: 

You can still attach a debugger to it even if it’s running in Release mode. You could try something like...

  • Write the program so that it waits for a keypress at the beginning of execution
  • Run it in Release mode
  • Attach the debugger while it is waiting for the keypress
  • Debug it

Then see what happens. If it stops happening and works under the debugger even when running in Release mode, then you have a Heisenbug (basically meaning it will be very difficult to find this bug).

If, however, it happens and the Visual Studio debugger breaks when the problem happens, then look at the Threads window (Ctrl+Alt+H, I think). It is possible that, although your application uses only one thread, the native code you ran could start unmanaged threads of its own. If that is the case, you might be able to find a way to get it to stop doing that, as unfortunately there is no way to catch that exception in your managed code.

Timwi
I think the term Heisenbug perfectly describes this. Will try the debugger technique and give you updates.
Lazlo
That depends on how easy it is to replicate. If it happens every time you run it this way, and within a reasonable time period, then it's probably not a Heisenbug. Such bugs are notoriously frustrating just to capture, or to make sense of the sporadic behaviour.
Sean Fausett
The first Wikipedia example is: "One common example is a bug that occurs in a program that was compiled with an optimizing compiler, but not in the same program when compiled without optimization (e.g., for generating a debug-mode version)." But it's rather pointless to argue on semantics.
Lazlo
+1  A: 

That may be due to the fact you are using try catch block some where

Try below steps

1- Go to Visual Studio IDE

2- Select Debug options

3- Click on Exceptions

4- Check Throw option for following 'Common Language RunTime Exception' and Native Win 32 Exceptions

5- Run your code in DEBUG mode first.

6- Check you are getting exceptions or not.

this may solve your problem atleast you will get the exception in DEBUG mode.

saurabh
A: 

I think it's better to test the unmanaged code in isolation first.

If this is successful, then the problem maybe the integration of the unmanaged code to managed code or in the managed code itself.

John
The managed code works and has been tested thoroughly in isolation.
Lazlo