How do I disable VsHub.exe in the system tray?

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.

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.

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

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.

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.

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.