title: How to get information on a Buffer Overflow Exception in a mixed application?
body: <p>In all WPF application I develop there is a global exception handler subscribed to <code>AppDomain.CurrentDomain.UnhandledException</code> which logs everything it can find and then shows a dialog box telling the user to contact the author, where the log file is etc. This works extremely well and both clients and me are very happy with it because it allows fixing problems fast.</p>
  
  <p>However during development of a mixed WPF / C# / CLI / C++ application there are sometimes application crashes that do not make it to the aforementioned exception handler. Instead, a standard windows dialog box saying "XXX hast stopped working" pops up. In the details it shows eg</p>
  
  <pre><code> Problem Event Name: BEX
   Application Name:   XXX.exe
   Fault Module Name:  clr.dll
   ...
  </code></pre>
  
  <p>This mostly happens when calling back a managed function from within umanaged code, and when that function updates the screen. I didn't took me long to figure out the root cause of problem, but only because I can reproduce the crash at my machine and hook up the debugger: in all occasions the native thread was still at the point of calling the function pointer to the managed delegate that calls directly into C#/WPF code.</p>
  
  <p>The real problem would be when this happens on a client machine: given that usually clients are not the best error reporters out there it migh take very, very long to figure out what is wrong when all they can provide me are the details above.</p>
  
  <p>The question: what can I do to get more information for crashes like these? Is there a way to get an exception like this call a custom error handler anyway? Or get a process dump? When loading the symbols for msvcr100_clr0004.dll and clr.dll (loaded on the thread where the break occurrs), the call stack is like this:</p>
  
  <pre><code>msvcr100_clr0400.dll!__crt_debugger_hook()  
  clr.dll!___report_gsfailure()  + 0xeb bytes 
  clr.dll!_DoJITFailFast@0()  + 0x8 bytes 
  clr.dll!CrawlFrame::CheckGSCookies()  + 0x2c3b72 bytes  
  </code></pre>
  
  <p>Can I somehow hook some native C++ code into __crt_debugger_hook() (eg for writing a minidump)? Which leads me to an additional question: how does <code>CheckGSCookies</code> behave on a machine with no debugger installed, would it still call the same code? </p>
  
  <p><strong>update</strong> some clarification on the code: native C++ calls a CLI delegate (to which a native function pointer is acquired using <code>GetFunctionPointerForDelegate</code> which in turn calls a C# System.Action. This Action updates a string (bound to a WPF label) and raises a propertychanged event. This somehow invokes a buffer overflow (when updating very fast) in an unnamed thread that was not created directly in my code.</p>
  
  <p><strong>update</strong> looking into <code>SetUnhandledExceptionFilter</code>, which didn't do anything at first, I found <a href="http://www.codeproject.com/KB/winsdk/crash_hook.aspx" rel="nofollow">this nifty article</a> explaining how to catch any exception. It works, and I was able to write a minidump in an exception filter installed by using that procedure. The dump gives basically the same information as hooking the debugger: the real problem seems to be that the Status string is being overwritten (by being called from the native thread) while at the same time being read from the ui thread. All nice ans such, but it does require dll hooking which is not my favorite method to solve things. Another way would still be nice.</p>