none
VS 2008 C++ Debugger hangs while debugging inline Code

    Question

  •  

    Hello,

     

    when I am debugging any inline Code in a large native C++/MFC application in Visual Studio 2008,

    Visual Studio hangs with 50% CPU load (AMD Dual Core) of devenv.exe.

    After about 20 - 30 seconds the CPU load falls to 0% and stepping to the next line is possible and so on...

    I can also reproduce this error, in an empty native MFC application (Installed Feature Pack), which I had created with VS 2008, if I step for example in the inline code of the default constructor of a local CString variable: CString cstrTest;

    My Tools->Options->Debugging->Symbols are empty.

    I have also reseted all options without success.  

     

    Debugging isn't possible with this bug!

     

    Can anybody help me?

     

    Thanks,

    Martin

    Wednesday, April 30, 2008 7:21 AM

Answers

  • Hi,

    I have found the "component" which causes the problem!

    The Debug "Autos" window (Debug->Windows->Autos) causes the high CPU load!
    If I close the "Autos" window, stepping seems to be quick.

    I have found another bug with inline Code:
    There are no "valid" debug information of member variables in inline Code available!
    I can't see "valid" member variables e.g. in the "Watch" window.
    e.g. step into constructor of CString and look at the end of the constructor.
    The string isn't assigned to the member variable. The member variable shows an empty string:

    CString cstrTest(_T("Test");

    VS2005's debugger worked with inline Code!

    Should I report this bugs or is there anybody else who can do this job for me?
    Where can I report the bugs?

    Thanks!
    Martin

    Wednesday, May 07, 2008 6:37 AM
  • Thanks Martin.

     

    Visual Studio bugs can be reported through http://connect.microsoft.com/VisualStudio. Its generally best if customers report the bugs themselves -- provides a way for you to track the issue, issue will get more attention, and makes it easy for us to come back and ask you questions if necessary.

     

    It sounds like there is some sort of bad interaction between the VC feature pack and the debugger's expression evaluator. Hopefully we will be able to track down the issue. If things get too bad you may actually find it helpful to rename the MFC PDBs so that the debugger ignores them.

     

    Friday, May 09, 2008 9:40 PM
  • To follow up on this a bit. This problem is not caused by the fact that you are stepping into a header file. This problem is caused by the fact that you are stepping into mfc90ud.dll, and the fact that the PDB for mfc90ud.dll is ~26MB, so when the debugger searches the PDB for the line information that the autos window needs, it can take a long time. As a comparison, in VS 2008 RTM this file was 11MB.

     

    Moving forward, we will see what we can do to make this faster.

     

    In the mean time, here are the two ways that you can work around the problem:

    1. Delete or rename %windir%\symbols\dll\mfc90d.i386.pdb.

    -or-

    2. Close the autos window (not that it needs to actually be closed, not just hidden).

     

    Thanks,

    Gregg Miskelly

    Friday, May 16, 2008 9:34 PM

All replies

  • Hi Martin,

     

    Let me see if I am understanding you. I this displaying the problem for you:

    1. Create a new MFC app

    2. Add a local CString variable

    3. Hit breakpoint on line of declration

    4. Step into constructor of CString variable

     

    Result:

    Visual Studio takes 20-30 seconds to complete the operation.

     

    Questions:

    1. Is this correct? If not, could you clarify what I am getting wrong?

    2. Do you have any addins installed? If so, does it help to remove/disable them?

    3. Do you see a similiar problem if you just open up cstringt.h (C:\Program Files\Microsoft Visual Studio 9.0\VC\atlmfc\include\cstringt.h) or do you actually need to be debugging?

    4. Could you explain what you mean by 'Installed Feature Pack'?

     

    Thanks!

    Gregg

     

     

    Monday, May 05, 2008 9:41 PM
  • Hi Gregg,

    thanks for your efforts.

    Here are the answers of your questions:

    1. I think you got me right. Here are the details of my problem:
    - "Step Into" (F11) constructor of CString variable - I have to wait ~20 sec until operation is completed
    - "Step Over" (F10) to the next line (end of the default constructor) of CString - I have to wait once more ~20 sec until operation is completed
    - "Step Out" to the calling method - Operation seems to be quick

    2. I use the "Visual Assist X" addin. I have disabled them in the Add-in Manager, restarted Visual Studio and tried
    to debug again without success.

    3. If I had opened cstring.h (C:\Program Files\Microsoft Visual Studio 9.0\VC\atlmfc\include\cstringt.h) before,
    I have the same debugging problem.

    4. I have installed the VC2008 C++ Feature Pack MFC Version 9.0.30411.0 on my Windows XP SP2 32-Bit system

    In the Debug->Windows->Modules, there are the following information:

    Name                Version               Symbol File
    ----------------------------------------------------------------------------
    mfc90ud.dll        9.00.30411.00      C:\Windows\symbols\dll\mfc90ud.i386.pdb
    msvcr90d.dll      9.00.30411.00       C:\Windows\symbols\dll\msvcr90d.i386.pdb

    In the C:\Windows\symbols\dll folder, I can see the following file dates:

    Filename                       Date
    ----------------------------------------------------------------
    mfc90ud.i386.pdb           04/11/2008
    msvcr90d.i386.pdb          04/10/2008

    mfc90ud.amd64.pdb        11/06/2007
    msvcr90d.amd64.pdb       11/06/2007

    I have the same problem, if I debug the release code (mfc90u.dll) of the MFC test project.

    Any ideas?

    Thanks!
    Martin


    Tuesday, May 06, 2008 9:18 AM
  • Hi,

    I have found the "component" which causes the problem!

    The Debug "Autos" window (Debug->Windows->Autos) causes the high CPU load!
    If I close the "Autos" window, stepping seems to be quick.

    I have found another bug with inline Code:
    There are no "valid" debug information of member variables in inline Code available!
    I can't see "valid" member variables e.g. in the "Watch" window.
    e.g. step into constructor of CString and look at the end of the constructor.
    The string isn't assigned to the member variable. The member variable shows an empty string:

    CString cstrTest(_T("Test");

    VS2005's debugger worked with inline Code!

    Should I report this bugs or is there anybody else who can do this job for me?
    Where can I report the bugs?

    Thanks!
    Martin

    Wednesday, May 07, 2008 6:37 AM
  • Thanks Martin.

     

    Visual Studio bugs can be reported through http://connect.microsoft.com/VisualStudio. Its generally best if customers report the bugs themselves -- provides a way for you to track the issue, issue will get more attention, and makes it easy for us to come back and ask you questions if necessary.

     

    It sounds like there is some sort of bad interaction between the VC feature pack and the debugger's expression evaluator. Hopefully we will be able to track down the issue. If things get too bad you may actually find it helpful to rename the MFC PDBs so that the debugger ignores them.

     

    Friday, May 09, 2008 9:40 PM
  • Thanks Gregg,

    I have reported this bug:

    http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=343714
    Tuesday, May 13, 2008 7:37 AM
  • To follow up on this a bit. This problem is not caused by the fact that you are stepping into a header file. This problem is caused by the fact that you are stepping into mfc90ud.dll, and the fact that the PDB for mfc90ud.dll is ~26MB, so when the debugger searches the PDB for the line information that the autos window needs, it can take a long time. As a comparison, in VS 2008 RTM this file was 11MB.

     

    Moving forward, we will see what we can do to make this faster.

     

    In the mean time, here are the two ways that you can work around the problem:

    1. Delete or rename %windir%\symbols\dll\mfc90d.i386.pdb.

    -or-

    2. Close the autos window (not that it needs to actually be closed, not just hidden).

     

    Thanks,

    Gregg Miskelly

    Friday, May 16, 2008 9:34 PM