Home » Visual StudioRSS

VS2008 slow debugging

Hi folks,

I am working on a small project in VS2008(4 projects 3 class libraries and one console app).

When i try to debug the program it's extremly slow.

Stepping through the code takes about 1-2 seconds for each step. Weird thing is though that i can see in my file-tabs that the ide locks the files during that second.

What he is doing during that time, i don't know, but i m sure it has something to do with my slow debugging.

Any suggestions?

 

20 Answers Found

 

Answer 1

Hi,

Do you have lot of breakpoints set in your project. That could slow  things down. Also, check the status bar for Visual studio to see if anything is happening during the step operation. It could be that visual studio is downloading symbols, thereby slowing it down. Also, try disabling hosting process through Project->Properties->Debugging->Enable hosting process.

Thanks,

Parool

 

Answer 2

I've a similar issue. A small  solution of 3 class  libraries and 1 web project.

After some tuning I've been able to reach an usable editor speed but when I start debug  I've to wait also for minutes, in output window I see assemblies loading


Auto-attach to process '[2004] aspnet_wp.exe' on machine 'TestMachine' succeeded.
'aspnet_wp.exe' (Managed): Loaded 'C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
'aspnet_wp.exe' (Managed): Loaded 'C:\WINDOWS\assembly\GAC_32\System.Web\2.0.0.0__b03f5f7f11d50a3a\System.Web.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
'aspnet_wp.exe' (Managed): Loaded 'C:\WINDOWS\assembly\GAC_MSIL\System\2.0.0.0__b77a5c561934e089\System.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
....

'aspnet_wp.exe' (Managed): Loaded 'C:\WINDOWS\assembly\GAC_MSIL\System.Design\2.0.0.0__b03f5f7f11d50a3a\System.Design.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
'aspnet_wp.exe' (Managed): Loaded 'A_b8f539d9_ec96_4468_ab1c_fd46b8678897'
'aspnet_wp.exe' (Managed): Loaded 'M_b8f539d9_ec96_4468_ab1c_fd46b8678897'
'aspnet_wp.exe' (Managed): Loaded 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\hypersic\877e83e7\fa8c362c\App_Web_l9zaulrg.dll', Symbols loaded.
'aspnet_wp.exe' (Managed): Loaded 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\hypersic\877e83e7\fa8c362c\App_Web_p9lfmmfv.dll', Symbols loaded.
'aspnet_wp.exe' (Managed): Loaded 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\hypersic\877e83e7\fa8c362c\App_Web_uvzne92q.dll', Symbols loaded.


but after a while I obtain and error stating that is "Unable to start debugging. The web server did not respond in a timely manner.This may be because another debugger is already attached to the web server".

In the output window I see


A first chance exception of type 'System.Threading.ThreadAbortException' occurred in mscorlib.dll
An exception of type 'System.Threading.ThreadAbortException' occurred in mscorlib.dll but was not handled in user code

Some hint?

 

Answer 3

Please also provide some information regarding what type of project  you're debugging.  C#? VB? C++?

Another option to turn off temporarily (if the project is C# or VB) is "Enable property evaluation and other implicit function calls" in Tools->Options->Debugging.

 

Answer 4

I'm experiencing the same problem (with a VB.Net Winforms application) -- I've tried both the suggestions  given above of disabling th ehost process & implicit calls, but step over is still very slow, and appears to be proportional to the number of source files  open in the IDE.

I find it strange that the SourceSafe padlock appears/disappears (for projects  not in source control) and disappears/appaers (for projects in SourceSafe) for every open file for each time  the debugger resumes/stops (andmaybe it's this that is having a major impact on performance)

(I should point out that I've eliminated the common causes in the FAQ at http://blogs.msdn.com/jimgries/pages/visual-studio-debugger-faq.aspx)
 

Answer 5

I'm debugging  a C# application.
In these days I made many tests, I was able to reproduce some scenarios.
- opening an ascx it takes  a couple of minutes, the strange thing  is that devenv seems to do nothing looking at task manager. CPU is near 0% for devenv process...it seems to wait for something.
- Pressing F5 it compiles the 4 projects quickly then devenv seems to do nothing for a couple of minutes (as above) and then a message pops up with the error I described above.
-  if after the above message I repress F5, devenv connects quickly to the web server, IE opens but it takes many times to show the page.

 

Answer 6

Rowland,

If you move your project  outside of source safe, does this still occur?
 

Answer 7

SbGibson,

Disable Just-My-Code and enable break when thrown for ThreadAbortException. Then, when you run this scenario, the debugger will break at that exception. Since you probably won't have symbols this will drop you into dissassembly. However, the callstack will be valuable. Can you please post that after doing this?

Thanks

Jackson Davis - MSFT
 

Answer 8

I've also had this problem with VS2008 professional and a native C++ application (4 static lib projects, one win32 project, an AQTime profiling project  and a setup project).  Theres some fairly extensive c++ template code  in there.

I just discovered that closing the 'autos' debug  window gets rid of the issue.  The 'locals' debug window appears to be fine. 

 

Answer 9

I also experienced the problem with Vista & Visual Studio 2008. Read some other thread in this forum and discovered that if I close Google toolbar then all is fine!
 

Answer 10

Had some major VS2008 performance issues on Vista here too.

Turning off the Windows Desktop Management made a huge difference in performance. (Shortcut -> Properties -> Compatibility)

Sure you miss out on the fancy Aero stuff, but thats a trade-off I guess.

Start time  of VS2008 decreased from about 90secs to around 5secs. Building goes twice as fast, and debugging: "delay? what delay!?"


Joep
 

Answer 11

I had the same slow  debugging experience - Vista SP1 with VS 2008 SP1. It was taking about 1 or 2 seconds for EACH step through when debugging.

I had a Watch window open and about 5 items that were unrelated to the project  in question.

Closed the Watch window, and the slow debugging  disappeared.
 

Answer 12

Yes!  We have Visual Studio 2008 SP1.  Starting and exiting debugging  of a C# ASP.Net application was taking minutes.  I deleted all breakpoints, after which the browser and application load in 5 seconds or less.  Apparently we had quite a number of breakpoints, most disabled.  This solved the problem!
 

Answer 13

I was also experiencing very slow  debugging of a C# project, up to 30 seconds per step-over call.

I am using VS2008 Development Edition SP1.

My solution has:
14 C# projects
1 C++/CLI project
2 Setup projects

All the projects  except the setup projects are configured to build in the debug  build in the Configuration Manager.

None of the above solutions worked for me...

I managed to solve the issue by unloading both setup projects before starting the debugging  session, back to lightning fast!
If I reload the setup projects, debugging goes back to super slow.

I don't want to guess why this solution works for me, it should be completely unrelated, but it may help someone else...
 

Answer 14

I also have similar problem with VS 2008 (and SP1 as well). debugging  unmanaged C++ heavily-templated code  is very very slow. Stepping either in source window or in disassembler takes  several seconds. Closing Auto, Locals and Watch does not help (but it lowers the delay to some point). Only a single breakpoint (or no breakpoints at all) is defined.

Another problem with heavily templated code is that it looks like a Disassembler window has an internal limit on maximum identifier length, so when a "call" instruction is displayed that refers to a particular long identifier name, no identifier name, and even no address is displayed - just the "call" instruction itself!

This problem, and slow  down did not occur in VS 2005.

The interesting part is that sometimes, if during debugging I switch to another window, do something, switch to something else etc. and then switch back to the pending debugger, it starts working  as a rocket! Like it was some lock a debugger had to acquire each step and now it is gone!

The project  being debugged does not do or initiate any network or inter-process communications, it's just a simple console  app.

And to finish a "bug report" - starting from SP1 command "Step to cursor" crashes the Visual Studio.

OS - Windows XP.
 

Answer 15

I unchecked the Edit and Continue from the debugging  options.  That fixed my slowness with Visual Studio 2008 debugging.

I also removed the google toolbar from IE and noticed a faster loading response from pages within the VS 2008 web application.
 

Answer 16

I was finding that stepping  while debugging  a native C++ application was taking up to a second.  I closed all other source file windows except the one I was stepping through and it became perfectly responsive again.
 

Answer 17

Hi All,

I've noticed in VS 2008 that if you have the 'Show Threads in Source' button selected in the debug  toolbar that stepping  can be at least 10 times slower.

I've also noticed that if your application takes  a long time  to start in debug mode that this can be resolved if you simply 'Delete All Breakpoints' under the Debug menu. This solved an annoying problem for me even though I only had a handful of breakpoints at the time.

Silas
 

Answer 18

My Setup:

Visual Studio 2008 + Service Pack (and all the latest updates) Windows 7 x86_64 Mostly Native C++

I'm not sure if this thread is still alive, but for educational purpose, I want to mention that for Native C++ projects  with multi-threads, if you have "Show Threads In Source" enabled (either right-click on Auto, Local, or Threads panel) you will get about 1-2 seconds delay per stepping.

 

Answer 19

Thank you CodeMonkeyNinja!!

I had this problem too suddenly, after working  fast before (VS2008/VB.NET WebProject)

"Show Threads In Source" enabled is the solution

 

Answer 20

Finally a fix to this problem!! It was that sneaky "Show Threads in Source" button. Debugging was painfully slow. Now it's back to normal.

Yay.

Thanks for posting the answer to my problems (of the moment)

 

VS2008 C++, WinXP

 
 
 
 
 
 

<< Previous      Next >>

Microsoft   |   Windows   |   Visual Studio   |   Follow us on Twitter