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:
I recently encountered what appears to be a very minor bug in Visual Studio 2015 Community Edition. I made some changes in a project I am working on, and navigated to the team explorer, to run a "diff" (i.e. invoke "Compare with Unmodified..." context menu) on a file I had changed. I then tried to search for a string within the solution, while I had the "diff" window open. The original file and thus the "diff" window file also happened to have the string being searched. I navigated to the "Find Result 1" window that listed the search results. I then used the "F8" shortcut to navigate through the search results, one after the other. When I reached the result pertaining to the file that had its equivalent "diff" file open, I was taken to the "diff" file as opposed to the actual file containing the search result. And once I reached that point, the "F8" shortcut stopped working and I could no more navigate through the rest of the search results using the "F8" shortcut. I had to further navigate the results using the mouse, to point at and select the next search result within the "Find Result 1" window.
Admittedly, this is a very minor bug but at times this kind of minor bug provide a window into a different underlying issue. And in this case, the fact that Visual Studio confuses between the temporary diff file and the actual file might be a clue as to there being potentially non obvious issues as well. Nevertheless, thought Visual Studio team might be interested to know.
Following is a quick demo of the bug: