I have installed visual studio 2013 Ultimate on Windows 8 enterprise edition.
When I start debugging an mvc project (which pretty empty) : it takes 27 seconds to start the debugging. I assume it's because IIS express 8 is loading symbols and hangs somewhere.
I have tried an empty mvc project and it starts in 10 seconds : which is very unacceptable.
I have tried :
- deleting all breakpoints
- enabling just my code
- unchecking symbols downloading from microsoft servers and downloading them on a local folder on the computer
- disabling intellitrace (was already disabled when i went to see)
- disabling just-in-time (was already disabled when i went to see)
- unplugging the ethernet cable (yes, i am pretty desperate)
- no antivirus is turned on
The first request (when i launch debugging) always take 27 seconds according to glimpse. The controller run under 1 second which is "acceptable". All the next requests are fine.
But I can't work with the 27 seconds each time I launch debugging.
Can someone help me ? I do not know what to do next.
My computer is a dual core 3Ghz with 4 Go of Ram and a 7200 rpm hd. I don't think it's hardware related.
Thank you very much.
UPDATE :
As soon as I start to use NLog in the code, it takes 30 sec to launch the debug mode.
If I comment all the place where I log something, It takes 10 sec. Sometimes less.
How much time you guys take to launch the debug mode ?
It's quit possible you are referencing dead or slow symbol path. For example, you're at home but accessing a symbol path on company's server. Check it under Tools -> Options -> Debug -> Symbol. If it's ok, check your system as follows.
Make sure there is no other process that runs out of your hardware resources.
First check if CPU usage is too high after staring debugging. If CPU usage is too high, use Process Explorer to check what activities VS Is performing. If they are in an extension thread, disable that extension. If they are in VS own thread, it's most likely a VS bug you can report to MS.
Check if memory usage is too high. If VS memory usage is too high, given that you just start simple debugging, it's a VS bug.
If both CPU and memory are ok, it's probably related to IO operation. Use Process Monitor to check which files are being accessed, especially files on remote machine.
This is how I troubleshoot the same problem on my machine. Hope it help you.
Related
I was using RAD 10.1 (Berlin) with no problem until now... Last month I applied Windows Creator Update and was occupied by other businesses... Now, each time I start the IDE, the loading progresses quickly up to "All design time packages loaded". At this time RAD studio sits on its splash window and consumes ~25% CPU. It takes at least 10 minutes before the IDE appears...
I've installed RAD 10.2 (Tokyo) and all provided patches, hoping for a fix... But the problem remains the same.
I can't go back to previous version of Windows 10 (more than 10 days after install).
I've already searched for an answer and Matthias E suggested that it was linked to https://quality.embarcadero.com/browse/RSP-17972.
But, in my case, the (very) long period stands only for IDE loading even when there is no project to (auto)load. I'm not talking about the time-period to load the project or to start project execution or even to start the application execution. Once the IDE has been loaded (after ~20'), everything (editing, compilation, building, debugging, execution) is working quickly...
I have become accustomed to never close the IDE once opened but this is particularly disturbing.
Could you help me ?
--- Edited ---
For those who cannot access the link above, here is the content :
Details
Type: Bug Bug
Status: Open Open
Priority: Major Major
Resolution: Unresolved
Affects Version/s: 10.2 Tokyo, 10.1 Berlin Update 2
Fix Version/s: None
Component/s: Debugger, IDE (Development Environment), Libraries/Frameworks
Labels: None
Platform: Windows 10
Language Version: English
Edition: Professional
InternalID: RS-83785
InternalStatus: Open
Description
The debugger goes haywire for everyone in our organization with Creators and Tokyo/Berlin. Reverting to Windows Anniversary brings back the sanity.
Debugger problems with Tokyo/Berlin and Creators:
App takes a long time to load with modules loading and unloading and re-loading many times
IDE freezes
Memory consumption of bds.exe explodes, sometimes (> 3GB)
I will attached before and after screenshots showing how modules load and unload and re-load with Windows 10 Creators.
I presume these problems have the same root cause(s) than those in https://forums.embarcadero.com/thread.jspa?messageID=884382*
--- ---
Thanks to Lieven Keersmaekers's suggestion to use procmon, I was able to find the cause of the problem. RAD studio was heavily trying to access an enormous (128 GB) zip backup file (see : qed-electronic.com/Download/170808-ProcMonTrace.jpg ). I've simply moved the backup file to another location and RAD studio now starts as before. I have no idea why RAD wanted so much to access this file : none of my project files were located in this zip. The Windows Creator Update was apparently not guilty...
bds.exe must be launch with only one CPU !
CPU Affinity CPU=0
Thx to Javorszky
https://community.embarcadero.com/forum/installation-issues/1408-running-from-ide-freezes-windows-10#4173
To run quickly without entring TaskManager and change Setting CPUAffinity,
just create a batch file on the desktop:
cd "C:\Program Files (x86)\Embarcadero\Studio\19.0\bin\"
start /affinity 1 bds.exe
Why ?
"The reason for this is that most applications you run these days have been designed with multi-core processors in mind and will work with the operating system to distribute their operations as evenly as possible across all the available cores. "
see : https://www.techrepublic.com/blog/windows-and-office/change-the-processor-affinity-setting-in-windows-7-to-gain-a-performance-edge/
I have VS 2013 and Microsoft Windows 8.1
The issue appeared at the ending of last week. Without any updating or important changing, when I do somethings in VS, disk usage reaches 100%. For example, when I click on "Check In" button in the "Team Explorer" window, disk usage raises up to 100%. Sometimes by a simple right-click in text editor this problems happens.
I googled about 100% disk usage problem but there are some things about this problem on windows 8.1 but on my computer, all applications are running without any problem, just VS2013 has a "full disk usage" problem.
Some information about my system:
OS Name: Microsoft Windows 8.1 Pro
OS Version: 6.3.9600 N/A Build 9600
System Type: x64-based PC
Processor(s): 1 Processor(s) Installed.
Intel64 Family 6 Model 60 Stepping 3GenuineIntel ~3500 Mhz
Total Physical Memory: 8,131 MB
Available Physical Memory: 3,836 MB
Virtual Memory: Max Size: 10,947 MB
Virtual Memory: Available: 5,275 MB
Virtual Memory: In Use: 5,672 MB
Page File Location(s): C:\pagefile.sys
(Comment for others landing here as #Marta explains that the problem no longer persists on their machine.)
In general, any performance issue in Visual Studio should be reported to Microsoft. It's easy to do this directly from VS using the Report a Problem tool. That feature will automatically attach logs/traces which are shared privately with Microsoft. Internally, tooling will analyse those attachments to assign a ticket to the relevant team. With such attachments, there is a high likelihood that the problem can be diagnosed and fixed in a future release of Visual Studio.
Instructions on the Report a Problem tool:
https://learn.microsoft.com/en-us/visualstudio/ide/how-to-report-a-problem-with-visual-studio?view=vs-2019
If you prefer to diagnose high disk IO yourself, FileMon can be a useful tool:
https://learn.microsoft.com/en-us/sysinternals/downloads/filemon
I am using Visual Code 1.71.2 as well as Visual Studio 2022 (Community Edition) on Windows 10. I am also facing the same issue.
After lot of checking, found disabling superfetch mitigates this issue. But again, Windows, applications startup take lot of time.
As a workaround, I found that by clearing %temp% folder after using visual studio or code eliminates this issue and disk activity is normal.
But every time, I may not remember this cleanup and hate it for forgetting :(
Hope this helps someone in similar situation.
It could be related to Visual Studio updates - which would show under C:\ProgramData\Package Cache.
A disk space management tool like TreeSize Pro will help figure it out though ... it will show which directory is using the most space. You can then target what aspect of Visual Studio is eating up your drive space.
There is a free trial at https://www.jam-software.com/treesize/
You can also use this tool to export and post a screenshot / export of the usage here and it may help identify what is going on.
I had a similar issue that turned out to be the built-in git provider having issues with large codebases containing a moderate-to-large amount of changes before a commit.
Changing to a third-party one fixed the issue.
The operating system manages the resources (CPU cores, disk drives, GPU) to deliver what you have asked of it.
Ideally (what the OS designers are hoping for), when you perform an action, all the resources spin up into action and due to a well balanced system, they all go to 100% utilization, for a brief length of time, then go back to idle.
This form of utilization is, in practice impossible to achieve, as the PC builders would have to know what your system is going to be used for.
When the task manager describes the CPU as 100% utilized, it means that all the cores on the box, are busy running code, and are the bottleneck.
When the task manager describes the disk as 100% utilized, it (as far as I can tell), means that there is always a queue of items to be read, or written to/from the disk. Even with 100% utilization, it may be that the metric is the only reason you are concerned, and the system is otherwise responsive.
In either of these cases, it shows that for a given workload, the CPU or the disk drive has become the rate determining step.
In practice, it should not matter, unless the length of time the system is at 100% is longer than a few minutes, or that your machine feels otherwise sluggish.
Further diagnosis can be performed by using the tool Sys internals : procmon, or the Microsoft : ADK
I would look using the procmon, at what files are being accessed during the 100%disk usage period, and decide whether
The behavior is sensible (if not raise a bug with Microsoft)
The machine is working usably (if not consider a hybrid or ssd disk)
I've had some exasperating problems with disk usage and source control explorer.
What fixed the issue for me was making sure that I never opened Source Control Explorer in more than one project at a time, keep it closed when I could and limit the amount of VS instances you have open.
An SSD may can solve this... Are you sure this is caused by visual studio? when I was using Windows 8.1, the Windows Defender get to 100% disk usage from time to time. If you're sure it occurs when you use Visual Studio, you can try to repair it using the installer. Hope these would help you.
Try moving the source code to SSD drive.
HDDs have much slower disk I/O performance compared to SSD drives.
Generally in windows C drive comes as SSD drive.
Have you ever experienced a slow linking process in a C++ project compile (I'm using VS2013)? I get linking process taking 15 minutes after a 5 minutes Build. A Rebuild or Visual Studio restart does not fix the issue.
Task manager shows mspdbsrv.exe taking a full core (25% on a 4-core), and pdb file creation is very slow, Kb after Kb it reaches 50 Mb.
Additional info:
the same project on another computer build and link in acceptable time.
antivirus is disabled
I've tried changing the pdb file creation location: no success
I've set the linker output Verbose, but it stops at one debug row and then wait all the time there.
VS2013 is updated to SP4
Hard disk activity led on my laptop is mostly turned off, so there's no full activity on the disk.
I'm running Windows 7 Pro.
VS2013 is run with administrator rights
Thank you.
Fixed changing "Debug Information Format" from /ZI (Edit and Continue feature) to /Zi. I still have no clue why this cause a slow linking only on a specific computer and not for the others. Hope this could help people coming here for the same issue.
Is it using Link-Time Code Generation? On VS2010 that step was single threaded so it takes much longer than the apparent compile step. On later versions this step was improved to be multithreaded, according to blog posts. It also mentioned that PDB access is a bottleneck. So, maybe you have an old mspdbsrv.exe on that system? Look at the version info on the file, compared across machines. There might also be some option to control its locking and multi-use behavior, hidden away someplace.
I'm using Visual Studio 2012 Update 3. When I open a project, VS automatically creates a process called <myproject>.vshost.exe, even before starting to debug.
When I start debugging and later close the debug application, most of the times the <myproject>.vshost.exe process closes as well. When this happens, devenv.exe starts taking up 3x more memory than normal and CPU goes up to 25% (on a i7 Quadcore with 8GB ram) for around 1 minute. At the end of 1 minute, a new <myproject>.vshost.exe opens up (even though I'm not debugging), CPU falls back down to 0 and memory drops back down as well.
Trying to start debugging whilst the CPU is at 25% and <myproject>.vshost.exe is not running in the background will results in the solution building but the debug does not start.
If I wait until the CPU falls back down and <myproject>.vshost.exe process is running again then I can start debugging normally.
This happens to me 80% of the times after closing the application I am debugging. The remaining 20% of the times when I stop debugging <myproject>.vshost.exe continues running in the background and I am able to start debugging again immediately after with no delay.
This also happens regardless of code changes in between debugs.
This is a new install of VS2012 U3, I've tried resetting all settings and disabled ReSharper but still no joy.
I don't want to disable vshost debugging because of the features I would lose.
Has anyone else encountered this problem before? Is this a known issue? Are there any solutions/workarounds?
EDIT
I changed the platform from Any CPU to x86 and it appears to work properly, but I still can't understand why I shouldn't be able to debug it as Any CPU. Even though this might be the workaround I'd still be interested in knowing whether this is a known issue and if there are other (better) solutions.
By 'working properly', I mean that when I stop debugging the vshost doesn't close, in fact it never closes, but the CPU of devenv stays at 0% and it allows me to start and stop debugging as many times as I want one right after the other.
EDIT2
Actually it appears that changing the platform to x86 only worked properly for a while, after about 20 rebuilds it is now doing the same as leaving it as Any CPU.
On another note, closing and opening VS makes no difference.
I've ended up formatting the computer again and re-installing everything from scratch. For not it appears to be working fine, let's see how long this lasts for.
I know this is several months old but I'm trying to post this answer in a few places since this is what was causing my ills: I had the Data Sources toolbox open in Visual Studio 2012. Once I closed that, it seemed to eliminate the lengthy delays when switching windows. You may also want to close Server Manager if you don't need it open.
I know this is old Post but, I think I need to share my solution for everyone.
and this is my first post so, please improve the answer if I miss something.
I have the same issue with Visual Studio 2012, When I try to build or debug it will use CPU up to 100%.
So, I try below steps to reduce the CPU usage while debugging:
Please close unnecessary opened file.
Hide unnecessary debugging panels like: breakpoints, auto, local, output, find symbol result, etc.
If still use high CPU then try to hide call stack panel.
Remove unnecessary breakpoints.
Im using ReSharper 6 in a Vs 2010 Pro environment and are doing some pretty large scale projects. Development box includes 2 x quadcore xeon with 24 GB ram. Project's are running on a PCI-E x4 SSD drive with 1GB/s read and write (for real). So, i suppose there is not much I can do to give the development machine more power.
The worst project is an Umbraco site with roughly 14000 files and folders and some pretty nasty css. I got everything from second long freezes to 30 sec VS freezout.
I've optimized VS2010 according to every guide available in VS optimization. Even enabled the 64bit memory enhancement but the problems continue.
I've even added the media library folder to the skip list.
Are there any other magic tricks someone would know of, please let me know!
gorohoroh's comment lead me to the solution, the 6.1 nightly dec 13 rocks!
Thanks
http://confluence.jetbrains.net/display/ReSharper/ReSharper+6.1+Nightly+Builds
I am using 7.0.1 and I find that it's killing my machine too.
However, it normally happens if I have more than one VS2010 open.
If it happens then the only way of fixing it I have found is to close VS, delete the DotSettings.user and the suo, and then reopen.
I'm using 6.1, and find that it slows down over time, and typing becomes really laggy. I've just discovered that when it starts to chug, if I go to "Tools..Options..ReSharper..General", then click on Suspend, then Resume - it goes back to it's initial speed.