none
Migrating MFC project from VC++ 6.0 to VC++ 9.0 (VS 2008) Compiles properly but gives exception randomly RRS feed

  • Question

  • Hello Programmers,
    I'm trying to Migrate MFC project from VC++ 6.0 to VC++ 9.0 (VS 2008). The code Compiles properly but gives exception randomly. I've noticed that the problem comes in the CTreeCtrl. Clicking on any of the items in CTreeCtrl crashes the application randomly. It takes me to some windows files wincore.cpp in the following function:
    LRESULT CWnd::DefWindowProc(UINT nMsg, WPARAM wParam, LPARAM lParam)
    {
    if (m_pfnSuper != NULL)
    return ::CallWindowProc(m_pfnSuper, m_hWnd, nMsg, wParam, lParam);
    ...
    }
    The exception comes in different files, but all are window's files.
    Please let me know if anybody has faced any issues with CTreeCtrl in VC++9.0.
    Looking forward for some quick response from the experts.
    Thanks in Advance.
    Monday, May 25, 2009 6:26 AM

All replies

  • What does the error message in the exception say ?
    «_Superman_»
    Monday, May 25, 2009 6:46 AM
  • The complete call stack looks like this:
    I hope it helps...
      ntdll.dll!7c90120e()  
      [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] 
      ntdll.dll!7c967212()  
      ntdll.dll!7c967921()  
      msctf.dll!7472ed96()  
      msctf.dll!74730e52()  
      msvcrt.dll!77c35cf5()  
      ntdll.dll!7c9032a8()  
      ntdll.dll!7c90327a()  
      ntdll.dll!7c92a526()  
      user32.dll!7e46c6f6()  
      user32.dll!7e418734()  
      user32.dll!7e418816()  
      user32.dll!7e46c6f6()  
      user32.dll!7e46c6f6()  
      user32.dll!7e41d545()  
      user32.dll!7e41d4ee()  
      user32.dll!7e418734()  
      user32.dll!7e41d4ee()  
      user32.dll!7e41d4ee()  
      user32.dll!7e41f65d()  
      user32.dll!7e41d4ee()  
    > mfc90d.dll!CWnd::DefWindowProcA(unsigned int nMsg=6, unsigned int wParam=1, long lParam=0)  Line 1043 + 0x20 bytes C++
      mfc90d.dll!CWnd::Default()  Line 274 C++
      mfc90d.dll!CWnd::OnMDIActivate(int __formal=1, int __formal=1, int __formal=1)  Line 368 + 0x11 bytes C++
      mfc90d.dll!CFrameWnd::OnActivate(unsigned int nState=1, CWnd * pWndOther=0x00000000, int bMinimized=0)  Line 1018 C++
      mfc90d.dll!CWnd::OnWndMsg(unsigned int message=6, unsigned int wParam=1, long lParam=0, long * pResult=0x0012fc30)  Line 2119 C++
      mfc90d.dll!CWnd::WindowProc(unsigned int message=6, unsigned int wParam=1, long lParam=0)  Line 1755 + 0x20 bytes C++
      mfc90d.dll!AfxCallWndProc(CWnd * pWnd=0x00339750, HWND__ * hWnd=0x00050cd6, unsigned int nMsg=6, unsigned int wParam=1, long lParam=0)  Line 240 + 0x1c bytes C++
      mfc90d.dll!AfxWndProc(HWND__ * hWnd=0x00050cd6, unsigned int nMsg=6, unsigned int wParam=1, long lParam=0)  Line 403 C++
      mfc90d.dll!AfxWndProcBase(HWND__ * hWnd=0x00050cd6, unsigned int nMsg=6, unsigned int wParam=1, long lParam=0)  Line 441 + 0x15 bytes C++
      user32.dll!7e418734()  
      user32.dll!7e418816()  
      user32.dll!7e41b4c0()  
      user32.dll!7e42e042()  
      mfc90d.dll!AfxInternalPumpMessage()  Line 153 + 0x13 bytes C++
      mfc90d.dll!CWinThread::PumpMessage()  Line 900 C++
      mfc90d.dll!CWinThread::Run()  Line 629 + 0xd bytes C++
      mfc90d.dll!CWinApp::Run()  Line 865 C++
      mfc90d.dll!AfxWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, char * lpCmdLine=0x00151f25, int nCmdShow=1)  Line 47 + 0xd bytes C++
      Admin.exe!WinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, char * lpCmdLine=0x00151f25, int nCmdShow=1)  Line 30 C++
      Admin.exe!__tmainCRTStartup()  Line 574 + 0x35 bytes C
      Admin.exe!WinMainCRTStartup()  Line 399 C
      kernel32.dll!7c816fe7()  

    Thanks
    Monday, May 25, 2009 7:21 AM
  • You still didn't mention the exception.  There's nothing obviously wrong with your code, the call stack looks entirely normal for the frames that belong to your code, well MFC's.  It is dying on a WM_ACTIVATE message.  This looks like system instability, most probably associated with msctf.dll.  I think it's an Office or Language Bar helper.  It would indeed be very interested in a window activation change.

    You should setup the debugging symbol server so you'll have some kind of idea what code is being executed by msctf.  If you see anything resembling a heap all, the problem points back at your program, corrupting the heap.
    Hans Passant.
    Monday, May 25, 2009 5:03 PM
    Moderator
  • Hi Hans,

    Thanks for your response. The exception that I get randomly while clicking on TreeCtrl is "Windows has triggered a breakpoint in Admin.exe.

    This may be due to a corruption of the heap, which indicates a bug in Admin.exe or any of the DLLs it has loaded.

    This may also be due to the user pressing F12 while Admin.exe has focus.

    The output window may have more diagnostic information."

    Another exception in DlgCore.cpp is "Unhandled exception at 0x7e423c2b in Admin.exe: 0xC0000005: Access violation reading location 0xbb16f07d."

    The code has been working absolutely fine with VC6 for a long time. But these issues have just started while migrating to VC9. I hope you can help.

    Thanks again.

    Tuesday, May 26, 2009 6:54 AM
  • Hmya, heap corruption.  Good luck finding it.
    Hans Passant.
    Tuesday, May 26, 2009 7:25 AM
    Moderator
  • If you have tooltips enabled for your controls, comment out the code that fills in the tooltip text (the _GETINFOTIP message etc)

    Since I found this to be a common cause of corruption in apps I've had to fix. Typically the issue is the tooltip text is either to long for the buffer but copies across anyhow, or isn't persistent long enough.

    Just a thought anyhow :)

    Thanks
    Tuesday, May 26, 2009 9:54 AM
  • Hi Mark,
    Thanks for the response. Unfortunately I do not find any tooltips enabled for the controls. Its still the same issue I'm facing from the last so many days and unable to move forward. Do you have any other thought ?
    Thanks
    Tuesday, May 26, 2009 1:14 PM
  • Hi,

    As the exception talks about Heap Corruption..can anyone guide me as to what should be the approach to know if the issue is Heap corruption and how to fix it?

    Thanks,
    Abhi
    Wednesday, May 27, 2009 4:27 AM
  • In your debug build, temporarily add calls to _CrtCheckMemory() after various operations. 

    In an MFC doc/view application OnIdle is an interesting place to add one of these calls.  Then it will keep checking the heap as you exercise the GUI.

     

    Wednesday, May 27, 2009 4:43 AM
  • The code has been working absolutely fine with VC6 for a long time. But these issues have just started while migrating to VC9. I hope you can help.

    Don't expect code that works in VC6 to work in VC9, two different compilers. Expect lots of work to do, it's not an easy one, I just converted one :).

    Some points to keep in mind...

    1. If your DLL or third party DLL API's use STL in their interface, please recompile or request a recompiled one for this compiler. Or write a wrapper in VC6 with no dependency of STL or MFC in it's interface and then use it instead of the other dlls (well mine was a small one so quite easy, not sure about your case).
    2. Careful with sscanf and fscanf (this one is notorious for stack corruption)
    3. Read this too
    4. Also note that wchar_t is treated an in built type, so will result in linker errors, better change this if you still work with older third party dlls. Goto Project Properties->Configuration Properties->C/C++->Language->Treat wchar_t as Build in type.
    5. There will for scoping errors (point 3). Goto Project Properties->Configuration Properties->C/C++->Language->Force Conformance in For scope.
    Also what will be interesting is the code written in the click handler for this tree control, step through and you'll find something. Good luck.

    Microsoft MVP - Visual C++
    Blog: http://nibuthomas.com
    Wednesday, May 27, 2009 5:05 AM
    Moderator
  • Hi Nibu,

    Thanks a lot for your response. I looked at your sugegstions. Here is the status for the points you mentioned.
    1. If your DLL or third party DLL API's use STL in their interface, please recompile or request a recompiled one for this compiler. Or write a wrapper in VC6 with no dependency of STL or MFC in it's interface and then use it instead of the other dlls (well mine was a small one so quite easy, not sure about your case).
    Resp: My DLL's use STL and MFC in the interfaces, but as it is implemented at a lot of places, so it wont be possible to build the code without them.

    2. Careful with sscanf and fscanf (this one is notorious for stack corruption)

    Resp: No Issues with format specifier with these function and its used at just 1 location.

    3. Read this too - Already gone through this article. Its a good one.

    4. Also note that wchar_t is treated an in built type, so will result in linker errors, better change this if you still work with older third party dlls. Goto Project Properties->Configuration Properties->C/C++->Language->Treat wchar_t as Build in type.

    Resp: I tried implementing these changes but got the same issue again.

    5. There will for scoping errors (point 3). Goto Project Properties->Configuration Properties->C/C++->Language->Force Conformance in For scope.

    Resp: I tried implementing these changes but got the same issue again.

    I really aprreciate and looking forward for some more input from your side.

    In case if anyone has any suggestions on this issue, it will be a great help to me.

    Thanks,

    Abhi

    Thursday, May 28, 2009 7:58 AM