I am beyond baffled by this. My application throws a System.AccessViolationException only when it is run in Release mode without the debugger attached (as in, I run the exe directly, outside of Visual Studio or I do "Start Without Debugging" in the Debug menu). Debug mode - everything works great; Release mode with debugger attached - everything works great. The very nature of how this error is thrown makes it impossible to debug, so I have no idea where to look into correcting it.
Has anyone else ever come across such an error Does anyone have an idea how to hunt down such an error The application is not just a few hundred lines, it is easily on the upper end of tens of thousands of lines. I cannot seek it out with a debugger because if one is attached, the error doesn't occur. I have tried to juggle all of the options that one can set in the project properties, even matching Release mode to Debug mode and Debug mode to Release mode, yet I can never get a Debug executable without debugger attached to crash nor a Release executable without debugger attached to not crash.
This issue occurs on both XP and Vista and the application is .NET 2.0.
Please, someone save my sanity.

Unhandled exception only when running in release without debugger attached.
Fluxtah
I am not sure how to determine when it crashes beyond that it crashes after the UI renders. The exception is caught by an unhandled exception event handler, but the exception object contains nothing of use beyond the type and message I displayed in my last post.
As I said in my first post, there are many, many lines of code, so I was hoping there was some easier way to track down where the exception stemmed from than guessing. I do know that release mode strips out debugging information, which is why this exception is so impossible to track down at the moment - it only happens in release mode without a debugger attached.
LeeroyB
bimalr1
patria
interesting. Is there a specific point where it crashes perhaps with some guess work you can comment out some code and see how that works, even the Debugger.Break()
I'm sure you are aware, but just FYI - when you compile something under release mode it strips out all debugging information (reduces file size too) and enhances performance
Gurpreet Singh Gill
Try running the application out of the debugger in release mode then attaching the debugger to the process after it has starte running and see if that then enables you to catch the exception. This must be related to some sort of optimization that is occuring with the release mode.
Mark.
une
Why can't this happen when the debugger is attached :( Life would be so much simpler.
daraneko
Aleniko29139
Hi,
can you see a stack trace of where the error is occuring Did you try capturing the Application.ThreadException and logging more information
Mark.
piccolo2101
The exact exception reads:
As far as code snippets go, I honestly have not a clue what may be causing this, not even a lead. There is no stack trace present with the exception object.
JLutz
As far as running it outside of the debugger and then attaching the debugger, I have tried that but the application crashes too quickly and loading after that point simply results in no symbols being loaded (even when I try to manually).
I tried to disable code optimization when I was messing around with the project build properties (mentioned in first post), so I'm pretty sure code optimization is not to blame.
DavidThi808
sure.
you wouldnt happen to be handling/dealing with unmanaged code or something of that nature
http://msdn2.microsoft.com/en-us/library/system.accessviolationexception.aspx
DaveSmith
startlet
*boggled*
tried running it on a different computer - just in case
maglup