22

Hopefully this is the right stack exchange site to post on... Didn't feel like it was a programming question for SO. Anyway, I'm running Visual Studio 2015 and got a notification to from Windows to close VS2015 because it's running low on memory. I have 24GB of RAM and just rebooted yesterday, so I think something is way off here. I sometimes use the C# interactive window, and python 2.7 interactive window, but those were not in use at the time of this message.

Note: As I'm writing this, I just got an "Unknown hard crash" message from devenv.exe (vs2015 process). But the Standard Collector service is still running using up 10.7GB.

Does anyone know what the Standard Collector is? And what might cause the RAM usage to spike?

Note: Again as I'm writing, I just noticed the Standard Collector Service stopped in my task manager and I have all my RAM back.

Large RAM usage by a Visual Studio "Standard Collector" process

Update: It sounds like this might be a bug that the VS team tried to fix in update 1. I definitely have update 1 installed, but perhaps I should try to reproduce in some sample code and send it to the VS team. The devenv instance that crashed was also not currently debugging. (Although, there is another instance where it is debugging as you can see by the .vshost.exe extension in task manager)

That devenv instance did not crash and it's actually still running in the debugger now without problems.

enter image description here

16

The Collector Process appears to be related to instrumentation/diagnostics of code running in debug mode, in Visual Studio 2015. Microsoft has acknowledged there is an issue with unbounded memory use of this process, and says, "We have researched the root cause and have made a fix that will be provided in VS2015 Update 1"

So make sure you get the latest Visual Studio 2015 update. For mitigation in the meantime:

"Meanwhile, if you notice that the process consumes too much memory you have two ways to recover. Simplest is just to restart your machine. That will get everything back to a fresh state. The other thing you can do to alleviate the memory consumption is to stop the Visual Studio Standard Collector Service using the Service Manager UI. The Name of the service is "VSStandardCollectorService140". It can be safely stopped when you not debugging with Visual Studio. If you stop the service while debugging (even stopped at a breakpoint) then the Diagnostic Tools window will display an error message after you resume the debug target process."

Look at this link, where the above quotes are sourced from: https://connect.microsoft.com/VisualStudio/feedback/details/1630071/visual-studio-standard-collector-unbounded-memory-usage

This link also has a code example of someone who experienced this from a console app. It could be worth running that sample code to see if it triggers the issue on your system. The person who reported the issue also indicated it occurred intermittently, but running the code in Visual Studio debugging mode seemed to be the one common thread.

Possibly Microsoft fixed some root causes of the issue, but there are still other unfixed causes now surfacing.

  • 1
    One simple way (Windows 7/Windows 10) to bring up the Services GUI is to do Start/Run and type "services.msc" and press Enter. In the list of services on my Windows 7 machine, the name I believe to be the one mentioned shows as "Visual Studio Standard Collector Service". – Developer63 Mar 23 '16 at 18:15
  • Interesting, although I do have Update 1 installed -> hence why I use c# interactive window (only available in Update 1). Interesting that the example code from your link that the guy reproduced uses Tasks. My application makes fair use of tasks and async code as well. – C. Tewalt Mar 23 '16 at 19:15
  • @matrixugly, as I understand the issue, the Collector Service is basically running all the time when VS2015 is running, collecting app instrumentation/diagnostic info. So what you were doing at the time when Windows gave the low memory alert may or may not have any relation to the issue. It could have been something much earlier, where the Collector Service process failed to recognize it needed to start clearing out old instrumentation data, gradually filled up memory, and the message appeared hours later during an unrelated activity. – Developer63 Mar 23 '16 at 20:13
  • 7
    Still exists in Update 3 RC. :( – SayusiAndo Jun 27 '16 at 5:00
  • 1
    Is this still a problem for VS2017? If so what are the consequences of disabling this service? – rolls Feb 27 '18 at 23:46
2

Disable the service and it won't eat your memory again.

Tools->Options->Debugging->General, disable "Enable Diagnostic Tools while debugging".

  • 2
    You should also mention that you won't have diagnostic tools which are part of the debugging suite that a lot of people use. – rolls May 9 '18 at 6:29
  • 1
    Personally, as a developer, I always disabled diagnostic tools because I felt it made my machine a lot slower since the first time I've seen it, and only enable it when I actually have a performance problem I need to diagnose (which is quite rare), and still, a profiling session usually give me much more information. I'm quite curious to know what would people use it for on a regular basis. – Eduardo Wada Dec 11 '19 at 9:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.