AFX_ISOLATIONAWARE_FUNC crash
-
I have a legacy MFC app that has recently been ported to VS 2005. Debug mode works fine, but release mode crashes on startup. I traced the code to a CImageList::Load method - which, in VS2005, now calls the following code:
AFX_ISOLATIONAWARE_FUNC(HIMAGELIST, ImageList_LoadImageW, (HINSTANCE hi,LPCWSTR lpbmp,int cx,int cGrow,COLORREF crMask,UINT uType,UINT uFlags), (hi,lpbmp,cx,cGrow,crMask,uType,uFlags),NULL)
This code is crashing (somewhere in the AFX_ISOLATIONAWARE_FUNC macro) and I have no ideas why. At first I thought the resource handle may be wrong, but if I call ImageList_LoadImageW directly, it works fine and returns a valid handle. Anyone have any clues at all? There is no mention of this new macro anywhere I can find.
The Rob Blog
Google Talk: robert.caldecott -
I have a legacy MFC app that has recently been ported to VS 2005. Debug mode works fine, but release mode crashes on startup. I traced the code to a CImageList::Load method - which, in VS2005, now calls the following code:
AFX_ISOLATIONAWARE_FUNC(HIMAGELIST, ImageList_LoadImageW, (HINSTANCE hi,LPCWSTR lpbmp,int cx,int cGrow,COLORREF crMask,UINT uType,UINT uFlags), (hi,lpbmp,cx,cGrow,crMask,uType,uFlags),NULL)
This code is crashing (somewhere in the AFX_ISOLATIONAWARE_FUNC macro) and I have no ideas why. At first I thought the resource handle may be wrong, but if I call ImageList_LoadImageW directly, it works fine and returns a valid handle. Anyone have any clues at all? There is no mention of this new macro anywhere I can find.
The Rob Blog
Google Talk: robert.caldecott -
I have a legacy MFC app that has recently been ported to VS 2005. Debug mode works fine, but release mode crashes on startup. I traced the code to a CImageList::Load method - which, in VS2005, now calls the following code:
AFX_ISOLATIONAWARE_FUNC(HIMAGELIST, ImageList_LoadImageW, (HINSTANCE hi,LPCWSTR lpbmp,int cx,int cGrow,COLORREF crMask,UINT uType,UINT uFlags), (hi,lpbmp,cx,cGrow,crMask,uType,uFlags),NULL)
This code is crashing (somewhere in the AFX_ISOLATIONAWARE_FUNC macro) and I have no ideas why. At first I thought the resource handle may be wrong, but if I call ImageList_LoadImageW directly, it works fine and returns a valid handle. Anyone have any clues at all? There is no mention of this new macro anywhere I can find.
The Rob Blog
Google Talk: robert.caldecottAfter much tweaking, I managed to fix the problem. The app in question was set to use 1-byte struct member alignment, which, for reasons only know to MS, caused these new macros to barf. I changed the setting to "Default" and used appropriate pragmas around the structs that needed 1-byte alignment, and the problem was cured!
The Rob Blog
Google Talk: robert.caldecott -
I have a legacy MFC app that has recently been ported to VS 2005. Debug mode works fine, but release mode crashes on startup. I traced the code to a CImageList::Load method - which, in VS2005, now calls the following code:
AFX_ISOLATIONAWARE_FUNC(HIMAGELIST, ImageList_LoadImageW, (HINSTANCE hi,LPCWSTR lpbmp,int cx,int cGrow,COLORREF crMask,UINT uType,UINT uFlags), (hi,lpbmp,cx,cGrow,crMask,uType,uFlags),NULL)
This code is crashing (somewhere in the AFX_ISOLATIONAWARE_FUNC macro) and I have no ideas why. At first I thought the resource handle may be wrong, but if I call ImageList_LoadImageW directly, it works fine and returns a valid handle. Anyone have any clues at all? There is no mention of this new macro anywhere I can find.
The Rob Blog
Google Talk: robert.caldecottput here because I found this thread when I had a similar problem ... We had a crash in one of the comdlg32 methods wrapped in a AFX_ISOLATIONAWARE_FUNC macro, the problem was eventually traced to some shonky code in MFC, namely
CDllIsolationWrapperBase::GetModuleHandle()This method uses::GetModuleHandleto get to (in our case) comdlg32 IIF that module is already loaded - the primary distinction between::GetModuleHandleandLoadLibraryis the upping of the refcount, done in the latter, not the former Our scenario was (simplistically) as follows ... 1. our code loads a 1st party lib, this dll explicitly loads comdlg32 2. our code uses comdlg32 methods - first time through, MFC needs a handle, uses GetModuleHandle as described above 3. our code frees 1st party lib, in its shutdown, comdlg's refcount drops to 0, hence unloads comdlg 4. our code uses comdlg32 methods again - MFC has a handle, it has a procAddress, it calls it ... boom! Obviously, this bug will exhibit similarly with all the libraries that use the MFC wrapper class