In-depth Articles-

• [Matt Pietrek] Internals of SEH.
• [Matt Pietrek] Vectored Exception Handling.
• [Chris Brumme] Managed Exception Model.
• [Jeremy Gordon] SEH for assembler programmers.
• [Gaurav Khanna] How CLR maps SEH exceptions to managed exception types.

Tips and Tricks-

• [Raymond Chen] Sucking the exception pointers from a stack trace.
• [Mike Stall] Finding where unmanaged exceptions come from.
• [Gregg Miskelly] Debugging an UEF.
• [Skywing] Debugging a custom UEF.
• [MSDN] Identifying original culprit stack when UEF is on stack.
• [Zhanli] Adding vectored handlers and UEFs.

Misc-

• [Chris Brumme] Unhandled Exceptions.
• [Gaurav Khanna] Unhandled exception processing in the CLR.
• [Skywing] Beware of Custom UEFs in DLLs.
• [Skywing] You might be using UEFs without even knowing it.
• [Andrew Pardoe] Handling corrupted state exceptions
• [Andrew Pardoe] ThreadAbortException
• [Gaurav Khanna] Catch, Rethrow and filters - Why you should care
• [Mike Magruder] The good and the bad of exception filters
• [Andrew Pardoe] Why catch(Exception)/empty catch is bad

References-

• [MSDN] SEH (C++ reference)
• [MSDN] SEH
• [MSDN] Exception Handling (x64)
• [MSDN] Managed Exceptions
• [MSDN] Managed Exceptions (development guide)
• [MSDN] Search and unwind algorithm reference

In-depth Articles-

• [MSDN] Let CLR find bugs for you with MDAs

Tips and Tricks-

• [Thomas Lai] How to disable a specific MDA

Misc-

• [Mike Stall] MDAs are cool.
• [Thottam Sriram] Managed Debugging Assistants (MDAs).

References-

• [MSDN] MDA reference

Question: How does the runtime (CLR) decide which flavor of a module to load while profiling? Under what circumstances will it load the profiler-enhanced ngen’ed images? When does it load regular ngen’ed images? Can I use specific profiler event-masks to control the runtime’s behavior? I’m totally confused. Help! 

Answer: Pictures speak more than words…………

 Image File Execution options provides you with a mechanism to always launch an executable directly under the debugger. This is extremely useful if you ever need to investigate issues in the executable's startup code (services especially). You can set the IFEO options directly via the registry or indirectly using the Gflags tools (available with the Window debugging toolkit).   

You need to create a registry key and populate it with a value as follows -

You do not need the full path to the application, only the exe name will suffice. However you do need the full path to the debugger.  As an example, we look at launching notepad under ntsd, you would be creating the following -

You can also use Gflags to set IFEO too -

How does IFEO work?    

Kernel32!CreateProcess when called without the DEBUG_PROCESS or DEBUG_ONLY_THIS_PROCESS creation flags, checks the registry to see if IFEO has been set on the executable that it is launching. If yes, then it simply prepends the debugger path to the executable name, effectively getting the executable to launch under the debugger. If you do not specify the correct path to the debugger, then you'll probably get greeted with a "file not found" error. In our notepad/ntsd example above, Kernel32!CreateProcess ends up invoking -

"c:\dbg\ntsd.exe -g  notepad.exe"    

Now ntsd eventually launches notepad under the debugger by calling Kernel32!CreateProcess with one of the following creation flags - DEBUG_PROCESS or DEBUG_ONLY_THIS_PROCESS. The presence of any of these creation flags forces Kernel32!CreateProcess to bypass IFEO options this time around (else we would have been running into an endless loop) and actually launch the executable under the debugger.    

IFEO and 64 bit -    

A word of caution - For 32 bit executable running in the WOW on X64 machines, your natural tendency might be to create the registry key in the syswow node -

"HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<executable>"    

However Gregg Miskelly notes that you should set the IFEO corresponding to the bit-ness to the application calling into kernel32!CreateProcess to launch the executable -    

"On Win 64, there are two copies of HKEY_LOCAL_MACHINE\Software (one for 32-bit apps, and one for 64-bit apps), and therefore there are two copies of these options. However, where the operating system looks isn't dependant on the bit-ness of the application that is going to be debugged (which is what you would probably expect). Instead, it is dependent on the bit-ness of the application that called CreateProcess."

Other IFEO caveats - 

Raymond Chen notes the following caveat in his blog entry  -

"If you passed special parameters via the STARTUPINFO structure, those parameters get passed to the debugger. And the PROCESS_INFO that is returned by the CreateProcess function describes the debugger, not the process being debugged."

IFEO and Managed debuggers -

IFEO can only be used for native or interop debugging, but not for managed debugging. Mike Stall has an excellent blog entry that describes in great detail exactly why. The gist is this - Managed debuggers like Mdbg/cordbg/VS.NET use ICorDebug::CreateProcess to launch managed executables under the debugger. However for managed debugging, the debugger should call ICorDebug::CreateProcess without the DEBUG_PROCESS or DEBUG_ONLY_THIS_PROCESS creation flags (this is publicly documented). This API internally ends up calling Kernel32!CreateProcess without the DEBUG_PROCESS or DEBUG_ONLY_THIS_PROCESS creation flags. This leads to the endless loop that I described above. Is this an ICorDebug API design flaw?  Not really. Just an oversight in my opinion - The API designers missed one scenario. Maybe in the next version of the CLR this will be fixed (I do not know for sure).

Some excellent resources on IFEO -

Exercise for reader -

Does IFEO work with other Win32 APIs like ShellExecute, CreateProcessAsUser, CreateProcessWithLogonW and CreateProcessWithTokenW?

TIP of the day -

Question - System services can launch before the user has a chance to log on. So how do you debug the startup code of these system services?

Answer - Put the machine under kernel Debugger (KD), use IFEO to launch the service under NTSD (use ntsd's  "-d" option to pipe the ntsd output to KD) and reboot the machine. When the system service launches, it will be launched under ntsd.  The ntsd debugger will automatically cause it break into KD when it encounters the initial loader breakpoint. The debugging session will begin in user mode automatically (yipee!). After you are done debugging, switch control to KD by issuing ".breakin" command.

The "sigcheck" tool from sysinternals is of great help here. Use the "-m" option to view the embedded manifest.

Sigcheck v1.63 - File version and signature viewer

Copyright (C) 2004-2009 Mark Russinovich

Sysinternals - www.sysinternals.com

usage: \\live.sysinternals.com\tools\sigcheck.exe [-a][-h][-i][-e][-n][[-s]|[-v]|[-m]][-q][-r][-u][-c catalog file] <file or directory>

-a Show extended version information

-c Look for signature in the specified catalog file

-e Scan executable images only (regardless of their extension)

-h Show file hashes

-i Show catalog name and image signers

-m Dump manifest

-n Only show file version number

-q Quiet (no banner)

-r Check for certificate revocation

-s Recurse subdirectories

-u Show unsigned files only

-v Csv output

Here is an example. We'll use the sigcheck tool on notepad.

C:\>\\live.sysinternals.com\tools\sigcheck.exe -m c:\Windows\notepad.exe

Sigcheck v1.63 - File version and signature viewer

Copyright (C) 2004-2009 Mark Russinovich

Sysinternals - www.sysinternals.com

c:\windows\notepad.exe:

        Verified:       Signed

        Signing date:   5:30 AM 11/2/2006

        Publisher:      Microsoft Corporation

        Description:    Notepad

        Product:        Microsoft« Windows« Operating System

        Version:        6.0.6000.16386

        File version:   6.0.6000.16386 (vista_rtm.061101-2205)

        Manifest:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<!-- Copyright (c) Microsoft Corporation -->

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

<assemblyIdentity

    name="Microsoft.Windows.Shell.notepad"

    processorArchitecture="amd64"

    version="5.1.0.0"

    type="win32"/>

<description>Windows Shell</description>

<dependency>

    <dependentAssembly>

        <assemblyIdentity

            type="win32"

            name="Microsoft.Windows.Common-Controls"

            version="6.0.0.0"

            processorArchitecture="*"

            publicKeyToken="6595b64144ccf1df"

            language="*"

        />

    </dependentAssembly>

</dependency>

<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">

    <security>

        <requestedPrivileges>

            <requestedExecutionLevel level="asInvoker" uiAccess="false"/>

        </requestedPrivileges>

    </security>

</trustInfo>

</assembly>

FYI - You can "net use" into \\live.sysinternals.com\tools and use all the sysinternals tools like process explorer, process monitor etc. Isn't that cool?

NOTE - I wrote this up more than a year back and for some mysterious reasons forgot to post it! Much of what is written here applies to Vista UAC accounts as well.

QUESTION - Under Windows Server 2003, can a "limited user" impersonate an "administrator"?

ANSWER –  As you are aware, there are four impersonation levels, each of which indicates the degree to which one user can impersonate another – SecurityAnonymous, SecurityIdentification, SecurityImpersonation, and SecurityDelegation. A limited user on Windows Server 2003 (or UAC admin on vista) needs SE_IMPERSONATE_PRIVILEGE enabled in order to impersonate the context of an "administrator" at any level above "SecurityIdentification".

Consider this snippet of code executed in the context of a limited user (non-admin). An admin's token is first obtained and duplicated to create an impersonation token at security level "SecurityImpersonation". The limited user then attempts to impersonate the admin. If impersonation succeeds, then it tries some operation that requires admin privileges (In this case, creating a key under HKLM\Software\Microsoft with write access).  

void wmain () {     HANDLE  hPrivToken ;     HANDLE  hPrivTokenImperson ;       if ( 0 == LogonUser( L"administrator", L"MyMachine", L"MyPassWord",                          LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT,                          & hPrivToken ) )     {         wprintf( L"Failed to logon admin. Last Error = %d\n",                  GetLastError() ) ;         return ;     }       if ( 0 == DuplicateTokenEx( hPrivToken, TOKEN_QUERY | TOKEN_IMPERSONATE, NULL,                                 SecurityImpersonation, TokenImpersonation,                                 & hPrivTokenImperson ) )     {         wprintf( L"Failed to obtain impersonation token. Last Error = %d\n",                  GetLastError() ) ;         return ;     }       if ( 0 == SetThreadToken( NULL, hPrivTokenImperson ) )     {         wprintf( L"Failed to impersonate administrator. Last Error = %d\n",                  GetLastError() ) ;         return ;            }       //     // Do something that requires admin privileges…………     //     if ( ERROR_SUCCESS != RegCreateKeyEx( HKEY_LOCAL_MACHINE,                                           L"Software\\Microsoft\\RandomKey", 0, NULL,                                           REG_OPTION_NON_VOLATILE, KEY_READ | KEY_WRITE,                                           NULL, & hKey, & dwDisposition ) )     {         wprintf( L"RegCreateKeyEx FAILED. Last Error = %d\n",                  GetLastError() ) ;     }     else     {         wprintf( L"RegCreateKeyEx SUCCEEDED.\n" ) ;     }       SetThreadToken( NULL, NULL ) ; // revert back }

Under Windows XP, the limited user is successfully able to impersonate the admin at level SecurityImpersonation. However on Windows 2003 and Vista things are a bit different because of the security changes related to SE_IMPERSONATE_PRIVILEGE that I described above. Although the first call to SetThreadToken() succeeds, the impersonation is being sneakily carried out at level SecurityIdentification. As a result of which your privileged operation (writing to HKLM in this case) fails with an access-denied error. Sweet! On Windows Server 2003 and above, the ability to impersonate at SecurityImpersonation and above is given only to Network Service, Local Service, Local System and Administrators (On Vista you need to be running elevated as well to have SE_IMPERSONATE_PRIVILEGE enabled in the token).

• Mainly used in PInvoke Signatures
• By default, while using DllImportAttribute to p-invoke, the DllImportAttribute.PreserveSig is set to true.
• If false: Converts returned HRESULTS from unmanaged signature to managed exceptions if they are not S_OK.
• If true: Does not convert returned HRESULT to exceptions.

PreserveSigAttribute (pseudo custom attribute)–

• This is mainly used in COM interface definitions in managed code.
• By default, for COM interface methods, the CLR does HRESULT to exception transformations (opposite behavior to that of pinvoke).
• If attribute applied: Does not convert returned HRESULT to exceptions.
• If attribute not applied: Default behavior of HRESULT to exception transformations.

My short-term memory is bad and I tend to forget things as soon as I learn them. So I jotted this down while I was reading Adam Nathan's excellent manuscript on COM interop. Hope you find this tidbit useful as well. 

Since I have no energy to type a long post today (sigh), I'll spare you the gory details on the cause of this error. Here are the main reasons why you would be seeing this error -

• While expecting to debug a v2.0.xxxx managed app, you have forgotten to implement ICorDebugManagedCallback2 in your managed callback handler. The managed callback handler must implement both ICorDebugManagedCallback and ICorDebugManagedCallback2 in such cases.

class ManagedEngine : public ICorDebugManagedCallback, public ICorDebugManagedCallback2 { }

• While implementing QueryInterace(..), you probably forgot to account for ICorDebugManagedCallback2.

    

HRESULT __stdcall ManagedEngine::QueryInterface(const IID & iid, void** ppv) {        if (iid == IID_IUnknown)         * ppv = static_cast<ICorDebugManagedCallback*>(this); // original implementation     else if (iid == IID_ICorDebugManagedCallback)         * ppv = static_cast<ICorDebugManagedCallback*>(this);     else if (iid == IID_ICorDebugManagedCallback2)         * ppv = static_cast<ICorDebugManagedCallback2*>(this);     else     {         * ppv = NULL;         return E_NOINTERFACE;     }     reinterpret_cast<IUnknown*>(*ppv)->AddRef();     return S_OK; }

Ever seen this run-time failure? - "The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention"

Whenever I get sloppy, I tend to write awful code as shown below -

FARPROC pDllFunc = NULL; HRESULT (* pDllGetReqRuntimeVer) (LPWSTR, LPWSTR, DWORD, DWORD*); HMODULE hModuleMscoree = LoadLibrary(L"mscoree.dll");   if(NULL != hModuleMscoree) {     pDllFunc = GetProcAddress(hModuleMscoree, "GetRequestedRuntimeVersion");     if(NULL != pDllFunc)     {         pDllGetReqRuntimeVer = (HRESULT(*)(LPWSTR, LPWSTR, DWORD, DWORD*))pDllFunc;         hr = pDllGetReqRuntimeVer(                     thrParam->cmdLineSw.pwszImage,                     wszDebuggeeVer,                     sizeof(wszDebuggeeVer)/sizeof(wszDebuggeeVer[0]),                     & dws);          :         :         :     } }

When sloppy, I forget to use the correct calling convention while declaring function pointers. Then I run into the above run-time error while calling into various functions exported by dlls (mscoree!GetRequestedRuntimeVersion in above example). Most Win32 APIs are declared as __stdcall which expects the "callee" to cleanup the stack. I compile with /Gd (uses __cdecl as default convention). Because I forgot of mark the function pointer with __stdcall, the run-time is now expecting the "caller" to cleanup the stack. Fortunately I'm bailed out by the above run time check. To correct this the, function pointer must be declared and used as follows -

FARPROC pDllFunc = NULL; HRESULT (__stdcall * pDllGetReqRuntimeVer) (LPWSTR, LPWSTR, DWORD, DWORD*); HMODULE hModuleMscoree = LoadLibrary(L"mscoree.dll");   if(NULL != hModuleMscoree) {     pDllFunc = GetProcAddress(hModuleMscoree, "GetRequestedRuntimeVersion");     if(NULL != pDllFunc)     {         pDllGetReqRuntimeVer = (HRESULT(__stdcall *)(LPWSTR, LPWSTR, DWORD, DWORD*))pDllFunc;         hr = pDllGetReqRuntimeVer(                     thrParam->cmdLineSw.pwszImage,                     wszDebuggeeVer,                     sizeof(wszDebuggeeVer)/sizeof(wszDebuggeeVer[0]),                     & dws);         :         :         :     } }

Given below are the native disassemblies (function prolog and epilog) when you use __cdecl and __stdcall respectively. As you can see, for the function marked as __cdecl, the "caller" is cleaning up the stack. While the "callee" does the needful when __stdcall is used.

When using __cdecl 

00412DB1  mov         esi,esp

00412DB3  lea         eax,[dws]

00412DB9  push        eax 

00412DBA  push        80h 

00412DBF  lea         ecx,[ebp-168h]

00412DC5  push        ecx 

00412DC6  mov         edx,dword ptr [ebp-48h]

00412DC9  mov         eax,dword ptr [edx+10h]

00412DCC  push        eax 

00412DCD  call        dword ptr [ebp-61Ch]

00412DD3  add         esp,10h  ß----------- stack is cleaned by caller!

00412DD6  cmp         esi,esp

00412DD8  call        @ILT+840(__RTC_CheckEsp) (41134Dh) ß------ The run time check

00412DDD  mov         dword ptr [ebp-18h],eax

When using __stdcall 

00412DB1  mov         esi,esp

00412DB3  lea         eax,[dws]

00412DB9  push        eax 

00412DBA  push        80h 

00412DBF  lea         ecx,[ebp-168h]

00412DC5  push        ecx 

00412DC6  mov         edx,dword ptr [ebp-48h]

00412DC9  mov         eax,dword ptr [edx+10h]

00412DCC  push        eax 

00412DCD  call        dword ptr [ebp-61Ch]

00412DD3  cmp         esi,esp ß--------- At this stage callee has already cleaned up stack

00412DD5  call        @ILT+840(__RTC_CheckEsp) (41134Dh) ß------ The run time check

00412DDA  mov         dword ptr [ebp-18h],eax

I should be paying more attention to the calling conventions and instead of relying on this run-time check. But it is nice to have this safety net.

- Ronaldo