title: Exception handling in subsystem:native
body: <p>I'm writing a native mode application (think: <code>link /subsystem:native</code>).  This means I can't use anything from kernel32.dll, which (apparently) means nothing from the C runtime libraries.  Mostly that's not a problem for me as everything I need is in ntdll.dll.  The code is written and working.</p>
  
  <p>However, I'm writing the code in c++, and there's the question of what to do with exception handling.  I believe the intent for native mode applications is to use SEH, which is what I've done.  But that's not quite working.</p>
  
  <p>If I compile without /EHa, my destructors don't get called when I RtlRaiseException.  But if I do compile with /EHa, I'm getting an undefined symbol (<strong>unresolved external symbol __CxxFrameHandler4</strong>), which apparently only exists in the C runtime.</p>
  
  <p>(How) can I compile my c++ code to support unwinding while still building a native mode application?</p>
  
  <hr>
  
  <p><strong>Edit</strong>: VC has 4 possible settings for exception handling, all of which have problems in this context:</p>
  
  <ul>
  <li><code>Yes with SEH Exceptions (/EHa)</code> - As mentioned above, this results in <em>unresolved external symbol __CxxFrameHandler4</em>.</li>
  <li><code>Yes (/EHsc)</code> - 2 unresolved symbols: __CxxFrameHandler4 &amp; __std_terminate</li>
  <li><code>Yes with Extern C functions (/EHs)</code> - Same 2 unresolveds as /EHsc</li>
  <li><code>No</code> - No unresolved symbols, but destructors don't get called when exceptions get raised.</li>
  </ul>
  
  <p>I wondered if I could link to the non-dll version of the C runtime.  After all, if everything's embedded in my executable, it won't need to load any dlls when running at boot time, right?</p>
  
  <p>So, I tried linking in libvcruntime.lib (the apparent home of __CxxFrameHandler4).  The good news is that __CxxFrameHandler4 is no longer unresolved.  The bad news is that gave me an additional 55 unresolved symbols.  This list includes items like <code>__imp_TlsAlloc</code> and <code>__imp_TlsGetValue</code> which are clearly from kernel32.dll (and thus unavailable to me).</p>
  
  <p>I'm prepared to use either C++ exceptions or SEH, but I can't get either to work in this context.</p>
  
  <p>I see a number of exception-related functions exported in ntdll.  Maybe there's some other exception handling mechanism I'm supposed to be hooking into?</p>
  
  <hr>
  
  <p><strong>Edit2:</strong>  Since __CxxFrameHandler4 isn't working for me, I tried disabling the new exception handling (<code>/d2FH4-</code>).  The only effect this had was to change the unresolved symbol to __CxxFrameHandler3.  Not the result I was hoping for.</p>
  
  <p>I'm out of ideas here.  If there's some way to unwind the stack without using kernel32, I'm not finding it.  The fact that there are exported functions in ntdll with "Exception" in their name suggests there might be, but perhaps not.  Perhaps the intent there was always "C" code where destructors aren't a thing.</p>
  
  <p>If anyone has any new things to try or a new place to look, I'd appreciate it.  Or even an authoritative source that says it can't be done.  At least then I'd know.</p>