139

Starting Visual Studio 2015 also launches two other executables:

VsHub.exe

and

Microsoft.VsHub.Server.HttpHost.exe

Both of these take a considerable space in the task manager.

How can I delete this "Visual Studio Hub" option? I don't use any of Visual Studio 'top-notch' features, including the Visual Studio Hub one.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Reda Lahdili
  • 1,533
  • 2
  • 10
  • 5
  • They are considered part of Visual Studio and you should leave them as they are. – Lex Li Jul 16 '15 at 12:20
  • 15
    Well I really don't use Visual Studio for something other than code editing. I use Unity and compiling is done by the built-in compiler, so all I want to see in VS is a fancy text-editor. Also, I don't want to use VS Code since it lacks auto-completion for Unity and you can't make your own custom themes. – Reda Lahdili Jul 17 '15 at 16:47
  • 2
    @RedaLahdili What did you end up doing? Both files are running even when I'm not running VS2015. – prettyvoid Aug 09 '15 at 15:33
  • 2
    Your case seems worse than mine! I unfortunately haven't found any solution. They really need to do something about this. Sometimes VSHub takes more memory than VS itself. uggh... Keep us updated guys if you find any solution. – Reda Lahdili Aug 10 '15 at 17:46
  • @LexLi that comment of yours doesn't help much if they are stealing CPU time from my performance validation, does it? – Jonathan Dickinson Aug 13 '15 at 14:58
  • @JonathanDickinson The proper way is to reach Microsoft Connect and report it. Even VS has a Feedback menu item built in. Stopping that process only breaks more functionality, and do you think that help you much? – Lex Li Aug 13 '15 at 15:46
  • It is actually a chain of processes: http://content.screencast.com/users/KeesCBakker/folders/Jing/media/06ff7b28-5ea9-4717-84e9-a7afca8d77ff/2015-11-27_1046.png – Kees C. Bakker Nov 27 '15 at 09:47
  • 1
    Another solution is: http://stackoverflow.com/questions/31904929/how-to-disable-diagnostic-tools – oguzh4n Dec 25 '15 at 12:14
  • 1
    *Microsoft.VsHub.Server.HttpHostx64.exe* has a **memory leak** that causes my windows 10 to shut down. See: https://connect.microsoft.com/VisualStudio/feedback/details/1610160/microsoft-vshub-server-httphostx64-exe – Olivier Jacot-Descombes Jan 20 '16 at 17:37
  • 1
    Yeah, mine leaks about 18.5GB and then warns that it wants to shut it down. Luckily, it isn't that much of a performance hit, and it doesn't do anything to kill it as it'll respawn. There is another open bug listed here: https://connect.microsoft.com/VisualStudio/feedback/details/1293295/httphostx64-exe-has-stopped-working – Adrian Apr 14 '16 at 16:30
  • Disabled diagnostic tools and the memory hog was gone. I think this memory leak is caused by the diagnostic tools. – beerwin Nov 24 '16 at 10:58
  • The problem with this is, that it just continues to grow, until you reach the limit of your available physical ram, then starts to go into the swap file, causing a lot of disk activity, slowing down the entire system. – beerwin Nov 24 '16 at 11:01

10 Answers10

131

I thought I’d try to shed some light on the VS Hub and what it’s intended for. I work for Microsoft.

As sraboy mentions, the VS Hub is an out-of-proc services host that Visual Studio (and other VS shell-based products such as Blend) use in order to support multi-tool communication, better responsiveness within devenv (VS), and enable certain services to extend past the lifetime of the spawning process. The set of services currently hosted in the VS Hub includes many of the items called out in the other answers, such as roaming settings, processing of large swaths of ETL data that is rendered in the diagnostics tooling, some telemetry reporting, and extension auto update and notifications. That set of services is very likely to grow in the future though, so even if none of those services seem necessary at the moment, additional services will be hosted there in the future (i.e. it’s a pretty big hammer to disable the vshub.exe through the renaming recommendation :-).

In terms of lifetime, the vshub and host processes (i.e. Microsoft.VsHub.Server.HttpHost(64).exe) can stay running after devenv.exe closes. However, they should not keep running indefinitely. In most cases these processes will terminate within ~5 minutes of the last instance of a VS-based shell closing. So if you have an instance of VS running (devenv.exe) and an instance of Blend running (blend.exe), and you shut down devenv.exe, vshub and the associated host processes will keep running. If you then shut down blend.exe, vshub and the associated host process will still be running. After about 5 minutes from then, however, those additional processes will shut down. If you start another instance of devenv.exe within that 5 minute window, then vshub and the associated host processes will not terminate, and will keep running (basically the host processes terminate whenever they don’t receive any requests within 5 minutes, and after all of the host processes terminate, the vshub.exe process itself terminates).

Resource-wise, the vshub.exe process itself should always be relatively lithe. If it ever gets large, then that’s a bug and I’d love to know about it so we can fix it :-) The host processes, on the other hand, may get very large depending on the service that is being hosted. In particular, the diagnostics tooling works by processing ETL. ETL can be very, very, large, and as such, the host may use a lot of resources. The diagnostics team is looking at ways to reduce that, but for the moment, closing the diagnostics tool window when you don’t need it should help mitigate the problem.

In terms of online connectivity, there are three main sources in the current set of hosted services at the moment (note, this will change over time). First, as user3345048 mentions, the service that detects and auto-updates extensions runs in that process. The options that control that communication are in Tools | Options | Environment | Extensions and Updates (see the first two checkboxes). Second, roaming settings runs as a service in the VS Hub. The setting that controls this behavior is in Tools | Options | Environment | Synchronized settings (or more holistically, if you do not sign into the personalization account in the upper right hand corner of VS). Finally, the VS Hub does report telemetry. The volume of this data can be significantly reduced via the Help | Customer Feedback Options | Settings… menu item. You can also read about the kind of telemetry that Microsoft collects and how it’s used in that location.

Codler
  • 10,951
  • 6
  • 52
  • 65
Anson Horton
  • 4,020
  • 2
  • 12
  • 5
  • 40
    Anson - I have Visual Studio 2015 with the RTM release 1 on Windows 7. If I open up Fiddler4, I see hundreds or more calls a second to localhost/vshub/sameGuidHereOverAndOver. This is completely unacceptable - I don't know what vshost.exe thinks it is doing, but it is completely gone nuts. I can kill the process and it still happens. May have to go back to 2013... – Mario Oct 16 '15 at 15:41
  • 4
    @Mario - as you've seen vshub often acts as a local http server, so it's expected you would see _some_ traffic whenever it's running (http is acting as the IPC). 100s of requests per second for any sustained period of time is definitely a bug. You could check logs in %temp%\VsHub which should indicate if there are any exceptions being thrown, and obviously you've already figured out how to inspect the traffic. The best thing to do would be to report this as an issue through connect.microsoft.com since it'll give us a channel to collect the logs and such and try to make sure it gets fixed – Anson Horton Oct 18 '15 at 06:26
  • Thanks @Anson. I submitted here: https://connect.microsoft.com/VisualStudio/feedback/details/1919828/hundreds-of-calls-second-to-vshub-and-browserlink-is-off Unfortunately I don't see any logs in %temp%\VsHub (VsHub folder doesn't exist %temp%) – Mario Oct 19 '15 at 20:42
  • 28
    Here is Microsoft.VsHub.Server.HttpHost64.exe being "lithe" on my machine - http://imgur.com/DKvSNqf - that's 1GB of RAM it peaked out at. Nice. – sh1rts Nov 01 '15 at 23:04
  • 7
    @sh1rts - I understand your frustration. The "lithe" comment I made above was targeted at vshub.exe. Microsoft.VsHub.Server.HttpHost64.exe is the host process that runs various services, including some that can be very memory intensive (e.g. the diagnostic tooling that starts when you use F5, or if you explicitly choose to do memory or ui responsiveness analysis). You can try some of the toggles I mention above to disable some of those services to see if that helps - but generally we'll be working to reduce the overall memory overhead in future versions. – Anson Horton Nov 04 '15 at 02:51
  • 3
    Resource-wise, these processes are relatively light _unless_ [diagnostics tools are enabled](http://stackoverflow.com/questions/31904929/how-to-disable-diagnostic-tools), in which case VsHub, HttpHost and devenv together consume about 25% of my CPU just sitting there attached to an idle winforms application. But turning them off fixes the CPU usage. – Roman Starkov Nov 15 '15 at 15:09
  • Yes, diagnostic tools, which is enabled by default, cause devenv.exe to go eat up almost all of my available CPU. I hover between 80-100% CPU when debugging a single WebApi web service on a 4th-gen quad-core i7. This is just completely unacceptable. Killing devenv.exe and it's related processes bring my CPU down to 10-20% with a nodejs HTTP server, chrome, skype, and various other applications still running. Our firm is moving away from Microsoft tooling because the last few years have just been simply abysmal. – crush Nov 19 '15 at 00:09
  • 2
    @crush - Can you please open an issue at connect.microsoft.com for Visual Studio? That way we can collect a trace and figure out what's going wrong. It sounds like something else is going on if you're seeing devenv.exe eating up all of your CPU (the data collection for the diagnostics tools runs in another process, and the UI for those windows also runs in a separate process called scriptedsandbox.exe). – Anson Horton Nov 20 '15 at 17:52
  • 1
    @AnsonHorton I found that it is directly related to my power options on my Dell laptop. It was set to the default "Balanced" plan that Dell ships with. I changed it to Ultra Performance, and now Devenv sits around 10-20% instead of 80-100%. In VS2013, however, it runs at 3-5%. The only extensions I have in VS2015 are Web Essentials and NuGet. I'm not going to waste time with Microsoft support. We've already moved on. Good luck to others. Thanks for replying. – crush Nov 20 '15 at 20:00
  • 2
    @Anson These diagnostics need to be disabled by default. Fiddler blows up with hundreds of messages per second and it taxes Visual Studio. When I reinstall VS the first thing I turn off is the tracing and performance measuring capabilities. The feature is not executed well... – Shaun Dec 09 '15 at 02:43
  • 1
    @Anson, have to agree with Shaun that this is not well tested. I just installed the latest update for VS2015 and now fiddler is blowing up with hundreds of connections for me as well. Disabling diagnostic tools while debugging resolved it. – Justin_H Dec 11 '15 at 22:11
  • @Shaun - Check out http://stackoverflow.com/questions/33837163/visual-studio-2015-vshub-is-spamming-fiddler/33928841?noredirect=1#comment56100902_33928841 – Anson Horton Dec 13 '15 at 23:40
  • 17
    So what is the way to stop seeing hundreds of /vshub/GUID requests in Fiddler. This is making it impossible to debug any HTTP client in Visual Studio, because for every step while debugging I see 10+ requests in fiddler and the request I'm interested in is lost :-(. Besides it's seriously inefficient way of inter-process communication to make HTTP requests on localhost. – Đonny Jan 08 '16 at 15:18
  • 1
    So simply editing some source code with VS2015 already starts a HTTP server by default? I bet a lot of employers will drop VS usage the moment they discover that unpleasant fact. **Potentially leaking source code is not something employers think lightly about.** – Sjoerd Jan 20 '16 at 01:16
  • 1
    @Sjoerd - The HTTP server it starts is only listening to requests from localhost (and on a random port, prefixed with a unique GUID each time its launched). The set of services that are currently loaded into VS Hub don't access source code. – Anson Horton Jan 21 '16 at 16:10
  • @Đonny - http://stackoverflow.com/questions/33837163/visual-studio-2015-vshub-is-spamming-fiddler/ – Anson Horton Jan 21 '16 at 16:11
  • 4
    @AnsonHorton: Thanks for the time you've taken to shed some light on this. I think it would be great if there was an opt-in option for this. You may say its light but it was large enough for me to notice. If I had the option I would get rid of it. – chosenbreed37 Mar 18 '16 at 08:39
  • Though I realise that Microsoft.VsHub.Server.HttpHost64.exe will require _some_ memory, I think that 18.5GB over 2 days is a _wee bit_ extreme, don't you? – Adrian Apr 14 '16 at 16:40
  • 1
    @Adrian - maybe a wee bit. Seriously though, it definitely shouldn't take anywhere near that much memory. If you could enter a connect issue at connect.microsoft.com, or send feedback via the 'Report a problem' tool in Visual Studio we can follow up and figure out what's gone wrong. – Anson Horton Apr 15 '16 at 21:52
  • 3
    FYI, as of Update 2, they DO stay running indefinitely (until the user logs off). Not having run VS 2015 CE since yesterday, NOW I see about a gigabyte of RAM used between Microsoft.VsHub.Server.HttpHost.exe, Microsoft.VsHub.Server.HttpHost64.exe, and VsHub.exe. You Microsoft people really need to put a configuration option in there to stop VsHub from running entirely on systems doing entirely local development! – NoelC Apr 19 '16 at 14:06
  • Agree with the last comment...with Update 2, I'm now seeing a VERY large chunk of memory eaten up by Microsoft.VsHub.Server.HttpHost64.exe. All the more galling because I always have the diagnostic tools turned OFF. – karfus Apr 20 '16 at 20:25
  • @noelc and karfus: This isn't a bug we understand the root cause of yet. We'd love to investigate this with your help and develop a fix. Can you please file a http://connect.microsoft.com/VisualStudio bug or send Feedback using the button on your Visual Studio title bar so we can collect some additional information? (MSFT employee) – Andrew Arnott Apr 21 '16 at 05:04
  • 1
    So Visual Studio hasn't been running all day, I login into my Win10 and this exe is running using up 15 GB of mem of my 16 total, slowing down the system to a crawl until I can finally kill it in Task Manager, which is rendering so slowly because the system is exhausted, seems like a poorly executed way to do this. – Paully Apr 28 '16 at 07:00
  • 1
    Just provide us a way to turn it off to where we don't have to rescind Execute permissions, Andrew. – NoelC Apr 29 '16 at 15:07
  • Oh the irony of crushes last answer @Anson... My throttled down CPU usage was too high so I decided it was broken and turned off throttling (power save mode). Bad microsoft... BAD /sarcasm – JimR Jun 17 '16 at 16:53
  • 1
    I've also seen VsHub64 consume over 8GB of RAM... but I haven't seen anyone mention the amount of trash left behind by these processes in the `%appdata%\..\Local\Temp` folder. Today I deleted almost 70GB of "Reports" that were created by the VsHub services. – xfx Jun 22 '16 at 13:10
  • 1
    @xfx - this should have been addressed in Update 2 of VS 2015 (it wouldn't have removed older log files, but it shouldn't grow unbounded any longer). The original idea was that since these logs are only showing exceptions, there shouldn't be a huge number. However, if there is a systemic issue on that machine, then we found this started to be a problem. Regardless, please let me know if you have the problem after installing the update. – Anson Horton Jun 23 '16 at 16:16
  • I've just had to delete this folder because this malwaresque process froze Visual Studio completely. – udog Jun 23 '16 at 21:31
  • 2
    @AnsonHorton Just updated to Update 3 and the same behavior persists. I have an application that should run 24/365 so I'm leaving VS running the app overnight. Unfortunately, I haven't been able to debug it for more than 36 hours because the VS VsHub64 ends consuming all available RAM thus crashing the whole system. Also, a little over 24 hours of debugging produces over 15GB of "stuff" in the Temp folder. – xfx Jul 04 '16 at 10:32
  • @xfx - please click 'report a problem' in VS, and if possible, include your email address so we can investigate. The "stuff" in your temp folder - it's all under VShub\logs? Opening one of those logs should help us figure out what's going on, since only errors should be going there. In terms of the memory growth of the debugging service, I'll loop in the right folks if you can submit a feedback item. – Anson Horton Jul 05 '16 at 17:03
  • 1
    @AndrewArnott https://connect.microsoft.com/VisualStudio/feedback/details/1610160/microsoft-vshub-server-httphostx64-exe Can you please investigate with the above bug? Does MS simple close bugs without fixing them? Seems most of them, including myself has the same problem with VS 2015 Update 3. As NoelC suggested, please provide a way to switch VSHub service off until you fix it. – Sen Jacob Oct 25 '16 at 06:25
  • this helped me http://stackoverflow.com/questions/33837163/visual-studio-2015-vshub-is-spamming-fiddler/33928841#33928841 – Niloofar Dec 30 '16 at 14:29
  • 1
    Wtf - vshub takes up over 20GB of memory and 80GB ETL files on my SSD. :( – MojoDK Jan 19 '17 at 19:43
  • lovely as usual; from redmond with love –  Feb 09 '19 at 23:57
81

Something no one's mentioned above...

According to my firewall log, VsHub.exe, Microsoft.VsHub.Server.HttpHost.exe, and Microsoft.VsHub.Server.HttpHostx64.exe all try to communicate online.

Addresses I saw to which there were outgoing connection attempts included 191.236.194.164 (Microsoft Azure, Wichita Kansas) and 23.102.160.172 (Microsoft Azure, Redmond Washington).

I realize "modern" software is supposed to be cloud-integrated, but...

As one who does not require anything from Microsoft Azure servers, and who is legitimately concerned with privacy and not leaking any part of what I'm working on to the outside world, I'd really like A) to have a way to choose not to run these programs, or B) be provided with settings to limit their chattiness online. Yes, the firewall blocks the connections, but that's a last resort.

Just a simple checkbox, "[ ] Contact Microsoft Azure Servers" would be nice. Whether that would mean not running the programs in question or just having them not make the online connections isn't of consequence to me. I guess from a resource perspective the former would be better as it would use fewer resources.

As a rule I wouldn't propose to change the files in an installed application's suite of files, but as I have a virtual machine environment within which I can test changes to Visual Studio 2015 without much consequence (snapshots are wonderful), I tried altering the permissions (to remove inheritance then disallow Read and Execute for Users) on these three files.

Voila, no more VsHub applications running, trying to contact remote systems.

Visual Studio comes right up. I'm not seeing a downside here.

-Noel

NoelC
  • 1,407
  • 10
  • 16
  • Downside: You yourself cannot modify these files any more. – harrymc Apr 05 '16 at 09:19
  • Not sure what you mean, harrymc. Can you please be more specific? Are you speaking of problems accessing the permissions? As an administrator you are still master over every file on your computer, though Microsoft throws monkey wrenches in the way sometimes. But if you understand how permissions works you can do anything you want. The files are on YOUR computer after all. If you mean that you've removed your own permissions, I worded it badly. I meant that I REMOVED permissions, not added a Deny setting. I should have used the word "Disallow". – NoelC Apr 06 '16 at 20:41
  • Once deny is set, to re-access the permissions one has to first set himself as owner of the files. – harrymc Apr 07 '16 at 05:15
  • Right. DO NOT check a box in the "Deny" column. Rather, UNCHECK "Read & execute" under the Allow column. – NoelC Jun 04 '16 at 16:18
  • 2
    Based on my post-Update 3 experience, just changing the permissions on vshub.exe to remove execute access appears to be enough. – NoelC Jul 14 '16 at 16:39
62

I am using Windows 7 x64 with Visual Studio Express 2015. I have terminated annoying processes with Task Manager. Then I have deleted the C:\Program Files (x86)\Common Files\microsoft shared\VsHub folder. This operation solves the problem, but requires administrator rights.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
xakepp35
  • 2,878
  • 7
  • 26
  • 54
  • Can anyone approve this? too scared to try – Reda Lahdili Aug 17 '15 at 10:08
  • 38
    Upvote from me, because the DevTools Team really needs to stop running all this annoying bullshit in the background all the time. Also following the advice to delete the VsHub folder because MS won't give me a clean way to uninstall this crap. – jerhewet Aug 26 '15 at 18:25
  • 2
    This worked for me, I deleted that folder and VsHub doesn't run in the task manager anymore. Though I won't flag this as solution for this question, I'm sure there is a cleaner way to disable VsHub. – Reda Lahdili Aug 30 '15 at 05:26
  • 18
    I've found more loyal solution. Rename **VsHub** folder to **_VsHub**, instead of deleting. This has an advantage of rolling back, if you're really scared :) – xakepp35 Sep 02 '15 at 18:12
  • 2
    Beware, removing / renaming the folder will cause any dependent tools to fail. One such example is the diagnostic tools that run while debugging. – BStruthers Sep 03 '15 at 20:53
  • 1
    I haven't experienced any problems with debugging after renaming. Which tool fails? – xakepp35 Sep 04 '15 at 22:20
  • 4
    During debugging, the diagnostic tools that show a live view of CPU & memory usage of the process being don't work. – Frederik Sep 12 '15 at 18:41
  • Be very careful with this option I tried it but I cannot run the profiler anymore. I guess I wiil try to reinstall VS because the files are back now and I the profiler is still unlaunchable. – Arnaud Sep 14 '15 at 07:48
  • 4
    I ran into trouble with VsHub and HttpHostx64 when I was trying to alter an old linq to sql designer file in an old project. After opening the designer, VS would lock up and be unresponsive. Procmon showed lots of activity from HttpHostx64.exe. I've renamed the c:\Program Files (x86)\Common Files\Microsoft Shared\VsHub\ folder to "VsHub(bullshit)". My linq-to-sql designer now loads as normal. :) – Nick Nov 04 '15 at 20:57
  • MS VS Professional 2015, Version 14.0.25422.01 Update 3 : I renamed as recommended and some time afterwards I lost "Find": no more search results! (I also forgot the location of the mentioned folder, but that's another story) – Liviu May 10 '17 at 12:09
  • I'm using SQL Management Studio on a production database server and this answer helped me slice 30-40% off SSMS memory usage and tons of garbage traffic. Thanks. – Alex from Jitbit Jun 10 '21 at 14:08
30

As xakepp35 mentioned, you can delete the C:\Program Files (x86)\Common Files\microsoft shared\VsHub folder. However, I suspect that updates or other installers will likely try to re-create it.

What I did was shut down all the VS processes. Take ownership of the folder (as admin) and then RAR (ZIP) up the folder and finally delete it (RAR as a backup if I need the files back). Mine is on an SSD so I want to conserve space. Otherwise you could simply rename it and leave it in place.

Then to prevent it being created again, I used an old Win 3.1 trick. Create a text file named VsHub.txt in the C:\Program Files (x86)\Common Files\microsoft shared folder. Then rename the text file and take off the .txt extension leaving a file named VsHub. Since the OS can't create a folder and a file of the same name in the same location, poof, its inaccessible as a folder to VS and its inaccessible and future installers/updaters as a folder either. Then if you need to allow access again in the future, simply add the .txt back on the file and away you go.

Wolfie
  • 1,801
  • 1
  • 14
  • 16
  • 8
    This proposed solution worked perfectly for me. It eliminated the flood of vshub requests in Fiddler and overall performance of VS is substantially improved. Microsoft, if you are reading: less is more -- bloatware is the worst thing that you can let happen to productivity software. – Shaun Dec 09 '15 at 02:56
  • Just to make sure that nobody gets any wild ideas about removing that file to allow creation of the directory, you can add an ACL to it from the right-click / properties / security tab that does nothing other than deny everyone delete privileges on the file. – dgnuff Jan 19 '16 at 02:25
  • I followed this tip and I got incredible speed pickup. My computer is susceptible to disk queuing which sometimes means Visual Studio splash screen is there for 5 minutes (no exaggeration). Thanks so much for this. – S Meaden Nov 24 '16 at 11:36
22

This seems to be a communication Swiss Army knife for visual studio as per @sraboy's answer. It is used during debugging to display performance information about the running process, but also to send telemetry to Microsoft about the project you're working on. You can build and step through code fine with it disabled (at first glance).

Removing, renaming or blocking the vshub process creation with AV will break the performance tracing I mentioned. Losing vshub improves privacy while using Visual Studio as it communicates with vortex.data.microsoft.com, passing information such as solution & project GUIDs along with your account id. Below is a screenshot from fiddler intercepting the HTTPS data.

Blocking access at network level helps with privacy, but it will not address your resource usage issue. I would consider the latter as a normal overhead of running Visual Studio.

For your use case, you can probably get away with some form of disabling (blocking instantiation with your antivirus software is probably the cleanest approach), but it may support additional functionality I haven't figured out yet.

Data communicated to Microsoft, via vshub

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Frederik
  • 2,921
  • 1
  • 17
  • 26
8

For those of you who want to preserve VSHub and still be able to use Fiddler you can setup a Filter in Fiddler with the following setting:

Request Headers > Hide if URL contains =
REGEX:localhost:\d+\/vshub\/

EDIT - you probably want to add this too:

Hosts > Show only the following Hosts: =
localhost;

in order to omit vortex.data.microsoft.com etc.. requests

vshub filter in Fiddler

Ilan
  • 1,647
  • 1
  • 15
  • 16
4

According to a Microsoft Program Manager commenting on the Visual Studio Blog commenting on the Visual Studio Blog, it's used to support multi-tool communication across the VS suite. Given how complicated Visual Studio is, I wouldn't recommend anything as harsh as xakepp35's answer (deleting it).

On my Win10 x64 with VS2015 running, while debugging, there's three processes and the total RAM usage is less than 150MB total. Unless you're page-thrashing on a machine with minimal RAM that's not much to be concerned about. Given that you're running VS2015, I'd guess you have 150MB to spare.

Until or unless you find documentation showing explicitly what the Hub is supporting, I'd recommend leaving it be. In my experience, Visual Studio installs are far too easy to break.

sraboy
  • 903
  • 2
  • 13
  • 26
  • 3
    On my machine after a day of work this program take 580MB. Even after I closed VS2015, This program does not stop. I thinks this is quite a lot of RAM for a program that supports features (cloud, udpates) I don't use. – 0xBADF00D Oct 08 '15 at 16:16
  • This also seems to be dependent on the size of your solution as well. – Ed DeGagne May 13 '16 at 15:00
  • 1
    Well, the problem is that it just grows unbounded. I only installed 2015 yesterday and this morning had a 7GB mystery to investigate. Just silly. Disabled diagnostic tools. – Nick Westgate Oct 12 '16 at 22:32
3

One of the reasons why Visual Studio tries to connect online seems also that, by default, search online for updates for both Visual Studio and its extensions.

Also, Visual Studio includes a version of Internet Explorer within its core so that webpage (and extension) can be downloaded live. In other words, it acts as a browser as well and as we all know... Microsoft is pretty keen on checking its users' data and usage of its software.

There are plenty of online functions in the menu ToolsOptions. (To be honest, I do prefer MonoDevelop even with its flaws.)

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
user3345048
  • 361
  • 3
  • 3
2

It's needed for BrowserLink, the Diagnostics window, Intellitrace.

I sometimes need these features, but only have 8 GB of RAM. I'm usually at 90-95% usage so I created a batch file to toggle VSHub on and off by renaming the folder and creating a symlink to an empty folder with dummy files.

Shutdown Visual Studio before running.

@echo off
goto CheckVsHubRunning

:KillVsHub
    echo Killing VsHub Process
    taskkill /IM VsHub.exe /T /F
    TIMEOUT /T 3 /NOBREAK
:CheckVsHubRunning
    ver > nul
    tasklist /FI "IMAGENAME eq VsHub.exe" | find /I /N "VsHub.exe"
    if "%ERRORLEVEL%"=="0" goto KillVsHub
    if "%ERRORLEVEL%"=="1" echo VsHub is not running.
    echo.

PUSHD "C:\Program Files (x86)\Common Files\microsoft shared"
    IF NOT EXIST "VsHub.original" (
        echo Renaming Original VsHub folder.
        RENAME "VsHub" "VsHub.original"
    )
    IF NOT EXIST "VsHub.dummy" (
        echo Creating Dummy Folder and Contents
        mkdir       "VsHub.dummy"
        copy NUL >  "VsHub.dummy\1.0.0.0"
        copy NUL >  "VsHub.dummy\ServiceModules"
        mkdir       "VsHub.dummy\dummy"
    )

    IF EXIST "VsHub\dummy" (
        echo ENABLING VsHub
        echo.
        rmdir       VsHub
        mklink /d   VsHub   VsHub.original

    ) ELSE (
        echo DISABLING VsHub
        echo.
        rmdir       VsHub
        mklink /d   VsHub   VsHub.dummy
    )
echo.
pause

On my machine VSHub and its cronies usually use:

  • VsHub.exe: 50 MB initially. 250-350 MB after 2+ hrs
  • Microsoft.VsHub.Server.HttpHost.exe: 200 MB initially. 350+MB after 1+ hrs
  • Microsoft.VsHub.Server.HttpHostx64.exe: 320 MB initially. 550+MB after 1+ hrs

This frees up over a 1 GB of RAM with hardly any functionality lost.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Derek Ziemba
  • 2,467
  • 22
  • 22
0

"VsHub" should be renamed to "SmartMobileCloud"; that's how stupidTrendy it is. I dumped it; my VisualC editing/debugging wasn't harmed.

After installing VisualStudio, remove unUsed extensions, do the "C:\Program Files (x86)\Common Files\Microsoft Shared\ - Deleted - VsHub" fix... and put a "VsHub" text file there ( no ".TXT" ), so nothing can recreate the folder.

Jeff Relf
  • 55
  • 3