SharePoint 2013 + Visual Studio 2012 Debugging extremely slow RRS feed

  • Question

  • Hi,

    We're running Windows Server 2012, Visual Studio 2012 and SharePoint 2013 in VMWare Workstation virtual machines. We've noticed that debugging SharePoint server-side code is extremely slow. This shows up in two different ways

    1) When a debugger is attached to w3wp.exe, all request to SharePoint 2013 are slowed down considerably, including requests that do not execute custom code, such as event receivers. This happens even before any symbols have been loaded.

    2) Debugger step-through in custom code is also extremely slow, it might take 10 seconds to step through basic code.

    The VMs in question have 16GB of RAM allocated, on fairly performant (Lenovo W520) laptops. The VMs are on SSDs, and generally optimized for good performance. In general the performance of the VMs is ok -- or to put it another way, the performance of debugging SharePoint server-side code is not at par with the general performance of our images.

    Has anyone had a similar experience? 


    Tuesday, January 29, 2013 8:18 AM

All replies

  • The debugger is intrusive, it will stop the process when you hit a breakpoint. any other asp.net requests to that w3wp.exe process will pause.

    But it sounds like you have another issue. Have you checked that your CPU allocation is healthy?

    Independant SharePoint Consultant. Feel free to contact me. Blog: http://www.sharepoint.bg/radi Twitter: @RadiAtanassov

    Tuesday, January 29, 2013 6:52 PM
  • Thanks,

    I know it'll stop at breakpoints, but you're right, that's not the issue here. We're not hitting any breakpoints for sure.

    One thing I didn't mention, but which you pointed out, is that the Visual Studio Remote Debugging Monitor process is eating up arount 26% of my CPU, and the CPU usage is at about 40% when debugging in total. However, I'm not experiencing the same issue with the same system on Win2008R2+SP2010+VS2010, with another VMWare image configured the same way as my SP2013 virtual box.

    So I guess I'm trying to figure out why it is that Visual Studio debugger slows my SP2013 to a crawl, but this isn't happening on my SP2010 box. I know the system requirements have increased in general, but like I said, the decrease in performance in this particular case is huge, while the system is running ok'ish otherwise.

    Wednesday, January 30, 2013 1:10 PM
  • >>the Visual Studio Remote Debugging Monitor process is eating up arount 26% of my CPU

    So you are attaching to process on another computer? What if just debug on local computer?

    Update: i had made a mistake here:

    If you debug a 64-bit application on the local computer, Visual Studio uses remote debugging to connect between WOW64 and the 64-bit application on the same computer.  (from http://msdn.microsoft.com/en-us/library/vstudio/ms184681(v=vs.120).aspx)

    And SharePoint are 64bit.

    • Edited by GuYuming Friday, July 26, 2013 6:35 AM fix my error
    Friday, February 1, 2013 4:11 AM
  • Hi,

    I'm actually debugging on a local computer. So everything is running on the same virtual box. I'm not sure why the Visual Studio Remote debugging monitor is firing up. Maybe it's because it's 64-bit code (see this discussion http://social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/0633de8b-cee5-4210-a42b-6f00d6b4eec6/)

    Some more info:

    I now added some more memory to my system, and the VM now has 18GB of memory with no visible effects.

    Thanks for the replies so far!

    Friday, February 1, 2013 6:09 AM
  • Jarno,

    I too am seeing the exact same thing - same setup.  Server 2008R2 + VS 2012 + SP 2013 + SQL Standard 2012 inside VM Workstation 9 w/ 16 GB RAM & 4 Procs committed to the VM.  At first thought it may have been the dynamic memory.  However, I disabled the dynamic memory in Workstation and I'm still only running at a little less than 7GB of RAM (leaving 9 GB not utilized).


    Saturday, February 2, 2013 10:04 PM
  • Thanks for sharing,

    the weird thing is, I have a colleague who reported that debugging is fine. I'll check with him and I'll report my findings, if I can isolate the differences.

    We both have the same amount of memory, but he does have a faster processor. I have this one: http://ark.intel.com/products/43122/Intel-Core-i7-720QM-Processor-6M-Cache-1_60-GHz. 

    I'd be surprised though, if there was such a huge difference between a Lenovo W510 and W520, which he has, but I'll look into that.

    Monday, February 11, 2013 3:00 PM
  • Here's a strange thing I've noticed...

    Scenario 1:

    When deploying solution to SP from VS (F5), if SharePoint's AppPool has 'cycled down', then the Visual Studio Remote Debugger spikes to 20% of processor and SharePoint very seldom even loads.

    Scenario 2:

    Prior to deploying the solution, I open up the local SharePoint in my browser.  This starts the AppPool process.  Once, SharePoint loads in the browser, I go back to VS and deploy solution.  SharePoint now comes up without a hitch.

    The combination of the two scenarios is also the same...If I've worked in Visual Studio for at least 20 mins without deploying/reloading SharePoint (enough for the default recycle timeout of the AppPool), then the debugger takes forever.  However, as long as I continue to deploy my solution and/or refresh SharePoint in the browser to keep the AppPool from recycling, I have no issues.

    Therefore, I've increased the default AppPool recycling timeout from 20 mins to 60 minutes just to be on the "safe" side and most productive.

    Ultimately, I think the issue lies somewhere in the cycling of the AppPool. Just my humble opinion.

    Tuesday, February 12, 2013 6:57 PM
  • Hi,

    thanks for the input. However, I've noticed no difference between a "warm" and a "cold" SharePoint site. Usually I just make a modification to the server-side code, update my changes, and warm up SharePoint by opening the site in my browser. Debugging, as well as SharePoint UI, is still extremely slow for me :(

    Monday, March 11, 2013 7:03 AM
  • I experience the same problem on different machines. Any solution available yet?
    Wednesday, April 17, 2013 12:23 PM
  • Hi All,


    • SharePoint 2013,
    • Windows Server 2012,
    • Microsoft SQL Server 2012,
    • 8GB Ram 8 Cores,
    • 100 GB HDD

    then I tested my system, the pages are loaded too late (5s)


    • SharePoint 2013
    • Window Server 2008 R2+SP1
    • Microsoft SQL Server R2+SP2
    • 8GB Ram and 8 Cores
    • 100GB HDD

    then I tested my system, the pages are loaded very fast (1s) 

    I suggest second software requirements until service packs release for MS Windows Server 2012, MS SQL Server 2012

    I hope it's helpful

    Good luck.

    SharePoint Developer (MCPD) Web Site : http://sharepointciyiz.biz

    Wednesday, April 17, 2013 2:24 PM
  • Hi,

    Same problem for me. WebPart is extremely simple (helloworld complexity). VS2012 SP2, SharePoint 2013, virtual machine.

    Current situation:

    F5 was never finishing.

    CTRL + F5 was working fine (no debugging !).

    My solution is : 

    remove Intellitrace +  use the Start button (green arrow) to start the debugging (do not use the F5). This is what was recommended in SharePoint Conference 2012 HOL. I do not know the difference but it has resolve my problem, I am able to step my code.

    I hope it helps.


    Thursday, April 25, 2013 6:04 PM
  • Hmm, I'm not seeing IntelliTrace in the menu at all, so it's probably not installed. I'm using VS 2012 Professional. The problem is, I can't really use F5/Start button either, because the solution is too complex for that.

    I admit that I haven't analyzed exactly what would happen with just F5/Starting it, but Visual Studio generally has an unwanted habit of activating and deactivating features on Start/F5. The solution wasn't really designed for that OTB start/F5 system...

    Friday, April 26, 2013 8:57 AM
  • I have been struggling with the same issue - waiting up to a minute for the app to start up after attaching the debugger to the w3p process.  This continued even after a significant hardware upgrade running on SSD's (see spec below), and all of the VS2012 updates (currently running update 3 RC2).  

    Historically i have always run my dev environment under a single service account.  I finally tried logging onto my dev server using another account, permissioned at the same level as my service account on both the WFE & SQL servers.   Now, when I run visual studio using  a separate account the debugging is much faster.  

    Note:  Fully logging in with a different account seems to work much better than simply doing a "run as" on visual studio. 


    Hyper V VM 
    Intel i7 @ 3.5 GHz  (4 virtual processors running on VM)
    20GB RAM (non-dynamic)
    240 GB SSD

    MSNGN: Smart Simple Solutions http://www.msngn.com

    • Edited by MSNGN [tim] Thursday, June 6, 2013 3:29 AM fixed typo and added details about installed VS updates
    Thursday, June 6, 2013 3:28 AM
  • The Search Crawler is the biggest resource eater in SharePoint 2013. It takes lots of memory and process with noderunner.exe process. If you don't need Search crawling, you can stop the service from Central Admin -> Manage Services on server ->  'Search Host Controller Service". It'll save a lot of memory and CPU time.

    Sohel Rana

    Thursday, June 6, 2013 6:27 AM
  • I had the same config as the thread starter. I disabled Intellitrace and I'm good to go now. MUCH faster.


    • Proposed as answer by Michele Cilio Monday, August 12, 2013 4:55 PM
    • Unproposed as answer by Jarno Leikas Monday, August 12, 2013 4:58 PM
    Thursday, July 25, 2013 4:14 PM
  • Thanks for the tip. I've also heard that disabling IntelliTrace helps some people, but that's not the answer to my original question, as I don't have IntelliTrace at all in my edition of Visual Studio. Cheers, Jarno
    Monday, August 12, 2013 5:01 PM
  • It's not the search that's hogging my CPU. The problem is the remote debugging monitor.
    Monday, August 12, 2013 5:04 PM
  • Well, seems like upgrading to a W530 did the trick for me.

    Not sure if it's just because of the additional performance, or some less than optimal configuration of my VMWare image that caused the slowdown, but by the looks of it, my debugging is faster.

    Tuesday, August 20, 2013 5:28 AM
  • Hi ,

    have you tried to attach the debugger only to the  W3WP  of current site appPool.

    Say , you have deployed ur application on http://sp2013demo , and you want to debug ur deployed application , you don't need to attached all w3wp process , just you need to attach the debugger with w3wp of http:// sp2013demo .

    try the following 

    Open a command prompt window and go to c:\windows\system32\inetsrv by typing in

    cd c:\windows\system32\inetsrv

    Next type in

    appcmd list wp

    This will return a list of all application pools running, with their PIDs.

    the result will be as the following 

    c:\Windows\System32\inetsrv>appcmd list wp
    WP "4020" (applicationPool:SecurityTokenServiceApplicationPool)
    WP "10124" (applicationPool:SharePoint - 80)
    WP "13832" (applicationPool:SharePoint Central Administration v4)
    WP "15064" (applicationPool:c100c93f943f419ebf310f029b90201d)
    WP "12348" (applicationPool:6863ef4eddc4437cab65222ae4237101)

    if you deploy ur application on  (applicationPool:SharePoint - 80) , just attach the debugger with PID 10124 from visual studio . but attaching the deugger with all w3wp , definitely will make the Debugging process extremely slow.

    i overcame my issue by above approach.



    Best Regrads, Ahmed Madany MCTS @twitter http://twitter.com/ahmed_madany @Blog http://ahmedmadany.wordpress.com @LinkedIn http://eg.linkedin.com/pub/ahmed-madany/35/80/2b6

    Saturday, June 7, 2014 3:18 PM