Recently I encountered an exception while debugging an Intel® SGX powered enclave application. Interesting enough, unlike classic environment, where the point of problem is usually apparent, there wasn't much I could glean from the debugger with this particular instance of the exception. The call stack window was empty and the debugger didn't take me to the point of problem as it normally does.
This being an enclave application, as a first step, I wanted to find out where the exception was happening, as in, whether it was within the trusted environment or outside. So, I installed a custom trusted exception handler, using Intel® SGX SDK provided sgx_register_exception_handler API and ran the same application. The idea being, if the exception occurred within the trusted environment and if for some reason, the Intel® SGX Visual Studio add-on that handles the trusted debugging failed to capture the exception, I would be able to find out. The trusted custom exception handler I installed didn't get invoked. Based on that I could conclude that the trusted execution environment is unlikely to have been the triggering factor for this exception instance.
I then installed an exception handler within the untrusted application using vectored exception handling feature provided by Microsoft Win32 API AddVectoredExceptionHandler. Sure enough I hit the exception handler the next time I ran the application. I was then able to check whether the faulting address was within the enclave address range using Intel® SGX SDK provided sgx_is_within_enclave API, by invoking that API via the untrusted exception handler.
Admittedly, it was a developer error that caused the exception. In this case, by way of an attempt to access an enclave address space address. However, debuggers are designed to make it easier for developers to spot these developer errors. What made the problem all the more non-obvious was that it was happening during thread creation time. If the Intel® SGX Visual Studio add-on would include an exception handler to trap exceptions caused by access to trusted address space addresses, while running in untrusted context and provide more specific information, potentially along with information regarding the last OCALL or event that caused the transition from trusted context to untrusted, it can only make Intel® SGX applications development/porting all the more easier. An aggregate of such minor additions can only positively encourage further adoption of the technology.
Following is a demonstration of the problem described above: