Unhandled exception only when running in release without debugger attached.

Unhandled exception only when running in release without debugger attached.

• New-Bee

  I did so and got the debugger attached before the UI rendered - no error because the debugger was attached.
  
  

• spotl

  The stack trace is not available and the exception is caught by an unhandled exception event handler, the e.ExceptionObject.GetType() returns that it is an AccessViolationException so I am not sure about an Application.ThreadException.
  
  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.
  

• LeeC22

  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.

  
  
  

• nhaas

  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.

  
  
  

• jk67

  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

  
  
  

• bj16060

  After I posted I went ahead and tested what commenting out all of the Debugger.Break() statements would do - the error still occurs with them gone.
  
  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.
  
  

• Ryan Schwartz

  Well, this is officially the weirdest bug ever. I've now removed all of the unsafe code, unchecked the ability to have unsafe code in the project settings, cleaned and recompiled everything, and the error STILL occurs.
  
  

• Kamii47

  by any chance are you trying to perform some debugging within your code that may cause this error Any chance on showing the exact exception message and perhaps any code snippets on where you think it maybe coming form
  
  

• CalinMac

  The only debugging setup is using Debugger.Break() and that should not crash an application running in release mode, only prompt the user to attach a debugger (or at least that was my understanding based on this).
  
  The exact exception reads:
  
  

  Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
  

  
  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.
  
  

• Jeff Green

  Yes, this occurs on at least five machines. The machines are all very different, with two being Vista, two being XP SP2, and one being XP SP1. Granted, I did not try the executable with removed unsafe code on those machines, but that's because it is not possible at this moment, and I'm pretty sure it won't make a difference.
  
  Why can't this happen when the debugger is attached :( Life would be so much simpler.
  
  

• Bodylojohn

  Try putting a Thread.Sleep in the startup of the program which will give you chance to attach the debugger.
  
  

• wfair

  In a number of places, yes. I also realize that is the root of such an exception; however, tracking it down is the issue. The biggest catch is: Why does it NOT happen when a debugger is attached or it is the debug mode executable that is manually run If I could answer that, then maybe the issue would seem at least trackable.
  
  

• C Senthil Kumar

  *boggled*

  tried running it on a different computer - just in case

  
  
  

• GuoHouzuo

  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

  
  
  
• Unhandled exception only when running in release without debugger attached.