Microsoft.Alm.Shared.Remoting.RemoteContainer -> High CPU - by ChrFin

Status : 

  Deferred<br /><br />
		The product team has reviewed this issue and has deferred it for consideration at a later time.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 807273 Comments
Status Closed Workarounds
Type Bug Repros 70
Opened 10/31/2013 8:11:02 AM
Access Restriction Public


I am using VS 2013 RTM since a few days and sometimes this process, which is spawned by devenv.exe, uses 50-80% of my CPU (over all my 8 Cores -> it uses 4-6 cores 100%).

What ist this process and why is this happening?

I think this is happening when the CodeLenses are updated - expecially in my ICollection implementation class the >50% phase is sometimes ~1 minute...

This problem was alread reported at
Sign in to post a comment.
Posted by Dwayne Robinson on 11/3/2017 at 9:57 PM
Horrible work-around: rename the file"C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\PrivateAssemblies\Microsoft.Alm.Shared.Remoting.RemoteContainer.disabled.dll"
It's the only effective solution that worked for me. Otherwise, even with CodeLens disabled, the process hogs my CPU for dozens of minutes, to the point that active foreground process are slowed.
Posted by dwolfe on 9/15/2017 at 9:46 AM
Still see this spike in VS2017.
Microsoft Visual Studio Enterprise 2017
Version 15.3.4
Microsoft .NET Framework
Version 4.7.02046
If this is a background task it shouldn't cause my CPU's to spike let alone cause my machine fan have to spike up to help the poor CPU's from burning up. I've see the spike up to 80% of my 4 CPU's. Yes a smaller machine than most other developers.
Posted by Jan Krivanek on 4/25/2017 at 3:12 AM
Visual Studio 2015 Update 3 -> issue still present
Posted by ChrFin on 2/10/2017 at 4:41 AM
For me it did improve a lot in VS 2017 RC. The spikes are still there but way less frequent and most important they do not delay the IDE anymore...
Posted by nZeus on 2/10/2017 at 4:36 AM
Issue is still there, VS 2015 Update 3.

I vote for reopening the issue
Posted by anantjot on 1/25/2017 at 3:05 PM
I experienced when using VS 2015. It just come on with high cpu usage with laptop fans going full speed. Very much annoying...
Posted by Michael-116 on 1/16/2017 at 8:09 AM
And to clarify, this is during normal development on a large enterprise application.
Posted by Michael-116 on 1/16/2017 at 8:03 AM
Still a super frustrating issue on VS 2015 Update 2. 14.0.25123.00 Update 2.

Posted by Karpuk Mikhail on 12/15/2016 at 3:26 AM
It's clearly CodeLenses update issue.
For me it happened when I look at Dispose method in the class which implements IDisposable. I guess it re-calculates all usages of Dispose in the solution (while 99+ would be enough for me). Unfortunately even if I let VS to calculate it (about a minute of ~99% CPU usage), each modification of a class with IDisposable causes re-calculation. I ended up commenting IDisposable usage for classes which I'm editing - which is very inconvenient
Posted by Petr Vones on 11/13/2016 at 9:34 AM
This issue is very annoying and persists with latest Update 3 version 14.0.25431.01. I can easily reproduce it by opening a source file of a class that overrides ToString() method. Its references number indicator is stuck and the process takes 99% CPU resources forever.
Posted by ChrFin on 10/18/2016 at 4:50 AM sad as it sounds, but the workaround is to disable CodeLens. Hopefully VS "15" fixes this once and for all...
Posted by Daniel Latikaynen on 10/18/2016 at 4:47 AM
this is urgent and should not wait until a "next major release". it it a serious responsiveness issue, at least, and hinders productivity. please provide at least a workaround.
Posted by sholodak on 8/6/2016 at 7:42 AM
Also still an issue with the latest Update 3 KB patch. 14.0.25425.01 Update 3. Turning off CodeLens until a fix is available.
Posted by Mr Onosa on 8/4/2016 at 6:13 AM
This is still an issue. Visual Studio Professional 2015 Version 14.0.25422.01 Update 3.
Posted by Spivonious on 7/25/2016 at 7:54 AM
Definitely still happening in VS2015 Update 3 (14.0.25420.01 Update 3). It seems that opening a file with an override of Equals or ToString. Oddly enough, GetHashCode does not cause the issue. CPU usage drops almost immediately after the file with the override(s) is not in the active tab.
Posted by Anthony Trudeau on 7/21/2016 at 5:55 AM
VS2015 Update 3, I read the workarounds. I have no open classes with ToString overrides.
CPU hits around 60%
Posted by Anthony Trudeau on 7/21/2016 at 5:51 AM
Seeing this since VS2015 Update 3. May have been there before, but if so I didn't notice it.
Posted by Raffaele Rialdi [MVP] on 7/8/2016 at 12:39 AM
Verified (again) on VS2015 Update 3
Posted by Bruce Dawson2 on 6/29/2016 at 6:16 PM
This process is currently using 10-20% of my CPU time. This is on a 24-core/48-thread machine, so that's about 5-10 hardware threads devoted to ???

This is significantly slowing down builds (especially if I run my compilers at low priority to avoid interfering with the UI) and it needs to be fixed.
Posted by guillaume62 on 5/9/2016 at 5:47 AM
This is starting to happen to me too, since I installed Update 1 of VS 2015.
Posted by NightKoder on 4/12/2016 at 7:38 AM
Hitting this problem with Visual Studio Enterprise 2015 Update 1. The process seems to randomly spike the CPU for several minutes, kicking in the CPU fan. Anyone know what this process is doing?
Posted by Bruce Dawson2 on 11/19/2015 at 1:53 PM
I am also hitting this problem. It consumes enough CPU time to noticeably affect the performance of my builds. I have seen this obscurely named process using enormous amounts of CPU time with VS 2015 Update 1.
Posted by Sergei Dorogin on 9/23/2015 at 8:58 AM
Toni Wenzel, the link "" is broken as well!
Posted by Toni Wenzel (CHG) on 9/6/2015 at 10:42 PM
Sorryy, wrong link:
Posted by Toni Wenzel (CHG) on 9/6/2015 at 10:42 PM
Vote for this new opened issue
because this issue is already closed.
Posted by Rosewood99 on 7/27/2015 at 9:38 AM
I'm having this issue with the new VS 2015 RTM. I have definitely narrowed it down to CodeLens. When enabled it brings my whole computer to a crawl, even without opening a solution. Disable CodeLens and everything goes back to normal.
Posted by SLD54 on 6/25/2015 at 12:54 AM
same issue with VS2013 update 4.... (12.0.31101.00)
Please make something, coding is really really annoying with that bug !!! Text lags, typing lags, everything lags and just this process is taking CPU (I have a really good machine I7-16GB-SSD... so what?)
We paid for a ultimate licence, we expect better performances.
Posted by ThomasG on 6/17/2015 at 11:27 PM
same issue with VS2013 Update 4 (12.0.31101.00)
Posted by Moslem Ben Dhaou on 6/5/2015 at 3:30 AM
Still having same issues with VS2015 RC..
Posted by Manuel Rin on 3/18/2015 at 11:15 AM
Although this item is closed and I'm looking forward to improvement with the next VS release, I've still added a parallel stacks view of a memory dump created while having this issue.
This might give the Visual Studio Dev Team an additional hint for where to optimize for the real world.
@MS Connect Support, please forward to the Dev Team if possible.
Posted by StevenQuick on 1/6/2015 at 6:56 PM
Still seems to be a problem for other people too
Posted by StevenQuick on 1/6/2015 at 6:52 PM
I am still seeing this problem in VS 2013 12.0.31101.00 Update 4.

An alternative to the other workarounds (turning of code lens) is to disable the source control integration: Tools > Options > Source Control > Plug-In Selection > None
Posted by Microsoft on 5/20/2014 at 9:02 AM

We appreciate all of the great feedback on this connect report. I wanted to let you know that we have made some changes to the priority of the other process in Visual Studio Update 2. This will likely not affect CPU utilization, but we expect it to alleviate freezing behavior in Visual Studio. We have plans to make deeper improvements, but those won't happen until the next major release of VIsual Studio (i.e. not an "update") because we will be taking advantage of presence of the .NET Compiler Platform ("Roslyn"), which was announced at BUILD. So, while I'm closing this issue, please be aware that we have work planned for the next release of Visual Studio to correct it.

Kind Regards,
Dustin Campbell
Visual Studio Managed Languages
Posted by Venryx on 4/23/2014 at 9:04 AM
I have the same issue. My processor is the AMD FX 8320, and when the above spike occurs, it sometimes gets so bad that my cursor begins to not respond smoothly--it jumps from place to place, with a very slow refresh rate.

The CodeLens feature is very helpful, so it would be nice to not have to disable it to fix this problem. In the mean-time, I can live with the delays, since they only happen every once in a while. It's large enough of a problem that it should definitely be fixed in the long-term, though.

I have little idea of what it takes to improve the performance in this area, but with it taking up this much processing on an 8-core processor, it seems it could be a huge problem for developers working on computers with only 1 or 2 cores.
Posted by Fluxify on 2/9/2014 at 11:37 PM
Hey guys, so this morning this process was spawned again - using 100% memory, 100% processor usage (across all 4 cores). My entire computer came to a halt for about 10 minutes after which I had to hard-shutdown my PC and lost all changes. This happened after making two changes inside a dataset for a website project. This really needs to be sorted ASAP - I use the CodeLens feature quite often to peek at definitions and to stay in touch with who's changing what in a source-controlled project.
Posted by Fluxify on 2/6/2014 at 6:06 AM
Hey guys, I'm also running Visual Studio 2013 Ultimate, with Update 1 applied on Windows 8.1 Pro. On my side it seems that when making changes to any class file within the App_Code folder of an ASP.NET Website Project, and the project is quite large, this little process just eats up my memory and CPU. On idle (or during normal development), my memory usage is around 41% and CPU load at 9-20%. Once this file is running, my memory usage spikes to 87%, and the CPU load going up to 82%. It seems once the entire App_Code folder has been compiled (supposedly in the "background", however the IDE becomes unresponsive) then this process quits and my system returns to normal.

It's become so bad that I have to write my classes within an ASPX page to avoid it being compiled in the "background". Once the class has been tested, then only can I move it to its own file in the App_Code folder. VERY FRUSTRATING!
Posted by Nate Diamond (Low Gravity Innovation) on 1/27/2014 at 1:25 PM
I am having the same problem as Phil, and I also have Update 1. Visual Studio is often using 1.6+ gig RAM as well.
Posted by Phil Soady on 1/26/2014 at 6:23 PM
With recent update 1 on VS 2013 ultimate im plagued with 100CPU issues. ALM.shared remoting using 70% of the CPU. I have to kill to the task to continue to develop
Posted by The Brans on 12/26/2013 at 4:08 AM
It is using not only CPU but with time a lot of memory, please fix this! -VS2013 Ultimate
Posted by MPolicarpo on 11/29/2013 at 5:04 AM
I have the same issue using VS2013 Ultimate. We have some classes that inherit from ICollection and the RemoteContainer.dll is constantly using 100% of the CPU every 5 min more or less. Also ended up turning CodeLens feature off.
Posted by Chris Bjugstad on 11/25/2013 at 1:03 PM
I gave up and just turned off CodeLens (Tools>>Options>>Text Editor>>All Languages>>CodeLens). I'm back to normal performance. After a couple other tests this problem seems to be more of an issue as a solutions gets larger (by number of projects).
Posted by Chris Bjugstad on 11/25/2013 at 7:14 AM
I did some further digging. I ran sysinternals procmon and filtered for this specific process. In my case the process (Microsoft.Alm.Shared.Remoting.RemoteContainer.dll) is reading/writing dlls referenced by one of my projects to a "shadow copy" folder.


The above folder had 2600+ empty folders. I deleted the <some_guid> folder and VS was faster at first until the process created 1500+ plus empty folders. I'm wondering if this is some sort of code analysis or JIT compilation that the editor is kicking off and it's getting slowed down enumerating all the folders in that shadow copy directory?
Posted by drevange on 11/22/2013 at 11:26 PM
Heck, even this site is having delay issues (I am on a completely different machine and completely different location and internet connection for this site than the one with a problem with VS)
Posted by drevange on 11/22/2013 at 11:20 PM
Chris - I also have VS 2013 Ultimate and it just started today. I am really suspicious that it is trying to hit something at MS over the internet and this is causing issues... Similar to how it can bog down with symbol loading from MS. What don't we know? How can this just "pop up" as an issue?
Posted by drevange on 11/22/2013 at 11:12 PM
I am hammered on this issue as well - CPU is running at 100% capacity with this taking 80%+
Posted by Chris Bjugstad on 11/22/2013 at 2:08 PM
I'm seeing the same problem in VS 2013 ultimate. It make the IDE unusable when simply editing a C# file.
Posted by kievryan1 on 11/21/2013 at 4:12 AM
I also have the same issue.

What exactly is this "remoting" ?
Posted by citykid dl on 11/18/2013 at 5:29 AM
I face the very same issue and must add that this is somewhat serious. About 5 times a day the cpu powers up for 1 minute.

btw, accessing a webpage at MS Connect constantly takes about 1 minute instead of expected < 1 second.
Posted by Microsoft on 11/5/2013 at 9:39 AM

Thanks for taking the time to report this issue. We are investigating ways to improve this for the next full release of Visual Studio. For now, this is on our internal backlog for the next release.

Kind Regards,
Dustin Campbell
Visual Studio Managed Languages
Posted by Microsoft on 10/31/2013 at 11:04 PM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Microsoft on 10/31/2013 at 8:50 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(