This is one of the interesting scenario in which an unmanaged application built with Non-Microsoft technology was crashing during application shutdown with BOOTUP_EXCEPTION_COMPLUS exception (c0020001). This unmanaged application happened to be using unmanaged dll (built with Microsoft compiler) which in turn used IJW (a.k.a. C++ Interop) to interact with windows forms and create some ActiveX controls.

Now as you might know BOOTUP_EXCEPTION_COMPLUS occurs if a call is made in the managed code before the execution engine has finished initializing, or after it has started shutting down. Have a look at cbrume’s blog to know more about BOOTUP_EXCEPTION_COMPLUS. To confirm the cause of the problem and troubleshoot thoroughly, WinDbg was an obvious choice.

After aligning symbols correctly for Microsoft modules, the call stack showed the exception being raised during a call to a window procedure. See frame 5 below which shows a function call to user32!UserCallWinProcCheckWow. This indicates that a window procedure registered during the window creation is trying to process a message. Observe the below call stack carefully:

0:000> .lastevent
Last event: 1084.1150: Unknown exception - code c0020001 (first/second chance not available)
  debugger time: Thu Aug 27 00:09:57.524 2009 (GMT+6)

0:000> knL100
# ChildEBP RetAddr 
00 0012f99c 7a0967c9 kernel32!RaiseException+0x53
01 0012f9b8 7a0257a8 mscorwks!COMPlusThrowBoot+0x4a
02 0012f9c8 79e71e6d mscorwks!UMThunkStubRareDisableWorker+0x25
03 0012f9e8 7739b6e3 mscorwks!UMThunkStubRareDisable+0xa
04 0012fa14 7739b874 user32!InternalCallWinProc+0x28
05 0012fa8c 7739c8b8 user32!UserCallWinProcCheckWow+0x151
06 0012fae8 7739c9c6 user32!DispatchClientMessage+0xd9
07 0012fb10 7c828556 user32!__fnDWORD+0x24
08 0012fb3c 7739d1ec ntdll!KiUserCallbackDispatcher+0x2e
09 0012fb90 77393c27 user32!NtUserMessageCall+0xc
0a 0012fbac 77393c91 user32!RealDefWindowProcA+0x47
0b 0012fbf4 0127b962 user32!DefWindowProcA+0x72
…[Snip]

Now, the next question was to know which window is processing the messages and why. To determine these details with public symbols, you have to manually see the raw call stack. This can be done by running WinDbg command dds. See below output:

0:000> dds 0012fa14
0012fa14  0012fa8c <Unloaded_.DLL>+0x124d57
0012fa18  7739b874 user32!UserCallWinProcCheckWow+0x151
0012fa1c  015b5052 <Unloaded_ure.dll>+0x15b5051
0012fa20  000202b6 <Unloaded_.DLL>+0x15581
0012fa24  0000001c <Unloaded_ure.dll>+0x1b
0012fa28  00000000
0012fa2c  0000178c <Unloaded_ure.dll>+0x178b

One of the values we are interested in is the handle to the window which is processing the message. In this case it is 000202b6. As you read further, you will come to know what this value resembles to.

Now if you analyze the disassembly for mscorwks!UMThunkStubRareDisableWorker, you will notice that even before routing the message to the window procedure the stub function first confirms if it is safe to run the managed code. It does this by calling mscorwks!CanRunManagedCode. If this call returns a value indicating “No”, the stub method throws the BOOTUP_EXCEPTION_COMPLUS. This was exactly the same in this case.

0:000> uf mscorwks!UMThunkStubRareDisableWorker
mscorwks!UMThunkStubRareDisableWorker:
7a025783 55              push    ebp
7a025784 8bec            mov     ebp,esp
7a025786 56              push    esi
7a025787 6a00            push    0
7a025789 6a01            push    1
7a02578b e8896cf2ff      call    mscorwks!CanRunManagedCode (79f4c419)
7a025790 85c0            test    eax,eax
7a025792 8b7508          mov     esi,dword ptr [ebp+8]
7a025795 7511            jne     mscorwks!UMThunkStubRareDisableWorker+0x25 (7a0257a8)

mscorwks!UMThunkStubRareDisableWorker+0x14:
7a025797 682b040780      push    8007042Bh
7a02579c c7460800000000  mov     dword ptr [esi+8],0
7a0257a3 e8ff0f0700      call    mscorwks!COMPlusThrowBoot (7a0967a7)

...[Snip]

Now if the managed code is not allowed to execute, why the managed window is still alive and registered for receiving the messages? Well, a quick look into the managed heap reveals that “Microsoft.Win32.SystemEvents” object is still alive! Ideally this object is destroyed during application cleanup phase; however this was not the case. Now, SystemEvents actually provides access to system event notifications like display setting changed, user preference changed, etc. This is achieved by creating a hidden window having a specific “windowHandle”. If you carefully analyze below command you will notice the “windowHandle” for these events is 202b6 which is exactly the same value for the window trying to process the message. This window is actually the “.NET-BroadcastEventWindow”, a special window, created for monitoring the system events.

0:000> .loadby sos mscorwks

0:000> !DumpHeap -stat
total 101243 objects
Statistics:
      MT    Count    TotalSize Class Name
7a5d2608        1           20 Microsoft.Win32.SystemEvents

…[Snip]

0:000> !DumpHeap -MT 0x7a5d2608
Address       MT     Size
017eacd8 7a5d2608       20
total 1 objects
Statistics:
      MT    Count    TotalSize Class Name
7a5d2608        1           20 Microsoft.Win32.SystemEvents
Total 1 objects

0:000> !do 017eacd8
Name: Microsoft.Win32.SystemEvents
MethodTable: 7a5d2608
EEClass: 7a4724fc
Size: 20(0x14) bytes
(C:\WINDOWS\assembly\GAC_MSIL\System\2.0.0.0__b77a5c561934e089\System.dll)
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
793332c8  40015b8        c        System.IntPtr  1 instance    202b6 windowHandle
79330a00  40015b2      568        System.String  0   static 017ead88 className
…[Snip]

0:000> du 017ead88+c
017ead94  ".NET-BroadcastEventWindow.2.0.0."
017eadd4  "0.9585cb.0"

The next step was to find why the window did not get destroyed. Reflecting the code for “Microsoft.Win32.SystemEvents.Initialize” shows that this window gets destroyed during the call to “SystemEvents.Shutdown()”.  See below code snippet:

private void Initialize()
{
   this.consoleHandler = new NativeMethods.ConHndlr(this.ConsoleHandlerProc);
   if (!UnsafeNativeMethods.SetConsoleCtrlHandler(this.consoleHandler, 1))
    {
       this.consoleHandler = null;
    }
   this.windowHandle = this.CreateBroadcastWindow();
   AppDomain.CurrentDomain.ProcessExit += new EventHandler(SystemEvents.Shutdown);
   AppDomain.CurrentDomain.DomainUnload += new EventHandler(SystemEvents.Shutdown);
}

Further, SystemEvents.Shutdown() method is called when either AppDomain.CurrentDomain.ProcessExit() or AppDomain.CurrentDomain.DomainUnload() events are served. Now these events are not guaranteed to be called always, mostly during rude exit (application directly calling kernel32!TerminateProcess/ExitProcess or StackOverFlow). So to confirm if the application is not running into a rude exit you can set breakpoints on above methods and see if it hits. It was confirmed that the problem was indeed with ProcessExit/DomainUnload events not getting called, due to which the broadcast window remains alive and thus executes the window procedure even when CLR is about to shutdown. 

A crude way to get around with the problem is to manually call SystemEvents.Shutdown() using System.Reflection just before closing the application. However, the reliable solution to the problem is to make sure the CRT/CLR cleanup code is correctly executed. For a mixed mode application, one of the crt functions which does this is exit(). It makes sure CRT/CLR code is correctly cleaned up and ProcessExit/DomainUnload events are called thus ensuring a correct cleanup.

- Gaurav Patole,

Technical Lead, Developer Support Languages Team.

Most of the developers work with CToolBarCtrl but they get stuck when it comes to display chevron button. This article is all about how to get chevron button displayed on CToolBarCtrl control while resizing its content window.

 

There is a good MSDN article on handling chevrons but no good sample implementation on it. I wrote a small sample using CDialog, CToolBarCtrl and CReBarCtrl classes to illustrate the same.

 

Since the main focus would be on handling chevron button, I am not going to cover tool bar control implementation details. Following are the steps to achieve chevron button on CToolBarCtrl.

 

1.       Using class wizard, create a new class CCustReBarCtrl deriving it from CReBarCtrl MFC class. Add m_wndReBar  and m_wndToolBar  of type CCustReBarCtrl and CToolBarCtrl respectively in dialog class. Create rebar and tool bar controls in OnInitDialog() dialog method as shown below.

 

m_wndReBar.CreateEx(WS_EX_TOOLWINDOW, WS_CHILD | WS_BORDER | WS_VISIBLE | WS_CLIPCHILDREN | WS_CLIPSIBLINGS | CCS_NOPARENTALIGN | CCS_NODIVIDER | RBS_VARHEIGHT | RBS_BANDBORDERS, CRect(0, 0, 0, 0), this, 10);

 

m_wndToolBar.Create(WS_CHILD | WS_CLIPCHILDREN | WS_CLIPSIBLINGS | CCS_NOPARENTALIGN | CCS_NODIVIDER | CCS_NORESIZE | TBSTYLE_TRANSPARENT | TBSTYLE_FLAT, CRect(0,0,0,0), &m_wndReBar, IDR_MAINFRAME);  //Note that rebar control is parent for tool bar control.

 

/*Make sure that tool bar resource is loaded here*/

 

m_wndToolBar.AutoSize();

 

Rebar control provides chevron control when RBBS_USECHEVRON flag in the fStyle member of the band's REBARBANDINFO structure is set. Before defining the band info, define the following macro in stdafx.h file.

#define REBARBANDINFO_SIZE CCSIZEOF_STRUCT(REBARBANDINFO, cxHeader)

 

SIZE sizeButtons;

m_wndToolBar.GetMaxSize(&sizeButtons);

 

REBARBANDINFO rbi;

ZeroMemory((void*)&rbi, sizeof(rbi));

rbi.cbSize = REBARBANDINFO_SIZE; // V5 structure size. Insert fails if the struct is too big

rbi.fMask = RBBIM_CHILD | RBBIM_CHILDSIZE | RBBIM_IDEALSIZE | RBBIM_STYLE;

rbi.fStyle = RBBS_GRIPPERALWAYS | RBBS_USECHEVRON;

rbi.cyMaxChild = rbi.cyMinChild = rbi.cyChild = sizeButtons.cy;

rbi.cxIdeal = rbi.cx = sizeButtons.cx;

rbi.hwndChild = (HWND)m_wndToolBar;

m_wndReBar.InsertBand(-1, &rbi);

 

RECT rcWindow;

GetClientRect(&rcWindow);

 

m_wndReBar.MoveWindow(0, 0, rcWindow.right - rcWindow.left, sizeButtons.cy);

 

2.       It’s very important to size the rebar control accordingly when dialog is resized otherwise chevron button will not be displayed. So handle WM_SIZE message (OnSize() method) in the dialog class and add the following code as shown below.

if (m_wndReBar.GetSafeHwnd())

{

RECT rcRebar;

 

      m_wndReBar.GetWindowRect(&rcRebar);

      m_wndReBar.MoveWindow(0, 0, cx, rcRebar.bottom - rcRebar.top);

                }

 

3.       Now if you run the code and resize the dialog, chevron will be displayed for tools that have been covered. When a user clicks a chevron, the rebar control sends RBN_CHEVRONPUSHED notification. The NMREBARCHEVRON structure that is passed with the notification contains the band's identifier and a RECT structure with the rectangle occupied by the chevron. Your handler must determine which buttons are hidden and display the associated commands on a pop-up menu.

 

Add RBN_CHEVRONPUSHED notification in CCustReBarCtrl, after adding the message map should look like as shown below

 

BEGIN_MESSAGE_MAP(CCustRebarCtrl, CReBarCtrl)

                                ON_NOTIFY_REFLECT(RBN_CHEVRONPUSHED, & CCustRebarCtrl::OnRbnChevronPushed)

END_MESSAGE_MAP()

 

            Following is the code that goes into the chevron handler 'void CCustRebar::OnRbnChevronPushed(NMHDR *pNMHDR, LRESULT *pResult)' method

 

            LPNMREBARCHEVRON pnmrc = reinterpret_cast<LPNMREBARCHEVRON>(pNMHDR);

 

      RECT rcBand;

      RECT rcButton;

      RECT rcIntersect;

      REBARBANDINFO rbi;

      TBBUTTON tbb;

      UINT cButtons;

      UINT iButton;

      UINT iMenu;

      HMENU hmenuPopup;

      MENUITEMINFO mii;

      TCHAR szText[200];

      HRESULT hr;

      CImageList* pimlToolbar;

 

      //

      //  Get the child window for this band.

      ZeroMemory((void*)&rbi, sizeof(rbi));

      rbi.cbSize = REBARBANDINFO_SIZE;

      rbi.fMask = RBBIM_CHILD;

 

      GetBandInfo(pnmrc->uBand, &rbi);

     

      CToolBarCtrl *pTBarCtrl = (CToolBarCtrl *)CToolBarCtrl::FromHandle ( rbi.hwndChild );

      ASSERT(pTBarCtrl);

      ASSERT(pTBarCtrl->IsKindOf(RUNTIME_CLASS(CToolBarCtrl)));

 

    //

    //  Get the client rectangle of the child window

      pTBarCtrl->GetClientRect(&rcBand);

       

    //

    //  Get the number of buttons in the toolbar. This should fail when the

    //  child window is not a toolbar.

 

      if ((cButtons = pTBarCtrl->GetButtonCount()) == 0)

        return;

 

    //

    //  Starting from the leftmost button, retrieve each button's bounding

    //  rectangle until we find a button that is at least partially hidden

    for (iButton = 1; iButton < cButtons; iButton++)

    {

        //

        //  Get the button's rectangle

        ZeroMemory((void*)&rcButton, sizeof(rcButton));

     

        pTBarCtrl->GetItemRect(iButton, &rcButton);

     

        CRect rtTabButton(rcButton);

        CRect rtToolBarCtr(rcBand);

           

        CPoint ptCenter = rtTabButton.CenterPoint();

           

           

         if(!rtToolBarCtr.PtInRect(ptCenter))

            break;

    }

 

      //

    //  Nothing to do if we didn't find a hidden button

    if (iButton == cButtons)

        return;

 

    //

    //  Allocate an array of bitmaps to hold the images used in menu items. An

    //  alternate approach is to ownerdraw the menu

    UINT cImages = cButtons - iButton;

    size_t cb = sizeof(HBITMAP) * cImages;

    HBITMAP* ahbmpImages = (HBITMAP*)malloc(cb);

    if (!ahbmpImages)

        return;

    ZeroMemory((void*)ahbmpImages, cb);

 

    //

    //  Create a memory DC that we use to render the toolbar images

    HDC hdcMem = NULL;

    HDC hdcWindow = ::GetDC(m_hWnd);

    if (hdcWindow)

    {

        hdcMem = CreateCompatibleDC(hdcWindow);

    }

 

    //

    //  Create a popup menu for the hidden toolbar items

    hmenuPopup = CreatePopupMenu();

 

    //

    //  Get the image list for the toolbar

    int cxImage = 0;

    int cyImage = 0;

 

    pimlToolbar = pTBarCtrl->GetImageList();

 

    if (pimlToolbar)

    {

        ImageList_GetIconSize(*pimlToolbar, &cxImage, &cyImage);

    }

       

    //

    //  Create a menu item for each hidden toolbar item

    iMenu = 0;

    for ( ; iButton < cButtons; iButton++)

    {

        ZeroMemory((void*)szText, sizeof(szText));

        ZeroMemory((void*)&tbb, sizeof(tbb));

 

           

     

        if (pTBarCtrl->GetButton(iButton, &tbb))

        { 

                  if(tbb.idCommand != 0)

                  {

                        LoadString(GetModuleHandle(NULL), tbb.idCommand, szText, sizeof(szText)-1);

                        int cch = strlen(szText);

                        szText[cch+1] = '\0';

                  }

 

            //

            //  Create a bitmap for the toolbar icon and draw the icon into the bitmap

            if (hdcMem && pimlToolbar->GetSafeHandle() && ahbmpImages)

            {

                ahbmpImages[iMenu] = CreateCompatibleBitmap(hdcWindow, cxImage, cyImage);

                if (ahbmpImages[iMenu])

                {

                    HBITMAP hbmpOld = (HBITMAP)SelectObject(hdcMem, ahbmpImages[iMenu]);

                    RECT rcImage = {0, 0, cxImage, cyImage};

 

                    //

                    //  First, fill the background with the menu background

                    FillRect(hdcMem, &rcImage, GetSysColorBrush(COLOR_MENU));

 

                    //

                    //  Then draw the icon

                    ImageList_Draw(pimlToolbar->GetSafeHandle(), tbb.iBitmap, hdcMem, 0, 0, ILD_NORMAL);

 

                    SelectObject(hdcMem, hbmpOld);

                }

            }

 

            //

            //  Add a menu item for this toolbar item

            ZeroMemory((void*)&mii, sizeof(mii));

            mii.cbSize = sizeof(MENUITEMINFO);

            mii.fMask = MIIM_STRING;

            mii.dwTypeData = szText;

            mii.wID = tbb.idCommand;

 

            if (ahbmpImages[iMenu])

            {

                mii.fMask |= MIIM_BITMAP;

                mii.hbmpItem = ahbmpImages[iMenu];

            }

 

            InsertMenuItem(hmenuPopup, iMenu++, TRUE, &mii);

        }

    }

 

    //

    //  Display the popup menu if it has menu items

    if (0 < GetMenuItemCount(hmenuPopup))

    {

            ::MapWindowPoints(pnmrc->hdr.hwndFrom, NULL, (LPPOINT)&pnmrc->rc, 2);

        TrackPopupMenu(hmenuPopup,

                       TPM_LEFTALIGN | TPM_TOPALIGN,

                       pnmrc->rc.left, pnmrc->rc.bottom,

                       0, m_hWnd, NULL);

    }

 

    //

    //  Destroy the popup menu

    DestroyMenu(hmenuPopup);

 

    //

    //  Cleanup the bitmaps

    if (ahbmpImages)

    {

        while (cImages)

        {

            cImages--;

            if (ahbmpImages[cImages])

                DeleteObject(ahbmpImages[cImages]);

        }

        free(ahbmpImages);

    }

 

    //

    //  Release the DCs used to handle the bitmaps

    if (hdcMem)

    {

        DeleteDC(hdcMem);

    }

 

    if (hdcWindow)

    {

            ::ReleaseDC(m_hWnd, hdcWindow);

    }

 

      // TODO: Add your control notification handler code here

      *pResult = 0;

 

Suppose you are calling some native code from your managed code, and you observe an Access Violation crash soon after returning from the native code inside your managed code. if you run the application inside the Visual Studio debugger you will see the following exceptions in the output window if IDE.

 

First-chance exception at 0x5eaf30b0 in TestApp.exe: 0xC0000090: Floating-point invalid operation.

First-chance exception at 0x5eaf30b0 in TestApp.exe: 0xC0000090: Floating-point invalid operation.

First-chance exception at 0x5eaf30b0 in TestApp.exe: 0xC0000090: Floating-point invalid operation.

First-chance exception at 0x5eaf30b0 in TestApp.exe: 0xC0000005: Access violation writing location 0x00133fec.

 

<crash>

 

OR

First-chance exception at 0x5eaf30b0  in TestApp.exe: 0xC0000091: Floating-point overflow.
First-chance exception at 0x79f958e3  in TestApp.exe: 0xC0000091: Floating-point overflow.
First-chance exception at 0x79f958e3  in TestApp.exe: 0xC0000091: Floating-point overflow.

First-chance exception at 0x79f958e3  in  TestApp.exe: 0xC0000005: Access violation writing location 0x001331ec.

....
<crash>

Or other Floating point exceptions with a Access violation at the end

 

These floating point exceptions gives a clue that somehow the FPCW (Floating Point Control Word) register has been changed inside the native code. Because its value has been changed so it results in floating point exceptions inside the managed code. Its stated in the ECMA specifications for IL  that IL floating point operations never throw exceptions. So CLR is not hardened against floating point exceptions.  Although it is allowed in native code to change the FPCW register, but you need  to restore it back to the old state as it was in before it was changed.

 

So the expectation here is that the FPCW should be restored to the same value as it was earlier before entering into the native code. In scenarios where the native code is not restoring this  register  we can call CRT’s  _controlfp() inside the managed code to reset FPCW soon after returning from native code.

 

Below is a sample code snippet which shows how to call  _controlfp() using pInvoke:

 

{

 

[DllImport("msvcrt.dll", CallingConvention = CallingConvention.Cdecl)]

        public static extern int _controlfp(int newControl, int mask);

 

        const int _RC_NEAR = 0x00000000;

        const int _PC_53 = 0x00010000;

        const int _EM_INVALID = 0x00000010;

        const int _EM_UNDERFLOW = 0x00000002;

        const int _EM_ZERODIVIDE = 0x00000008;

        const int _EM_OVERFLOW = 0x00000004;

        const int _EM_INEXACT = 0x00000001;

        const int _EM_DENORMAL = 0x00080000;

        const int _CW_DEFAULT = (_RC_NEAR + _PC_53 +

                                 _EM_INVALID + _EM_ZERODIVIDE +

                                 _EM_OVERFLOW + _EM_UNDERFLOW +

                                 _EM_INEXACT + _EM_DENORMAL);

 

      public SomeCode()

      {

 

      Some_unmanahed_code();                       /*this is the native code which alters the FPCW regiester */

      int value = _controlfp(_CW_DEFAULT, 0xfffff);    /* Calling _controlfp()using pInvoke     */ 

      Some_managed_call()                          /*Calling the maanged code using pInvoke  */

 

      }

 

}

 

 

I found this “initial Control Word” value as _CW_DEFAULT in the float.h file.

 

/* initial Control Word value */

#if     defined(_M_IX86)

#define _CW_DEFAULT ( _RC_NEAR + _PC_53 + _EM_INVALID + _EM_ZERODIVIDE + _EM_OVERFLOW + _EM_UNDERFLOW + _EM_INEXACT + _EM_DENORMAL)

 

 

Regards,

Bhupendra Dhyani

Recently I worked with one of my colleague on an interesting scenario in which the MFC application was crashing on startup. The next step was to run the application under WinDbg. After running the application under WinDbg we saw that we are actually access violating an address which was indeed a NULL pointer. The access violation was coming within mfc90u!AfxWinMain().

(ce8.1018): Access violation - code c0000005 (first chance)

First chance exceptions are reported before any exception handling.

This exception may be expected and handled.

eax=00000000 ebx=7ffdf000 ecx=77224e10 edx=00000000 esi=00000000 edi=00000000

eip=5749b48a esp=001cf824 ebp=001cf840 iopl=0         nv up ei pl zr na pe nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246

mfc90ud!AfxWinMain+0x7a:

5749b48a 8b10            mov     edx,dword ptr [eax]  ds:0023:00000000=????????

 

The obvious question was why AfxWinMain() would fail with an access violation? We analyzed the callstack to find the reason of the access violation (AV). Looking at the file source information we saw the application was failing in winmain.cpp @ line 37.

0:000> kbn100

*** WARNING: Unable to verify checksum for Test.exe

 # ChildEBP RetAddr  Args to Child             

00 001cf840 010e70ea 010d0000 00000000 001e20ec mfc90ud!AfxWinMain+0x7a [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\winmain.cpp @ 37]

01 001cf858 010e35fb 010d0000 00000000 001e20ec Test!wWinMain+0x1a [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\appmodul.cpp @ 30]

02 001cf908 010e335f 001cf91c 773a4911 7ffdf000 Test!__tmainCRTStartup+0x28b [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 574]

03 001cf910 773a4911 7ffdf000 001cf95c 7721e4b6 Test!wWinMainCRTStartup+0xf [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 399]

04 001cf91c 7721e4b6 7ffdf000 7748c3a5 00000000 kernel32!BaseThreadInitThunk+0xe

05 001cf95c 7721e489 010e178a 7ffdf000 00000000 ntdll!__RtlUserThreadStart+0x23

06 001cf974 00000000 010e178a 7ffdf000 00000000 ntdll!_RtlUserThreadStart+0x1b

 

Looking at the source code, “C:\Program Files\Microsoft Visual Studio 9.0\VC\atlmfc\src\mfc\winmain.cpp” we saw that the application was failing while accessing pThread. Since pThread was NULL we were getting AV. Now if you carefully see the source code, pThread is being returned from AfxGetThread().

 

int AFXAPI AfxWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,

      _In_ LPTSTR lpCmdLine, int nCmdShow)

{

      ASSERT(hPrevInstance == NULL);

 

      int nReturnCode = -1;

      CWinThread* pThread = AfxGetThread();

      CWinApp* pApp = AfxGetApp();

 

      // Snip

 

// AV on below line

      if (!pThread->InitInstance())

      {

            // Snip

}

 

// Snip

}

 

Above findings were confirmed by displaying the value of pThread using display type command (dt) in WinDbg. CWinThread pointer was in fact NULL.

 

0:000> dt pThread

Local var @ 0x1cf838 Type CWinThread*

(null)

 

The question was why AfxGetThread() returns NULL? Especially when it’s called from mfc90u!AfxWinMain() where we do not have direct control, unless we override AfxWinMain(). Looking at the source code of AfxGetThread(), it was clear that pThread was coming from the module thread state, AFX_MODULE_THREAD_STATE. For the ones who are wondering what is it? Have a look at afxstat_.h. below lines show where exactly pThread pointer is assigned.

 

“C:\Program Files\Microsoft Visual Studio 9.0\VC\atlmfc\src\mfc\thrdcore.cpp” @ line 138

 

CWinThread* AFXAPI AfxGetThread()

{

      // check for current thread in module thread state

      AFX_MODULE_THREAD_STATE* pState = AfxGetModuleThreadState();

      CWinThread* pThread = pState->m_pCurrentWinThread;

      return pThread;

}

 

Now when and where the CWinThread pointer is getting assigned for the module thread state? A further search in the MFC source reveals that the CWinThread pointer is getting assigned from CWinApp constructor. See below line.

 

“C:\Program Files\Microsoft Visual Studio 9.0\VC\atlmfc\src\mfc\appcore.cpp” @ 381

CWinApp::CWinApp(LPCTSTR lpszAppName)

{

      // Snip

 

// below code correctly sets CWinThread with this pointer

      pThreadState->m_pCurrentWinThread = this;

     

// Snip

}

 

Wow! Does that mean the constructor was never called?  Yes, the crux of the problem was that someone had accidently commented the global CWinApp constructor. As a result the constructor never got called. Compiler never complained about it being commented, and why should it? Since CWinApp was not correctly set, the application crashed by throwing an AV on pThread. So, as a rule of thumb you should always create the global CWinApp object to make sure it's constructor gets called and the AFX_MODULE_STATE structure is correctly setup. If you see your code works without the correct initialization, probably you are not using enough MFC in your code! This is the reason behind AfxGetThread() returning NULL in AfxWinMain().

 

- Gaurav Patole,

 

Technical Lead, Developer Support VC++/C# and Robotics

In native world, one interacts with OS directly by calling Win32 APIs for managing resources (like allocating/deallocating memory,opening/closing handles). In managed world one  relies on CLR totally or at times partially for doing the same( eg GC does memory management for us).Due to lack of understanding of the way CLR does the work for us,  we may at times conclude false theories. I was recently working on a test application, which seemed to leak threads when compiled  with /clr switch . Following are the functions that were used to create threads.

unsigned int __stdcall WorkerThread(void * ptr)

{

      THREADINFO *ti             =  (THREADINFO*)ptr;

      ::Sleep(100);

      delete ti;

      return 1;

}

 

void CTest::CreateWorkers(void *ptr)

{

      int counter=0;

      while (_run)

      {

            ::Sleep(100);

           

            THREADINFO *ti = new THREADINFO;

           

            DWORD   ui;

            HANDLE threadHandle = CreateThread(NULL,4096,(LPTHREAD_START_ROUTINE )WorkerThread,(unsigned(_stdcall *)(void *))ti, CREATE_SUSPENDED,&ui);

            ti->threadID = threadHandle;

     

            ResumeThread(threadHandle);

            WaitForSingleObject(threadHandle,INFINITE);

            int a = CloseHandle(threadHandle);

           

            counter++;

      }

}

Note that it is  C++ code which was being compiled with /clr for testing purpose as a step towards porting the application to .net. This is not a recommended way to create managed threads in an application. If we run this application after compiling it with /clr it seems to leak thread handles. If an application seems to leak resources, first thing to do is to confirm that resource indeed is being leaked and to find out what resource the application is leaking.

STEP 1. Use process explorer/performance monitor  to see what type of resource application is leaking. For memory one should look at virtual bytes and private bytes counter in process monitor , for managed memory one should look at Total # bytes in GC heap.  For handles process explorer gives a good idea as to which type of handles application is leaking.  It was found that it looked like application was leaking thread handles.

STEP 2. Once it is established that application is leaking handles and we know which type of handles application is leaking. Next step is to enable stack trace for opening and closing of handles. Htrace extension command comes in handy to enable stacktrace for opening and closing of handles.Stack traces are generated by ntdll , htrace just enables it. Launch the application under windbg  and use !htrace –enable to enable stack tracing for handles.

0:002> !htrace -enable

Handle tracing enabled.

Handle tracing information snapshot successfully taken.

STEP 3. After running the application for some time , when you are sure that enough of the handles have been leaked ,  run !htrace –diff , Output of this command , is stack trace of handles that have been opened but not yet closed. In this case it showed us stack trace of  thread creation. We are creating threads using Win32 API createthread and then running managed code on them.  In order to proceed further ,since we take help of runtime to manage system resources for us , it is a good idea to have an understanding of how runtime manages resources for us, in this case , resource is threads.

There are two types of threads that CLR needs to keep track of , one which start execution  from within managed code  by calling Thread.Start , other type are threads which were created in native world but which later execute managed code . CLR needs to maintain information about either of these threads in-order to performs operations like GC, CAS security checks , etc.  In order to see a list of threads which belong to either of these categories , and some of the information that CLR maintains about them,  run the following command after loading sos.dll.

0:004> !threads

ThreadCount: 183

UnstartedThread: 0

BackgroundThread: 182

PendingThread: 0

DeadThread: 0

Hosted Runtime: no

                                      PreEmptive   GC Alloc           Lock

       ID OSID ThreadOBJ    State     GC       Context       Domain   Count APT Exception

   0    1 1fc6c 0028b500      6020 Enabled  02c750e8:02c75fe8 00255be0     0 STA

   2    2 21640 00294730      b220 Enabled  00000000:00000000 00255be0     0 MTA (Finalizer)

   3    3 abcc 002d01a8       220 Enabled  00000000:00000000 00255be0     0 Ukn

XXXX    4 abb0 002d1888  80010220 Enabled  00000000:00000000 00255be0     0 Ukn

XXXX    5 b7ec 002d2070  80010220 Enabled  00000000:00000000 00255be0     0 Ukn

XXXX    6 2177c 002d2880  80010220 Enabled  00000000:00000000 00255be0     0 Ukn

XXXX    7 abc0 002d30b8  80010220 Enabled  00000000:00000000 00255be0     0 Ukn

XXXX    8 ab98 002d38f0  80010220 Enabled  00000000:00000000 00255be0     0 Ukn

XXXX    9 216e8 002d4128  80010220 Enabled  00000000:00000000 00255be0     0 Ukn

XXXX    a 1fb78 002d4960  80010220 Enabled  00000000:00000000 00255be0     0 Ukn

XXXX    b 216b8 002d5198  80010220 Enabled  00000000:00000000 00255be0     0 Ukn

XXXX    c 216f8 002d59d0  80010220 Enabled  00000000:00000000 00255be0     0 Ukn

XXXX    d 216c8 002d6208  80010220 Enabled  00000000:00000000 00255be0     0 Ukn

</snip>

You may want to run !help threads in order to see what exactly all these columns indicate. ThreadObj  is the address of the data-structure , in which CLR keeps the necessary information about these threads.  PreemptiveGC  indicates whether the thread can be preempted by the any other thread on which  has to perform a garbage collection .  As a developer it is not required to understand how CLR maintains this information and it is an implementation detail that can change over time but having a fair understanding of it helps in debugging.

XXX in first column indicates that the thread is a dead thread ,ie it has been detached from its corresponding os thread . There were a lot of such dead threads in output of !threads. Note that these dead threads are cleaned up at a later time by finalizer thread of the application.

In this particular case  , GC was not yet triggered and finalizer thread was not getting invoked and hence these dead thread objects were getting accumulated giving an impression that thread handles are being leaked . In order to prevent dead threads in this test scenario we periodically called Gc.Collect. It is important to realize that GC is generational and self tuning in nature  and hence it is not a good idea to call GC.Collect in code , however at times it may be justified to call GC.Colect , this blog talks about it in detail.

In order to prevent dead threads in this test scenario we periodically called GC.Collect.  However for creating worker threads in managed applications we have following better options :

1)ThreadPool.QueueUserWorkItem.

2)CCR’s dispatcher object.

-Manish Jawa

After migrating to Visual Studio 2008 SP1 and building the application, the manifest file of application and all the dependent DLL’s contain RTM version.

In Visual Studio 2008 SP1, by design, the manifest for the created exe links it to the RTM version of the CRT.

In Visual Studio 2005 SP1, by design, the manifest is linked to the current version of the CRT. This was a design change that happened in Visual Studio 2008; by default, it always links to the RTM version of the CRT (no matter if we are using SP1 to build it).

In order to link with SP1 version, rebuild the application with _BIND_TO_CURRENT_MFC_VERSION=1, _BIND_TO_CURRENT_CRT_VERSION=1, and/or _BIND_TO_CURRENT_ATL_VERSION=1 in stdafx.h.

http://blogs.msdn.com/vcblog/archive/2008/05/15/vc-runtime-binding.aspx

Recently, I came across the scenario where building an ATL project with _BIND_TO_CURRENT_MFC_VERSION=1, _BIND_TO_CURRENT_CRT_VERSION=1, _BIND_TO_CURRENT_ATL_VERSION=1 in stdafx.h, the manifest file contains dependency of both RTM and SP1 version of CRuntime library.

The manifest file will look like:

<dependency>

    <dependentAssembly>

      <assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.30729.1" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>

    </dependentAssembly>

  </dependency>

  <dependency>

    <dependentAssembly>

      <assemblyIdentity type="win32" name="Microsoft.VC90.MFC" version="9.0.30729.1" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>

    </dependentAssembly>

  </dependency>

  <dependency>

    <dependentAssembly>

      <assemblyIdentity type="win32" name="Microsoft.VC90.ATL" version="9.0.30729.1" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>

    </dependentAssembly>

  </dependency>

  <dependency>

    <dependentAssembly>

      <assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.21022.8" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>

 

    </dependentAssembly>

 

 

If you’re seeing multiple manifest entries, the easiest way I’ve found to diagnose this is to do something like this:

1.       Set LINK_REPRO=c:\repro  [or any other directory]

2.       Build your app. 

3.       All objs and libs that your application depends on are present in c:\repro.

4.       In c:\repro, do “link /dump /directives *.lib *.obj > direct.txt”

5.       Open up ‘direct.txt’ in your any text editor and search for the “bad” version number (9.0.21022.8).  That will tell you which object or library is responsible for the RTM dependency in your manifest.

This may be caused by one of the following:

1.       Inconsistent use of ‘BIND_TO_CURRENT_VERSION’ in your app. 

2.       An external static library that you are using which wants RTM, while the rest of your objects want SP1. 

In my scenario, it was the .obj file that corresponds to the _i.c file which is auto generated file after compiling an IDL file.  As IDL files are compiled before stdafx.h, and if IDL file is referring to certain header files which can introduce dependency to RTM version of CRT, finding such dependency is very difficult.  Also we cannot add _BIND_TO_CURRENT_MFC_VERSION=1, _BIND_TO_CURRENT_CRT_VERSION=1, _BIND_TO_CURRENT_ATL_VERSION=1 _i.c to the _i.h file, as they are auto-generated files. 

Work Around:

To work around this issue, we can use preprocessor definitions and add _BIND_TO_CURRENT_VCLIBS_VERSION

1.       Right Click _i.c file.

2.       Go to Configuration Property.

3.       Select C/C++ Preprocessor

4.       Add _BIND_TO_CURRENT_VCLIBS_VERSION to Preprocessor Definitions.

 

 

Jyoti Patel

Developer Support VC++ and C# 

 

This article focuses on troubleshooting a heap corruption caused by writing into the next allocated block. Heap corruption comes into notice when the overridden memory is accessed, leaving in a state where it becomes hard to figure out the original code that is overriding the memory.

 

In this scenario, call stack could look like

0:000> kp

ChildEBP RetAddr 

0:000> kb

ChildEBP RetAddr  Args to Child             

0012c2f4 7c91a3bc 01660000 01d0b000 0012c320 ntdll!RtlpFindAndCommitPages+0x116

0012c32c 7c911917 01660000 00000300 0012eb04 ntdll!RtlpExtendHeap+0xa6

0012c55c 00f4103e 01660000 00000000 000002f4 ntdll!RtlAllocateHeap+0x623

0012c578 00f4fd76 000002f4 5a7fcbb3 0012eb04 msvcr90d!_heap_alloc_base+0x5e

0012c5c0 00f4fb2f 000002d0 00000001 00000000 msvcr90d!_nh_malloc_dbg+0x2c6

0012c5e0 00f4fadc 000002d0 00000000 00000001 msvcr90d!_nh_malloc_dbg+0x7f

0012c608 00f5b25b 000002d0 00000000 00000001 msvcr90d!_nh_malloc_dbg+0x2c

0012c628 00f3d691 000002d0 cccccccc cccccccc msvcr90d!malloc+0x1b

0012c644 007ab543 000002d0 cccccccc 0012c690 msvcr90d!operator new+0x11

0012eb14 0073b367 MyApp!DummyFun

 

01660000 is the heap used by msvcr90d.dll in this case

 

0:000> !heap -av 01660000

Index   Address  Name      Debugging options enabled

 12:   01660000

    Segment at 01660000 to 01670000 (00010000 bytes committed)

    Segment at 01d00000 to 01e00000 (00011000 bytes committed)

    Flags:                00001002

    ForceFlags:           00000000

    Granularity:          8 bytes

    Segment Reserve:      00200000

    Segment Commit:       00002000

    DeCommit Block Thres: 00000200

    DeCommit Total Thres: 00002000

    Total Free Size:      00000089

                -

                -

                -

        0166e8e0: 00048 . 00300 [01] - busy (2f4)

        0166ebe0: 00300 . 00048 [01] - busy (3c)

        0166ec28: 00048 . 00048 [01] - busy (3c)

        0166ec70: 00048 . 00048 [01] - busy (3c)

        0166ecb8: 00048 . 00300 [01] - busy (2f4)

        0166efb8: 00300 . 00030 [01] - busy (25)

        0166efe8: 281a8 . 17188 [01] - busy (1717c)

   

##CORRUPTION FOUND at 0x0166EFE8

    PreviousSize field does not match Size field in previous entry

    Entry->PreviousSize == 0x2e31

    PreviousEntry->Size == 0x60

##The above errors were found in segment at 0x01660640

 

Looking at the 0166efe8 memory block, it is clear that the current size of previous block ‘00030’  is not matching with the previous size ‘281a8’. This infers that 0166efe8 is corrupted and previous size field is overridden by some data.  

 

_ CrtMemBlockHeader is the block header structure used to store the debug heap's bookkeeping information, for more information http://msdn.microsoft.com/en-us/library/bebs9zyz.aspx

 

0:000> dt msvcr90d!_CrtMemBlockHeader 0166efb8+8

   +0x000 pBlockHeaderNext : 0x0166ecc0 _CrtMemBlockHeader

   +0x004 pBlockHeaderPrev : 0x0166eff0 _CrtMemBlockHeader

   +0x008 szFileName       : (null)

   +0x00c nLine            : 0

   +0x010 nDataSize        : 1

   +0x014 nBlockUse        : 1

   +0x018 lRequest         : 3686

   +0x01c gap              : [4]  "???"

 

0:000> dt msvcr90d!_CrtMemBlockHeader 0166efe8+8

   +0x000 pBlockHeaderNext : 0x0166efc0 _CrtMemBlockHeader

   +0x004 pBlockHeaderPrev : 0x0166f028 _CrtMemBlockHeader

   +0x008 szFileName       : (null)

   +0x00c nLine            : 0

   +0x010 nDataSize        : 8

   +0x014 nBlockUse        : 1

   +0x018 lRequest         : 3687

   +0x01c gap              : [4]  "???"

 

The reason behind adding 8 bytes is that, each memory block in a given segment has 8 bytes metadata associated with it. The metadata is used by the heap manager to effectively manage the heap blocks within a segment.

 

lRequest is the allocation count. The above msvcr90d!_CrtMemBlockHeader structures show that they are adjacent allocations (3686 & 3687). If the corruption is in the same spot and allocation numbers are sequential, _CrtSetBreakAlloc(3686) can be used to determine the code that is overriding the memory 0166efe8 and how that block is being corrupted.

 

Call _CrtSetBreakAlloc(3686) at the code startup for ex: main(), start debugging(F5) the code and this should break the debugger when 0166efb8 memory block is allocated. Once the debugger breaks, code could be reviewed for two things

1) How many bytes are allocated

2) Are there any chances that suspected buffer could overflow.

 

For Example:

char *ptr = new char;

 

strcpy(ptr, source);   //where ‘source’ variable holds more than one character.

 

Please make a note that 3686 & 3687 may be different when its debugged second time, but it’s very rare case.