Timeline for How do I disable VsHub.exe in the system tray?
Current License: CC BY-SA 3.0
38 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 9, 2019 at 23:57 | comment | added | user9826550 | lovely as usual; from redmond with love | |
| Jan 19, 2017 at 19:43 | comment | added | MojoDK | Wtf - vshub takes up over 20GB of memory and 80GB ETL files on my SSD. :( | |
| Dec 30, 2016 at 14:29 | comment | added | Niloofar | this helped me stackoverflow.com/questions/33837163/… | |
| Oct 25, 2016 at 6:25 | comment | added | Sen Jacob | @AndrewArnott connect.microsoft.com/VisualStudio/feedback/details/1610160/… 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. | |
| Jul 5, 2016 at 17:03 | comment | added | Anson Horton | @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. | |
| Jul 4, 2016 at 10:32 | comment | added | xfx | @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. | |
| Jun 23, 2016 at 21:31 | comment | added | udog | I've just had to delete this folder because this malwaresque process froze Visual Studio completely. | |
| Jun 23, 2016 at 16:16 | comment | added | Anson Horton | @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. | |
| Jun 22, 2016 at 13:10 | comment | added | xfx |
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.
|
|
| Jun 17, 2016 at 16:53 | comment | added | JimR | 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 | |
| Apr 29, 2016 at 15:07 | comment | added | NoelC | Just provide us a way to turn it off to where we don't have to rescind Execute permissions, Andrew. | |
| Apr 28, 2016 at 7:00 | comment | added | Paully | 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. | |
| Apr 21, 2016 at 5:04 | comment | added | Andrew Arnott | @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 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) | |
| Apr 20, 2016 at 20:25 | comment | added | karfus | 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. | |
| Apr 19, 2016 at 14:06 | comment | added | NoelC | 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! | |
| Apr 15, 2016 at 21:52 | comment | added | Anson Horton | @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. | |
| Apr 14, 2016 at 16:40 | comment | added | Adrian | 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? | |
| Mar 18, 2016 at 8:39 | comment | added | chosenbreed37 | @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. | |
| Jan 21, 2016 at 16:11 | comment | added | Anson Horton | @Đonny - stackoverflow.com/questions/33837163/… | |
| Jan 21, 2016 at 16:10 | comment | added | Anson Horton | @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. | |
| Jan 20, 2016 at 1:16 | comment | added | Sjoerd | 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. | |
| Jan 8, 2016 at 15:18 | comment | added | Đonny | 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. | |
| Dec 13, 2015 at 23:40 | comment | added | Anson Horton | @Shaun - Check out stackoverflow.com/questions/33837163/… | |
| Dec 11, 2015 at 22:11 | comment | added | Justin_H | @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. | |
| Dec 9, 2015 at 2:43 | comment | added | Shaun | @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... | |
| Nov 20, 2015 at 20:00 | comment | added | crush | @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. | |
| Nov 20, 2015 at 17:52 | comment | added | Anson Horton | @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). | |
| Nov 19, 2015 at 0:09 | comment | added | crush | 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. | |
| Nov 16, 2015 at 8:01 | history | edited | Codler | CC BY-SA 3.0 |
Highlight actions
|
| Nov 15, 2015 at 15:09 | comment | added | Roman Starkov | Resource-wise, these processes are relatively light unless diagnostics tools are enabled, 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. | |
| Nov 4, 2015 at 2:51 | comment | added | Anson Horton | @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. | |
| Nov 1, 2015 at 23:04 | comment | added | sh1rts | Here is Microsoft.VsHub.Server.HttpHost64.exe being "lithe" on my machine - imgur.com/DKvSNqf - that's 1GB of RAM it peaked out at. Nice. | |
| Oct 19, 2015 at 20:42 | comment | added | Mario | Thanks @Anson. I submitted here: connect.microsoft.com/VisualStudio/feedback/details/1919828/… Unfortunately I don't see any logs in %temp%\VsHub (VsHub folder doesn't exist %temp%) | |
| Oct 18, 2015 at 6:26 | comment | added | Anson Horton | @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 | |
| Oct 16, 2015 at 15:41 | comment | added | Mario | 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... | |
| Oct 15, 2015 at 16:43 | review | Late answers | |||
| Oct 15, 2015 at 16:46 | |||||
| Oct 15, 2015 at 16:29 | review | First posts | |||
| Oct 15, 2015 at 16:36 | |||||
| Oct 15, 2015 at 16:25 | history | answered | Anson Horton | CC BY-SA 3.0 |