Forum

Hello-

I’m using prof-uis 2.53 pretty extensively in my multithreaded application. Every now and then I get crashing in some function called HookChains_t. This happens quite often if I’m showing a modal dialog and then either close it or click off of it, but not every time. Seems like some kind of race condition?

I get a callstack like this....

     ntdll.dll!7c901230()     
    msvcr71d.dll!_CrtDbgBreak() Line 93    C
    msvcr71d.dll!_CrtDbgReport(int nRptType=2, const char * szFile=0x7c144c68, int nLine=888, const char * szModule=0x00000000, const char * szFormat=0x00000000, ...) Line 427    C
    mfc71d.dll!AfxAssertFailedLine(const char * lpszFileName=0x7c144c68, int nLine=888) Line 28 + 0x14    C++
    mfc71d.dll!CWnd::AssertValid() Line 888 + 0x3f    C++
    mfc71d.dll!AfxAssertValidObject(const CObject * pOb=0x0381a404, const char * lpszFileName=0x10756098, int nLine=4511) Line 104    C++
    ProfUIS253md.dll!CExtPageContainerWnd::OnHookWndMsg(long & lResult=0, HWND__ * hWndHooked=0x007017aa, unsigned int nMessage=15, unsigned int & wParam=0, long & lParam=0) Line 4513    C++
    ProfUIS253md.dll!CExtHookSink::HookChains_t::HookChainsWindowProc(unsigned int nMessage=15, unsigned int & wParam=0, long & lParam=0) Line 181 + 0x24    C++
>    ProfUIS253md.dll!CExtHookSink::HookChains_t::g_HookWndProc(HWND__ * hWnd=0x007017aa, unsigned int nMessage=15, unsigned int wParam=0, long lParam=0) Line 247 + 0x14    C++
    user32.dll!77d48734()     
    user32.dll!77d48816()     
    user32.dll!77d4b4c0()     
    user32.dll!77d4b50c()     
    ntdll.dll!7c90eae3()     
    user32.dll!77d494d2()     
    user32.dll!77d4b530()     
    user32.dll!77d5e04a()     
    user32.dll!77d48a10()     
    user32.dll!77d5e2b9()     
    user32.dll!77d561c6()     
    user32.dll!77d6a92e()     
    mfc71d.dll!AtlTraceVA(unsigned long dwModule=1287424, const char * pszFileName=0x003a8444, int nLine=73746, unsigned long dwCategory=3835096, unsigned int nLevel=3835096, const char * pszFormat=0x003a84c8, char * ptr=0x7c144c68) Line 315 + 0x19    C++
    msvcr71d.dll!CrtMessageWindow(int nRptType=2, const char * szFile=0x7c144c68, const char * szLine=0x0013b544, const char * szModule=0x00000000, const char * szUserMessage=0x0013b564) Line 617 + 0x16    C
    msvcr71d.dll!_CrtDbgReport(int nRptType=2, const char * szFile=0x7c144c68, int nLine=888, const char * szModule=0x00000000, const char * szFormat=0x00000000, ...) Line 516 + 0x4c    C
    mfc71d.dll!AfxAssertFailedLine(const char * lpszFileName=0x7c144c68, int nLine=888) Line 28 + 0x14    C++
    mfc71d.dll!CWnd::AssertValid() Line 888 + 0x3f    C++
    mfc71d.dll!AfxAssertValidObject(const CObject * pOb=0x0381a404, const char * lpszFileName=0x10756098, int nLine=4511) Line 104    C++
    ProfUIS253md.dll!CExtPageContainerWnd::OnHookWndMsg(long & lResult=0, HWND__ * hWndHooked=0x007017aa, unsigned int nMessage=15, unsigned int & wParam=0, long & lParam=0) Line 4513    C++
    ProfUIS253md.dll!CExtHookSink::HookChains_t::HookChainsWindowProc(unsigned int nMessage=15, unsigned int & wParam=0, long & lParam=0) Line 181 + 0x24    C++
    ProfUIS253md.dll!CExtHookSink::HookChains_t::g_HookWndProc(HWND__ * hWnd=0x007017aa, unsigned int nMessage=15, unsigned int wParam=0, long lParam=0) Line 247 + 0x14    C++
    user32.dll!77d48734()     
    user32.dll!77d48816()     
    user32.dll!77d4b4c0()     
    mfc71d.dll!CThreadLocalObject::GetData(CNoTrackObject * (void)* pfnCreateObject=0x03051750) Line 414 + 0x11    C++
    user32.dll!77d4b50c()     
    ntdll.dll!7c90eae3()     
    user32.dll!77d494d2()     
    user32.dll!77d4b530()     
    mfc71d.dll!CWnd::WalkPreTranslateTree(HWND__ * hWndStop=0x00163ed0, tagMSG * pMsg=0x00000001) Line 3123 + 0x14    C++
    user32.dll!77d496c7()     
    mfc71d.dll!AfxInternalPumpMessage() Line 188    C++
    mfc71d.dll!AfxPumpMessage() Line 198    C++
    mfc71d.dll!CWnd::RunModalLoop(unsigned long dwFlags=4) Line 4566 + 0x5    C++
    mfc71d.dll!CPropertySheet::DoModal() Line 934 + 0xc    C++


How can I avoid this?

Thanks.

We are stick to the UI design used in all today’s Microsoft applications: the UI is implemented in one thread and all the other logic can be implemented in the same thread or in other threads. So first of all please check this. Of course, it would be helpful if you would reproduce the crash using any of our samples or your test project. The first assertion from the bottom looks like as a result of subclassing a window multiply times but un-subclassing during window destruction was performed in an invalid order. What this means is that some window was subclassed several times using a classic technique of changing the window procedure. Please note that un-subclassing and restoring the window procedure should be performed in the reverse order. If the un-subclassing is performed incorrectly, the restored window procedures may access invalid or de-allocated data.