HOWTO: JIT Debug a COM Local Server

• Microsoft Visual C++, 32-bit Editions, version 6.0
  on the following platforms: NT
• Windows 2000

SUMMARY

When an exception (for example, an access violation) is thrown from within a COM method, the server gets the first chance to handle the exception. If the server does not handle the exception, the COM/remote procedure call (RPC) run time handles it and returns an error indicating the exception was thrown. This behavior is by design.

The result of this is that no exception thrown in a COM method [including DebugBreak()] ever goes unhandled. As a result, just-in-time (JIT) debugging of COM local servers is difficult at best.

This article presents a way to JIT debug some exceptions from a COM local server. The article also explains how to pseudo-JIT debug a COM local server for other exceptions.

MORE INFORMATION

JIT Debug a COM Local Server

HKEY_LOCAL_MACHINE\Software\Microsoft\Ole
IgnoreServerExceptions="Y" 

• STATUS_ACCESS_VIOLATION



• STATUS_POSSIBLE_DEADLOCK



• STATUS_DATATYPE_MISALIGNMENT



• STATUS_INSTRUCTION_MISALIGNMENT



• STATUS_ILLEGAL_INSTRUCTION



• STATUS_PRIVILEGED_INSTRUCTION

Pseudo-JIT Debug a COM Local Server

1. All functions must be wrapped in a Win32 structured exception handling try-except block; for example:




LONG MyUnhandledExceptionFilter(EXCEPTION_POINTERS *ExceptionInfo);

#define PJITTry  \ 
    __try { \ 
        UINT __oldErrMode = SetErrorMode(0);

#define PJITExcept(x) \ 
    SetErrorMode(__oldErrMode); \ 
    } __except (MyUnhandledExceptionFilter(GetExceptionInformation())) {}

HRESULT MyClass::MyMethod (BSTR bstrName) {
    PJITTry {
        return MyClass::_MyMethod(bstrName);
    }
    PJITExcept {}

} 

Note that if you are using C++ exception handling (try-catch), then you must provide stub functions in a different file that call the real functions so you can wrap the function call in a try-except block.

Depending on your circumstances, the wrapper functions can be introduced in various ways. You need to think about your approach carefully, before beginning, to reduce the overall amount of work. For instance, in the example above, if MyClass had many methods, it may be easier to derive a class and override all interface methods than to rename all of the real methods:

class MyDebugClass : public MyClass {
    //... lots of methods
    virtual HRESULT MyMethod (BSTR bstrName) {
        PJITTry {
            return MyClass::_MyMethod(bstrName);
        }
        PJITExcept {}
    }

} 

If you use the STDMETHOD and STDMETHODIMP macros, it may be as easy as undefining and redefining these macros.

There are many other ways to wrap your functions. It is not possible to provide an exhaustive list in this article.


2. The next step is to include the function below as a separate .cpp file in your project:

   
   #ifndef _WIN32_WINNT
   #define _WIN32_WINNT 0x400
   #endif
   #include <windows.h>
   #include <tchar.h>
   extern "C"
   LONG MyUnhandledExceptionFilter(EXCEPTION_POINTERS *ExceptionInfo)
   {
       __try {
           CHAR AeDebuggerCmdLine[MAX_PATH];
           if(IsDebuggerPresent()) return EXCEPTION_CONTINUE_SEARCH;
           if (0 == GetProfileString(
               _T("AeDebug"),
               _T("Debugger"),
               NULL,
               AeDebuggerCmdLine,
               sizeof(AeDebuggerCmdLine)-1)
               )
           {
               return EXCEPTION_CONTINUE_SEARCH;
           }
           BOOL b;
           STARTUPINFO si;
           PROCESS_INFORMATION pi;
           CHAR CmdLine[MAX_PATH];
           DWORD Status;
           HANDLE hEvent;
           SECURITY_ATTRIBUTES sa;
           sa.nLength = sizeof(sa);
           sa.lpSecurityDescriptor = NULL;
           sa.bInheritHandle = TRUE;
           hEvent= CreateEvent(&sa,TRUE,FALSE,NULL);
           ZeroMemory(&si,sizeof(si));
           wsprintf(CmdLine,AeDebuggerCmdLine,GetCurrentProcessId(),hEvent);
           si.cb = sizeof(si);
           si.lpDesktop = _T("Winsta0\\Default");
           b =  CreateProcess(NULL,CmdLine,0,0,TRUE,0,0,0,&si,&pi);
           if ( b && hEvent) {
               Status = WaitForSingleObject(hEvent,INFINITE);
               return EXCEPTION_CONTINUE_EXECUTION;
           }
           return EXCEPTION_CONTINUE_SEARCH;
       } // end __try
       __except (EXCEPTION_EXECUTE_HANDLER)
       {
           return EXCEPTION_CONTINUE_SEARCH;
       }
   } 

   The caveats with this code are:
   
   
   • The code requires the exception to be repeatable. When we attach the debugger, we continue execution to cause another exception. If the continued execution doesn't cause the exception again, then we have lost the opportunity to debug.
   
   
   
   • The debugger doesn't stop on first-chance exceptions by default. Because this exception is handled by a RPC, we must force the debugger to stop on the first-chance notification.
   
   
   



3. Force the debugger to stop on first-chance exceptions, as follows:
   
   
   1. Start Developer Studio.
   
   
   
   2. From the File menu, click Open, and find the executable for the local server.
   
   
   
   3. From the Build menu, click Debug, then click Go (or Step Into).
   
   
   
   4. From the Debug menu, click Exceptions.
   
   
   
   5. Change all exceptions to stop always.
   
   
   
   6. From the Debug menu, click Stop Debugging.
   
   
   
   7. From the File menu, click Close Workspace. When prompted, save the workspace options.
   
   
   

Additional query words:

Keywords : kbDebug kbNTOS kbWinOS2000 kbVC600 kbDSupport
Version : winnt:6.0; :
Platform : winnt
Issue type : kbhowto