Wednesday, April 30, 2008 7:21 AM
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?
Monday, May 05, 2008 9:41 PMModerator
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
Visual Studio takes 20-30 seconds to complete the operation.
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'?
Tuesday, May 06, 2008 9:18 AMHi 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:
I have the same problem, if I debug the release code (mfc90u.dll) of the MFC test project.
Wednesday, May 07, 2008 6:37 AMHi,
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:
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?
Friday, May 09, 2008 9:40 PMModerator
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.
Tuesday, May 13, 2008 7:37 AMThanks Gregg,
I have reported this bug:
Friday, May 16, 2008 9:34 PMModerator
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.
2. Close the autos window (not that it needs to actually be closed, not just hidden).