Defensive programming 101

What is defensive programming? Defensive programming is an approach to improve your source code and software, in the general terms of:

• Quality - Reducing the number of bugs
• Making source code readable: Comments, Comments, Comments....
• Making the software behave in a predictable manner.
• Code review and test the code in retail and debug builds.

I often see programmers make common mistakes like:

• Never checking return values after calling a function
• Hard coding HRESULTS to something other than the true error code was
• Using try/catch(...) statements (I will clarify this one).
• Not handling the error at all

I am about to show you the simple try/catch(...) statement. This is a powerful piece of code, however it is very deceptive because of what it hides - your exception if one occurs!! Don't get me wrong try catch statements are great, however catching everything with the catch(...) is very bad.

This is what a typical try/catch mistake:

Sample #1 (No try/catch statement) - This will cause an access violation when we try to write to the memory address of wszBuffer because it is uninitialized

#include "stdafx.h"
#include <stdio.h>
#include <strsafe.h>

#define BufferSize 64

int main(int argc, char *argv[])
{
     HRESULT hr = S_OK;
     wchar_t* wszBuffer = NULL;
     wchar_t* wsString = L"This is an access violation"
     hr = StringCchCopyW(wszBuffer, BufferSize, wsString);  <-- Raise exception here!!
     wprintf(L"Out string = %ws", wszBuffer);
     return 0;

}

When we run this code we get the following results: Unhandled exception at 0x00411ac3 in AccessViolation.exe: 0xC0000005: Access violation writing location 0x00000000.

Sample #2 (Using try/catch(...) statement) - This will catch the exception and allow the application continue and we will eventually crash later on.

#include "stdafx.h"
#include <windows.h>
#include <strsafe.h>

#define BufferSize 64

int main(int argc, char *argv[])
{
     HRESULT hr = S_OK;
     wchar_t* wszBuffer = NULL;
     wchar_t* wsString = L"This is an access violation"

     try
     {

          // Raise exception here and return the HRESULT for the failure
          hr = StringCchCopyW(wszBuffer, BufferSize, wsString);  

     }
     catch(...)
     {

        // 1. The StringCchcopyW failed now set the HRESULT to E_FAIL
        // 2. Output the wrong HRESULT and leave no indication to why we really failed.

          hr = E_FAIL;                     
          wprintf(L"Error hr = %08X", hr); 
     }

          wprintf(L"Out string = %ws", wszBuffer);
          return 0;
}

When we run this code we get the following results: Error hr = 80004005 - Out string = (null).

From a programmers view this would look ok because we caught and handled the problem, however we really raised an exception and never handled properly or reported it correctly. In addition to this being really bad here are a few more reasons:

1. You could raise an exception a few functions deeper and never ever know which function caused the exception.
2. You are throwing your exception away.

This can and will produce very unstable results for your application. One very important thing that was missed in the catch(...) statement was the exception that was raised. There are a few things that you need to keep in mind here when you are using exception handling.

1. Exception handling is very expensive because the compiler has to setup and tear down every try/catch statement even if they are not used.
2. Every time you throw an exception we are calling RaiseException which causes a trip to the kernel. For more information on RaiseException please see: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/base/raiseexception.asp

Why use expensive calls and throw away the most important information that can help you fix your application? Also what was so important and what did we miss when we the exception was raised?

Well, when you program runs a frame (known as a stack frame) is created and pushed on to the stack. Each frame can have multiple exception handlers (try/catch statements) which guard certain portions of your code like in the above example. At the time of an exception the kernel has to do a few things:

1. Invoke the Trap Handler. The Trap Handler will create a trap frame and an Exception Record. This Exception Record is a pointer to the EXCEPTION_POINTERS structure and contains the machine-independent description of the exception. For more information on EXCEPTION_RECORDS please see this article: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/base/exception_record_str.asp
2. Invoke the Exception Dispatcher. The Exception Dispatchers only job is to look for a handler to take care of the exception.
   1. The Exception Dispatchers first attempt will be to send a notification event to the debugger port to see if a debugger is attached. (This is where the First Chance exception comes from).
   2. If there is no debugger like WinDBG, CDB or Adplus attached to the process that caused the exception, or if the debugger doesn't handle that exception the exception dispatcher has to perform an extra task. Being that all processing happens behind the scenes in the kernel we don't have access the exception dispatcher helps us out by copying the trapped frame back over to the user mode process space. When this data is copied back over gets formatted in the form of a CONTEXT_RECORD. A CONTEXT_RECORD is pointer to the CONTEXT structure that contains the processor-specific description of the state of the processor at the time of the exception. Additionally the CONTEXT_RECORD sits at offset 0x004 inside the _EXCEPTION_POINTERS structure.
3. The Exception Dispatcher keeps looking for an exception handler and if one is not found it will keep unwinding all of the frames until it either finds one. If no handlers are found then the Exception Dispatcher will hand the exception back over to the kernel and you will end up with(a Second Chance Exception. At this point the application will be terminated.

This data is essential to fixing the bugs in your applications. As a alternative to the try/catch(...) is the at try/except statement. This statement will allow you to write your own exception filter that can display the exception and context records if you choose too. I am sharing my sample code out for those of you that are interesting in learning more about exception handling and what happens behind the scenes. This exception filter will call GetExceptionInformation which returns a pointer to the EXCEPTION_RECORDS structure and then searches for the exception handler. I did not write the portion for walking the call stacks and displaying the symbols. This exception filter is for X86 only, I didn't add the registers for the 64 bit processor.

For your code you would do the following:

#include "stdafx.h"
#include <windows.h>
#include <strsafe.h>

#define BufferSize 64

When we run this code we get the following results:

Exception - Access Violation: C0000005
EAX=CDCDCDCD EBX=01312720 ECX=01312720 EDX=01312720 ESI=00000000
EDI=7C809E01 EBP=0012FC30 ESP=0012FC0C EIP=38F373E0 FLG=00010246
CS=001B DS=001B SS=0023 ES=0023 FS=0023 GS=003B
Bit Flag: 00000001 - Memory Address Accessed: CDCDCDCD : 00000000

NOTE: If the bit flag value is zero, this thread attempted to read the inaccessible data.

If the bit flag value is 1, this thread attempted to write to an inaccessible address.

The second array element specifies the virtual address of the inaccessible data.

Exception handler executed!
Program will terminate!!

A more practical and real world approach to this for real world scenareos would be to run ADPlus -crash -pn <pid of your application>. By using ADPlus to capture all this information you will capture all first / second chance exceptions, and all of the call stacks associated.

For more information on AdPlus please see: How to use ADPlus to troubleshoot "hangs" and "crashes"

For more information on exception handling filters please see: http://msdn2.microsoft.com/en-us/library/s58ftw19.aspx

Dave