The Visual C++ Exception Model
by Howard Jeng

When programming in C++ with Microsoft Visual C++, your program has two exceptions models: the normal C++ exception model and the Structure Exception Handling (SEH) exception model.¹⁾ MSVC's C++ exception system is, in fact, implemented with SEH's functionality. This implementation leads to some interesting behaviors.

This article discusses some of the consequences of the MSVC exception system from the standpoint of a C++ programmer. It assumes familiarity with C++ exceptions, including exception aware programming techniques like RAII, and basic Windows programming.²⁾ It does not assume any background with SEH. The behavior described covers MSVC .NET 2002, 2003, 2005 and 2008.

An Introduction to Structured Exception Handling

Structured Exception Handling is a mechanism built into the operating system that provides facilities to detect and deal with exceptional circumstances, much as C++ exceptions do for C++ programs. SEH exceptions come in two varieties: hardware exceptions and software exceptions. Hardware exceptions are exceptions raised by the CPU such as access violations and divide by zero. Software exceptions are exceptions raised explicitly by programs or, on occasion, the operating system itself. For the purposes of this article, there isn't much difference between the two.

When an exception is raised, two pieces of information are captured: one is the state of the processor at the time of the exception, which is stored in a CONTEXT structure³⁾. The other is information about the exception, which is stored in an EXCEPTION_RECORD. The two parts of this structure we'll be concerned about are the ExceptionCode member and the ExceptionInformation array, which contain a numeric value for the exception type and additional information respectively. For example, when an access violation is detected, a hardware exception is raised with the code 0xC0000005. If ExceptionInformation[0] is zero the access violation was caused by a read and if ExceptionInformation[0] is non-zero the access violation was triggered by a write, and ExceptionInformation[1] is the address that was read from or written to. Not all exceptions generate additional information; in fact, the majority don't. To raise a software exception, code can call the RaiseException() function, which takes an exception code and other exception information, which will then be packaged into an EXCEPTION_RECORD.

Windows exception codes follow the following format: Bits 31 and 30 represent the severity code. It should be 00 for success, 01 for informational, 10 for warning and 11 for an error. Bit 29 is set for user exception codes. Bit 28 is reserved and should not be set. Bits 27 to 16 represent a facility code. For example, Windows Update is assigned the facility code of 36, while 0 represents no particular facility. The bottom 16 bits then represent the actual error code. This is why exceptions like access violations start with 0xC: these codes represent non-user error exceptions. In theory, most user exception codes should start with 0xE to represent user defined error exceptions⁴⁾.

Actually dealing with SEH exceptions in MSVC takes two primary forms: frame based exception handling (__try/__except blocks) and termination handling (__try/__finally blocks).

Frame Based Exception Handling

Frame based exception handling is roughly analogous to C++'s try/catch blocks. Instead of try/catch, the blocks look like:

__try {
  // code to attempt to execute
} __except (filter_expression) {
  // handler code
}

Unlike C++ catch block, where the catch contains types, the filter expression is more like the contents of the parenthesis after an if⁵⁾: it can be almost anything that eventually evaluates to a value. In particular, the filter expression must evaluate to one of three values: EXCEPTION_EXECUTE_HANDLER, EXCEPTION_CONTINUE_SEARCH or EXCEPTION_CONTINUE_EXECUTION. If the expression evaluates to EXCEPTION_EXECUTE_HANDLER, the code in the handler block is executed, much like when the type matches the catch for a C++ exception. If the expression evaluates to EXCEPTION_CONTINUE_SEARCH it looks for another __except block that might handle the exception, like when a C++ catch block doesn't contain a matching type ⁶⁾. EXCEPTION_CONTINUE_EXECUTION has no analogy in C++ exception handling: it causes program execution to resume from the point where the exception was raised ⁷⁾.

Unlike C++ catch blocks, you can't chain __except blocks. That is to say this code is illegal:

  __try {
    // stuff
  } __except (filter expression 1) {
    // handler 1
  } __except (filter expression 2) {
    // handler 2

  }

  __try {
    __try {
      // stuff
    } __except (filter expression 1) {
      // handler 1
    }
  } __except (filter expression 2) {
    // handler 2

  }

So what does a typical filter expression look like? If there was such a thing as a typical filter expression, it would probably look something like this:

  EXCEPTION_POINTERS * eps = 0;
  __try {
    // stuff

  } __except (eps = GetExceptionInformation(), EXCEPTION_EXECUTE_HANDLER) {
    // handler
  }

DWORD filter(EXCEPTION_POINTERS * eps) {
  if (eps->ExceptionRecord->ExceptionCode == EXCEPTION_ACCESS_VIOLATION)
    return EXCEPTION_EXECUTE_HANDLER;
  return EXCEPTION_CONTINUE_SEARCH;
}
 
  EXCEPTION_POINTERS * eps = 0;
  __try {
  } __except (eps = GetExceptionInformation(), filter(eps)) {
  }

  EXCEPTION_POINTERS * eps = 0;
  __try {
  } __except (eps = GetExceptionInformation(), 
              ((GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION) 
                  ? EXCEPTION_EXECUTE_HANDLER 
                  : EXCEPTION_CONTINUE_SEARCH)) {
  }

Termination Handling

Termination handling is much simpler than frame based exception handling. Instead of __try/__except, we have __try/__finally. The __try block is executed, and barring the thread or process ending, the code in the __finally block is executed unconditionally when the __try block is exited, whether the function returns, an exception is thrown, if there's a goto out of the block or the last statement in the __try block finishes executing.

  __try {
    // try to execute this code
  } __finally {
    // execute this code afterwards (unless the thread or process ends)
  }

  __try {
    __try {
      // try to execute this code
    } __finally {
      // execute this code afterwards (unless the thread or process ends)
    }
  } __except (filter_expression) {
    // exception handler
  }

Implementing C++ Exceptions

This section presents a very high level overview of how C++ exceptions are implemented. ¹¹⁾ Let's start with what happens when a C++ exception is thrown: first a copy of the exception is placed on the stack, then the program calls to function named __CxxThrowException() with the address of the exception object and a pointer to a throw information structure placed in the executable image. __CxxThrowException() in turn calls RaiseException() with an exception code of 0xE06D7363 and three information arguments: a magic number, 0x19930520, and the two arguments passed to __CxxThrowException().

Given that RaiseException() is involved in throwing a C++ exception, the natural mechanism for implementing stack unwind for automatic objects is a termination handler. Basically, each function that requires stack unwind has an extra local variable that contains an ID that can be used to determine how far function execution has progressed. As objects are created and destroyed this ID is updated. When the stack frame is destroyed, and the termination handler is run, it uses the ID to destroy the objects in reverse order of construction. This is obviously an simplification of the process; there are a number of special cases. For example, for some calling conventions, function call arguments are constructed by the caller and destroyed by the callee. An unfortunate side effect of this is that if such a function is called via a function pointer and the function pointer has a bad address, causing an SEH exception, this means that the destructors for the arguments will not be run.

The throw information structure used is one of the interesting types that seem to be built into the compiler itself. Even if you include no headers, the compiler knows what the definition for the _s__ThrowInfo should be. Unfortunately, that means that there's no header that we can look at to see an official definition, but the relevant bits seem like they looks something like¹²⁾:

typedef void (__cdecl * _PMFN)(void); // despite the static typing, function pointers of 
                                      //   type _PMFN are usually used as pointers to other
                                      //   function types
 
struct _PMD {
  int mdisp;  // member offset

  int pdisp;  // offset of the vtable 
  int vdisp;  // offset to displacment inside the vtable
};
 
struct _s__CatchableType {
  unsigned int      properties;       // bit 1: is a simple type

                                      //   bit 2: can be caught by reference only
                                      //   bit 3: has virtual base 
  _TypeDescriptor * pType             // pointer to std::type_info object.
  _PMD              thisDisplacement; // displacement of the object for this type
  int               sizeOrOffset;     // size of the type

  _PMFN             copyFunction;     // pointer to copy constructor or 0
};
typedef const _s__CatchableType _CatchableType;
 
struct _s__CatchableTypeArray {
  int              nCatchableTypes;         // number of entries in arrayOfCatchableTypes

  _CatchableType * arrayOfCatchableTypes[]; // array of pointers to all base types of the object
                                            //   including types that it can be implicitly cast to
};
typedef const _s__CatchableTypeArray _CatchableTypeArray;
 
struct _s__ThrowInfo {
  unsigned int          attributes;           // bit 1 for const, bit 2 for volatile

  _PMFN                 pmfnUnwind;           // function to destroy the exception object
  int        (__cdecl * pForwardCompat)(...);
  _CatchableTypeArray * pCatchableTypeArray;  // pointer to array of pointers to type information
};
typedef const _s__ThrowInfo _ThrowInfo;

That brings us to the wonderful mess that is catch (...). Depending on your compiler catch (...) may turn into the equivalent of __except(EXCEPTION_EXECUTE_HANDLER) or __except(0xE06D7363 == GetExceptionCode() ? EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH). In other words, either always execute the handler no matter what kind of SEH exception was triggered or only execute the handler if it's a C++ exception. In MSVC 2005 and later, the compiler chooses the conditional execution if compiled with /EHs and the unconditional execution if compiled with /EHa. With MSVC 2003 and earlier the compiler chooses the always execute option no matter if you use /EHa or /EHs.

Well, sort of. Take this sample program:

#include <iostream>
#include <windows.h>
 
int main(int, char **) {
  try {
    RaiseException(0, 0, 0, 0);
  } catch (...) {
    std::cout << "Moo." << std::endl;
  }
  return 0;
}

So what is the difference between /EHs and /EHa? MSVC supports two exception models: the synchronous exception model and the asynchronous exception model. The asynchronous model generates code with the assumption that any expression can throw an exception. The synchronous model assumes that exceptions can only be thrown by throw statements or function calls. This means that functions compile with the asynchronous model tend to generate more function state IDs for stack unwind and the associated data structures to support the additional possible exception points. And, as mentioned, in MSVC 2005 and later, using /EHa will allow catch (...) to catch SEH exceptions while /EHs does not. /EHc, which makes sense only when applied with /EHs, additionally makes the assumption that extern "C" functions do not throw exceptions.

A case can be made either way for catch (...) handling SEH exceptions. One point against is the simple fact that C++ exception handlers aren't supposed to handle things like divide by zero or access violations. One point for is the fact that since C++ stack unwind is implemented in terms of termination handler semantics, unless catch (...) handles SEH exceptions, a SEH exception will cause stack unwind, but will not trigger a rethrow clean up catch block. In the following example, if f() raises a SEH exception, the_object will be destroyed, but the catch (...) block won't execute.

  try {
    A the_object;
    f();
  } catch (...) {
    // clean up stuff
    throw;
  }

Unifying Exceptions in MSVC

Assuming you want to make sure that catch (...) handles SEH exceptions, the process is relatively simple in MSVC: use the /EHa flag instead of /EHsc for enabling exception handling information¹⁵⁾. For MSVC 7.1 and earlier, this prevents catch blocks from being removed by the optimizer, and is a necessary condition for the catch blocks doing so in MSVC 2005 and later. It will also most likely increase the image size for the module and will probably increase the process working set as well.

You can also take an additional step: installing an exception translator, a function that translates SEH exceptions into C++ exceptions. One of the simplest examples of this would be:

struct SEHException {
  SEHException(const EXCEPTION_RECORD & record) : record(record) {}
  EXCEPTION_RECORD record;
};
 
void translator_function(unsigned int, EXCEPTION_POINTERS * eps) {
  throw SEHException(*eps->ExceptionRecord);
}

 
int main(int, char **) {
  try {
    _set_se_translator(&translator_function);
    // stuff
  } catch (SEHException & e) {
    // handle the exception

  }
  return 0;
}

If you don't want to install an exception translator or don't want to use /EHa, but want the equivalent of a catch (...) block that handles SEH exceptions, you can also use a __finally block that checks for abnormal termination. Of course, this isn't a direct translation. The limitation on objects with unwind semantics may make this technique annoying to apply in a large number of situations, and you need to pay attention to control flow statements that may generate an abnormal termination such as returning out of the __try block. In practice this translation often requires creation of two extra functions: the original function calls a function with just a __try/__finally block which in turn calls a third function that performs the work of the original try block (and sometimes a fourth function to perform the work of the catch block).¹⁶⁾

Sometimes you want the opposite effect: being able to handle C++ exceptions inside an __except block. This is a much steeper challenge since most C++ objects can't be used effectively within a function that sports SEH handling blocks. However, functions called from a function with SEH handling blocks don't have the same restrictions, including functions called from a filter expression. You might be wondering why you would want to do this, especially since you can translate SEH exceptions into normal C++ exceptions with MSVC. Well, one interesting aspect of a filter expression is that it's executed in the context of the point of the exception, before stack unwind occurs. That means you can obtain quite a bit of diagnostic information about the point where the exception was triggered in a filter expression, such as a stack trace, and this functionality has no analogue in C++ catch blocks.

Within an SEH handler, to get at a C++ object for an exception requires duplicating some of the work that the compiler does automatically in C++ catch blocks. You need to check the exception code, and then use the _s__ThrowInfo to figure out how to map the pointer in the exception information to a pointer to a desired type. To demonstrate this, let's develop an application that contains a global handler for SEH exceptions and reports a stack trace when it handles an exception.¹⁷⁾

Bringing it all Together

Because SEH handler blocks can't be used in functions with C++ objects that have unwind semantics, normal RAII techniques don't work without a little finesse. For example, let's say I want two C++ objects in my main() function. One is an RAII object to initialize and cleanup the symbol handler for the stack walk and the for the other I want my exception handler's filter expression to write to a buffer that the will be displayed and saved in the __except, but I don't want to manually manage the memory, so I want to use a std::string. One way to handle this is to have the object created in one function and then have that function call a function that uses SEH handlers like so:

int main(int argc, char ** argv) {
  SymInit sym;
  std::string buffer;
  return seh_helper(argc, argv, buffer);
}

 
int seh_helper(int argc, char ** argv, std::string & buffer) {
  __try {
    return actual_main(argc, argv);
  } __except (filter(GetExceptionInformation(), buffer)) {
    if (!buffer.empty()) {
      save_buffer(buffer);
      MessageBoxA(0, buffer.c_str(), "Abnormal Termination", MB_OK);
    }
    return -1;
  }
}

Similarly, if we try to perform a stack walk inside a filter expression, things could go wrong because of the reason of the exception. An exception can result because of heap corruption, stack corruption or any number of other states that would make performing the stack walk impossible. So to address this, you can break the filter function in two parts:

DWORD filter(EXCEPTION_POINTERS * eps, std::string & buffer) {
  __try {
    return do_filter(eps, buffer);
  } __except (EXCEPTION_EXECUTE_HANDLER) {
    return EXCEPTION_CONTINUE_SEARCH;
  }
}

For converting the SEH exception information to C++ exception information, I use this implementation:

struct UntypedException {
  UntypedException(const EXCEPTION_RECORD & er)
    : exception_object(reinterpret_cast<void *>(er.ExceptionInformation[1])),
      type_array(reinterpret_cast<_ThrowInfo *>(er.ExceptionInformation[2])->pCatchableTypeArray)
  {}
  void * exception_object;
  _CatchableTypeArray * type_array;
};

 
void * exception_cast_worker(const UntypedException & e, const type_info & ti) {
  for (int i = 0; i < e.type_array->nCatchableTypes; ++i) {
    _CatchableType & type_i = *e.type_array->arrayOfCatchableTypes[i];
    const std::type_info & ti_i = *reinterpret_cast<std::type_info *>(type_i.pType);
    if (ti_i == ti) {
      char * base_address = reinterpret_cast<char *>(e.exception_object);
      base_address += type_i.thisDisplacement.mdisp;
      return base_address;
    }
  }
  return 0;
}

 
template <typename T>
T * exception_cast(const UntypedException & e) {
  const std::type_info & ti = typeid(T);
  return reinterpret_cast<T *>(exception_cast_worker(e, ti));
}

DWORD do_filter(EXCEPTION_POINTERS * eps, std::string & buffer) {
  std::stringstream sstr;
  const EXCEPTION_RECORD & er = *eps->ExceptionRecord;
  int skip = 0;
 
  switch (er.ExceptionCode) {
    case 0xE06D7363: { // C++ exception

      UntypedException ue(er);
      if (std::exception * e = exception_cast<std::exception>(ue)) {
        const std::type_info & ti = typeid(*e);
        sstr << ti.name() << ":" << e->what();
      } else {
        sstr << "Unknown C++ exception thrown.";
      }
      skip = 2; // skip RaiseException and _CxxThrowException

    } break;
    case EXCEPTION_ACCESS_VIOLATION: {
      sstr << "Access violation. Illegal "
           << (er.ExceptionInformation[0] ? "write" : "read")
           << " by "
           << er.ExceptionAddress
           << " at "
           << reinterpret_cast<void *>(er.ExceptionInformation[1]);
    } break;
    default: {
      sstr << "SEH exception thrown. Exception code: "
           << std::hex << std::uppercase << er.ExceptionCode
           << " at "
           << er.ExceptionAddress;
    }
  }
  sstr << "\n\nStack Trace:\n";
  generate_stack_trace(sstr, *eps->ContextRecord, skip);
  buffer = sstr.str();
  
  return EXCEPTION_EXECUTE_HANDLER;
}

      if (std::exception * e = exception_cast<std::exception>(ue)) {
        sstr << e->what();
      } else if (exception_cast<boost::python::error_already_set>(ue)) {
        PyErr_Print();
        // magically extract the contents of sys.stderr and put it in the stream

      } else {
        sstr << "Unknown C++ exception thrown.";
      }

void get_exception_types(std::ostream & os, const UntypedException & e) {
  for (int i = 0; i < e.type_array->nCatchableTypes; ++i) {
    _CatchableType & type_i = *e.type_array->arrayOfCatchableTypes[i];
    const std::type_info & ti_i = *reinterpret_cast<std::type_info *>(type_i.pType);
    os << ti_i.name() << "\n";
  }
}

Exception Handling Overhead

The word "overhead" in the context of exception handling is something of a loaded term, but no discussion of an specific implementation of exception handling is really complete without at least a minimal discussion of the performance consequences.

First off, when exception handling is enabled, every function that needs unwind semantics needs to execute additional prologue and epilogue code, as well as additional space on the stack to hold exception handling information. This depends on the function in question, the optimization settings, processor targeted and MSVC version, but works out to be about five instructions for the prologue and about three instructions for the epilogue in the common case and the additional space on the stack works out to about five pointer widths. The prologue and epilogue code may also be invoked via a function call rather than inlined; this will increase the cost of executing the prologue and epilogue code to gain some reductions in overall executable size. Additionally, quite a bit of code and data is added to the executable in order to actually process the exception and perform stack unwind.

Fortunately, these sources of overhead are significantly reduced in the presence of aggressive inlining, especially link time cross-module inlining. On the other hand, while MSVC is very good about inlining code, it's not so good at separating out redundant code from multiple functions. As mentioned earlier, when throwing a C++ exception, the compiler generates code to place a copy of the exception on the stack, then calls _CxxThrowException() with a pointer to the exception and a pointer to the _ThrowInfo for the exception type. On 32-bit x86, throw std::exception() could compile to something like:

  ; 6 : throw std::exception();
 
  lea   ecx, DWORD PTR $T5541[esp+12]
  call  DWORD PTR __imp_??0exception@@QAE@XZ
  push  OFFSET FLAT:__TI1?AVexception@@
  lea   eax, DWORD PTR $T5541[esp+16]
  push  eax
  call  __CxxThrowException@8

The exception model is implemented in such a way that translation units compiled with /EHs, /EHa or without exception handling enabled at all can coexist in an application. This means that another way to fight exception handling overhead is if a profiler shows a function to be a bottleneck, it can be separated into its own source file and compiled with a different exception handling switch to eliminate prologue and epilogue generation.

Finally there's the cost incurred of throwing and catching an exception versus returning an error code and checking and propagating the value. The relative cost of these situations are highly dependent on a number of situation specific modifiers such as how far nested the point of failure is compared to the location of the error handler, the number and type of objects that need to be unwound, optimization settings and so on. However, even the most optimistic estimates place throwing an exception as hundreds of times more expensive than returning an error code. The cost is probably closer to several thousands of times, if not more. Of course, this shouldn't be news to anyone experienced with C++ exceptions; exceptions should only be used for exceptional circumstances. This does, however, supply a metric for exception use: if the error condition is expected to occur more often than once out of every 10,000 times the function is run, then use an error code; otherwise use an exception.

Conclusion and References

This article only touches the surface of what can be done with customizing exception handling in MSVC, though it hopefully does cover the important consequences of the exception model if you don't intend on modifying the behavior. The following references include more detail on how SEH is implemented, how C++ exceptions are implemented with SEH and additional things you can do with exception handling with MSVC including instrumenting the _CxxThrowException() function and replacing the MSVC exception handler altogether.

• "A Crash Course on the Depths of Win32 Structured Exception Handling" by Matt Pietrek http://www.microsoft.com/msj/0197/exception/exception.aspx . This is one of the most frequently referenced articles explaining how SEH works on the Win32 platform.
• "The Exception Model" http://blogs.msdn.com/cbrumme/archive/2003/10/01/51524.aspx . A blog entry by one of the CLR developers explaining updates to the SEH mechanisms that have occurred since Matt Pietrek's article was published, as well as how the Common Language Runtime implements its exception handling system.
• "Structured Exception Handling" http://msdn2.microsoft.com/en-us/library/ms680657.aspx . MSDN's Platfrom SDK section on using SEH.
• "Reversing Microsoft Visual C++ Part I: Exception Handling" http://www.openrce.org/articles/full_view/21 . A detailed examination of the mechanics of exactly how the data structures and functions of the C++ exception handling mechanism works for MSVC.
• "How a C++ compiler implements exception handling" by Vishal Kochhar http://www.codeproject.com/KB/exception/exceptionhandlerByVishal%20Kochhar.aspx . Another detailed examination of the the MSVC C++ exception handling implementation.
• "Visual C++ Exception-Handling Instrumentation" by Eugene Gershnik http://www.ddj.com/windows/184416600 . A detailed explanation of how MSVC implements throwing C++ exceptions, including how to hook the exception handling implementation.
• "How to trap stack overflow in a Visual C++ application" http://support.microsoft.com/kb/315937 . A description of the minimum work necessary to handle stack overflow properly in a SEH exception handler.
• "Exceptions and Error Codes" by Kyle Wilson http://gamearchitect.net/Articles/ExceptionsAndErrorCodes.html . A game programmer's analysis of the relative costs of exception handling vs. error codes with MSVC 8.

The Complete Sample Application

The following is the complete code for running the application developed in the article. It suffers from many of the flaws of other article sample code examples: it exists to demonstrate techniques and points mentioned in the article and so does some things unnecessarily. For example, the buffer in the main() function exists to demonstrate a method to use an object with unwind semantics in a SEH handler rather than any actual need. Also, the code fails to properly handle exceptions resulting from stack overflows, only works on x86 processors, may cause cancer and the stack dump output is quite ugly.

//Copyright (c) 2007 Howard Jeng

//
//Permission is hereby granted, free of charge, to any person obtaining a copy
//of this software and associated documentation files (the "Software"), to deal
//in the Software without restriction, including without limitation the rights
//to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
//copies of the Software, and to permit persons to whom the Software is
//furnished to do so, subject to the following condition:
//
//THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR

//IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
//FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
//AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
//LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
//OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
//THE SOFTWARE.
 
#include <iostream>
#include <sstream>

#include <fstream>
 
#include <windows.h>
#include <dbghelp.h>
 
class SymInit {
  public:
    SymInit(void) : process_(GetCurrentProcess()) {
      SymInitialize(process_, 0, TRUE);
 
      DWORD options = SymGetOptions();
      options |= SYMOPT_LOAD_LINES;
      SymSetOptions(options);
    }
    ~SymInit() {
      SymCleanup(process_);
    }
  private:
    HANDLE process_;
    SymInit(const SymInit &);
    SymInit & operator=(const SymInit &);
};

 
std::string get_module_path(HMODULE module = 0) {
  char path_name[MAX_PATH] = {};
  DWORD size = GetModuleFileNameA(module, path_name, MAX_PATH);
  return std::string(path_name, size);
}
 
void write_module_name(std::ostream & os, HANDLE process, DWORD64 program_counter) {
  DWORD64 module_base = SymGetModuleBase64(process, program_counter);
  if (module_base) {
    std::string module_name = get_module_path(reinterpret_cast<HMODULE>(module_base));
    if (!module_name.empty())
      os << module_name << "|";
    else 
      os << "Unknown module|";
  } else {
    os << "Unknown module|";
  }
}

 
void write_function_name(std::ostream & os, HANDLE process, DWORD64 program_counter) {
  SYMBOL_INFO_PACKAGE sym = { sizeof(sym) };
  sym.si.MaxNameLen = MAX_SYM_NAME;
  if (SymFromAddr(process, program_counter, 0, &sym.si)) {
    os << sym.si.Name << "()";
  } else {
    os << "Unknown function";
  } 
}

 
void write_file_and_line(std::ostream & os, HANDLE process, DWORD64 program_counter) {
  IMAGEHLP_LINE64 ih_line = { sizeof(IMAGEHLP_LINE64) };
  DWORD dummy = 0;
  if (SymGetLineFromAddr64(process, program_counter, &dummy, &ih_line)) {
    os << "|" << ih_line.FileName
       << ":" << ih_line.LineNumber;
  }
}

 
void generate_stack_trace(std::ostream & os, CONTEXT ctx, int skip) {
  STACKFRAME64 sf = {};
  sf.AddrPC.Offset    = ctx.Eip;
  sf.AddrPC.Mode      = AddrModeFlat;
  sf.AddrStack.Offset = ctx.Esp;
  sf.AddrStack.Mode   = AddrModeFlat;
  sf.AddrFrame.Offset = ctx.Ebp;
  sf.AddrFrame.Mode   = AddrModeFlat;
   
  HANDLE process = GetCurrentProcess();
  HANDLE thread = GetCurrentThread();
  
  os << std::uppercase;
  for (;;) {
    SetLastError(0);
    BOOL stack_walk_ok = StackWalk64(IMAGE_FILE_MACHINE_I386, process, thread, &sf,
                                     &ctx, 0, &SymFunctionTableAccess64, 
                                     &SymGetModuleBase64, 0);
    if (!stack_walk_ok || !sf.AddrFrame.Offset) return;
    
    if (skip) {
      --skip;
    } else {
      // write the address

      os << std::hex << reinterpret_cast<void *>(sf.AddrPC.Offset) << "|" << std::dec;
 
      write_module_name(os, process, sf.AddrPC.Offset);
      write_function_name(os, process, sf.AddrPC.Offset);
      write_file_and_line(os, process, sf.AddrPC.Offset);
 
      os << "\n";
    }
  }
}

 
 
struct UntypedException {
  UntypedException(const EXCEPTION_RECORD & er)
    : exception_object(reinterpret_cast<void *>(er.ExceptionInformation[1])),
      type_array(reinterpret_cast<_ThrowInfo *>(er.ExceptionInformation[2])->pCatchableTypeArray)
  {}
  void * exception_object;
  _CatchableTypeArray * type_array;
};
 
void * exception_cast_worker(const UntypedException & e, const type_info & ti) {
  for (int i = 0; i < e.type_array->nCatchableTypes; ++i) {
    _CatchableType & type_i = *e.type_array->arrayOfCatchableTypes[i];
    const std::type_info & ti_i = *reinterpret_cast<std::type_info *>(type_i.pType);
    if (ti_i == ti) {
      char * base_address = reinterpret_cast<char *>(e.exception_object);
      base_address += type_i.thisDisplacement.mdisp;
      return base_address;
    }
  }
  return 0;
}

 
void get_exception_types(std::ostream & os, const UntypedException & e) {
  for (int i = 0; i < e.type_array->nCatchableTypes; ++i) {
    _CatchableType & type_i = *e.type_array->arrayOfCatchableTypes[i];
    const std::type_info & ti_i = *reinterpret_cast<std::type_info *>(type_i.pType);
    os << ti_i.name() << "\n";
  }
}

 
template <typename T>
T * exception_cast(const UntypedException & e) {
  const std::type_info & ti = typeid(T);
  return reinterpret_cast<T *>(exception_cast_worker(e, ti));
}
 
DWORD do_filter(EXCEPTION_POINTERS * eps, std::string & buffer) {
  std::stringstream sstr;
  const EXCEPTION_RECORD & er = *eps->ExceptionRecord;
  int skip = 0;
 
  switch (er.ExceptionCode) {
    case 0xE06D7363: { // C++ exception

      UntypedException ue(er);
      if (std::exception * e = exception_cast<std::exception>(ue)) {
        const std::type_info & ti = typeid(*e);
        sstr << ti.name() << ":" << e->what();
      } else {
        sstr << "Unknown C++ exception thrown.\n";
        get_exception_types(sstr, ue);
      }
      skip = 2; // skip RaiseException and _CxxThrowException

    } break;
    case EXCEPTION_ACCESS_VIOLATION: {
      sstr << "Access violation. Illegal "
           << (er.ExceptionInformation[0] ? "write" : "read")
           << " by "
           << er.ExceptionAddress
           << " at "
           << reinterpret_cast<void *>(er.ExceptionInformation[1]);
    } break;
    default: {
      sstr << "SEH exception thrown. Exception code: "
           << std::hex << std::uppercase << er.ExceptionCode
           << " at "
           << er.ExceptionAddress;
    }
  }
  sstr << "\n\nStack Trace:\n";
  generate_stack_trace(sstr, *eps->ContextRecord, skip);
  buffer = sstr.str();
  
  return EXCEPTION_EXECUTE_HANDLER;
}
 
DWORD filter(EXCEPTION_POINTERS * eps, std::string & buffer) {
  __try {
    return do_filter(eps, buffer);
  } __except (EXCEPTION_EXECUTE_HANDLER) {
    return EXCEPTION_CONTINUE_SEARCH;
  }
}
 

int actual_main(int, char **) {
  // do stuff
  
  // cause an access violation
  //char * ptr = 0; *ptr = 0;
  
  // divide by zero

  //int x = 5; x = x / (x - x);
  
  // C++ exception
  //throw std::runtime_error("I'm an exception!");
  throw 5;
  
  return 0;
}
 
void save_buffer(const std::string & buffer) {
  std::ofstream ofs("err_log.txt");
  if (ofs) ofs << buffer;
}
 

int seh_helper(int argc, char ** argv, std::string & buffer) {
  __try {
    return actual_main(argc, argv);
  } __except (filter(GetExceptionInformation(), buffer)) {
    if (!buffer.empty()) {
      save_buffer(buffer);
      MessageBoxA(0, buffer.c_str(), "Abnormal Termination", MB_OK);
    }
    return -1;
  }
} 
 

int main(int argc, char ** argv) {
  SymInit sym;
  std::string buffer;
  return seh_helper(argc, argv, buffer);
}

Discuss this article in the forums

Date this article was posted to GameDev.net: 3/27/2008
(Note that this date does not necessarily correspond to the date the article was written)

See Also:
Programming

© 1999-2008 Gamedev.net. All rights reserved. Terms of Use Privacy Policy
Comments? Questions? Feedback? Click here!