201

I have read: How do I disable VsHub.exe in the system tray? and https://connect.microsoft.com/VisualStudio/feedback/details/1919828/hundreds-of-calls-second-to-vshub-and-browserlink-is-off

I would prefer to not disable vshub; I just want it to be more quiet when I am using fiddler. Right now it spams everything else out, and I cannot do general debugging.

Does anybody know a workaround? Can I block vshub from showing up in fiddler without blocking the rest of locahost?

0

8 Answers 8

267

This is a relatively new problem because System.NET used to ignore proxy settings for localhost, and therefore Fiddler wouldn't see the traffic by default (http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/ConfigureDotNETApp) - see bottom section.

Now this no longer appears to be the case, so I expect more people will have the same question. Fiddler supports several ways to filter requests, though nothing that the client can control (which is probably good, since you wouldn't want malware from excluding its traffic). The most appropriate and simplest mechanism in this case is probably to set a filter for any url that contains localhost or vshub. You can do that by:

  1. Click the filters tab (it's a top-level tab, at the same level as inspectors, statistics, etc.),
  2. Check the checkbox labeled 'Use Filters'
  3. Scroll down and find the checkbox labeled 'Hide if URL contains'.
  4. Check that box, and enter either localhost or vshub into the accompanying textbox.
  5. You should see the vshub traffic stop immediately.

This filter will persist, so if you shutdown Fiddler and start it up again later, it will still be set.

6
  • 4
    Thanks, @Anson. Hiding these huge amount of requests will make Fiddler usable again. But this still remains a serious issue, of course. It also makes you wonder why Visual Studio, or any subsequently related process from it, is making these requests in the first place (retorical). If you're inconvenienced by this as well, add a vote on either MS Connect bug #1919828 and/or through ASP.NET MVC issue #3655.
    – Juliën
    Commented Dec 9, 2015 at 11:04
  • 4
    Just to add you can use the || operator in the 'Hide if URL contains' box if you want to hide other requests like browserlink. Commented Jan 5, 2016 at 16:49
  • 4
    @Moriarty re: ...why Visual Studio is making these requests ...well, this is because the processes are communicating with one another through HTTP on the loopback adapter. . This traffic has been generated for "a while" now; it just recently has been changed that it is visible by default to HTTP proxies...so I'm not really sure why you would consider this a bug. Commented Jan 27, 2016 at 19:42
  • 2
    Which is a side effect of new remote debugging tools in Visual Studio 2015, I am pretty sure. Especially related to cross platform debugging for Cordova on Apple devices, I'd further wager. They probably built these changes in a way allowing them to extend it to other platforms later, hence the global change.
    – Bon
    Commented Feb 18, 2016 at 22:08
  • 1
    This isn't the correct solution. It just hides the problem. The solutions below removing diagnostic tools while debugging in VS is the true solution.
    – Rafi
    Commented Dec 5, 2016 at 8:12
132

These requests seem to come from the Diagnostic Tools window which runs when debugging. Seems as though they provide the monitoring information for Memory Usage and CPU Usage.

You can stop the requests if you don't care to see the usage information by disabling Memory/CPU monitoring in the Diagnostic Tools dialog box.

  • Open the Diagnostic Tools window (Debug -> Windows -> Show Diagnostic Tools)
  • Click the "Select Tools" drop-down and un-check Memory Usage and CPU Usage.
  • Stop debugging and next time you start debugging you should no longer see the requests being made to vshub
5
  • 10
    That's the correct solution. It immediately got rid of all the spamming message. Right now I do not care for CPU/Memory, I need my fiddler to stay clean so I can use it properly. So big Thanks to you Alex for this fix. Commented Dec 17, 2015 at 16:40
  • 6
    This will help only once, but you can disable "Diagnostic Tools" in Vusial Studio here: Tools -> Options -> Debugging -> General -> checkbox "Enable Diagnostics Tools while debugging" Commented Jul 25, 2016 at 8:45
  • 1
    I can't seem to find the "Select Tools" drop-down (in Visual Studio 2015). Any idea of where it is? Commented Sep 9, 2016 at 5:56
  • 1
    @PerLundberg If you can't locate "Select Tools" try Brian's answer below (same as Andrey's in these comments). This is now my preferred solution to just keep the Memory/CPU monitoring disabled all the time. If I need it I know how to enable it.
    – Alex
    Commented Nov 4, 2016 at 18:05
  • Note that if you're in a debug session and you do Alex's option, while your Memory/CPU monitoring will stop, the requests will not until you stop and restart your debug session! Found this out the hard way.
    – vapcguy
    Commented Apr 23, 2018 at 21:26
89

For me, the fix to stop "spamming" to Fiddler4, instead of a Fiddler filter, which I could have chosen to do, was to change a Visual Studio 2015 option:

Visual Studio 2015 -> Tools -> Options -> Debugging -> General -> uncheck/disable "Enable Diagnostic Tools while debugging"

enter image description here

VSHUB.exe service must be the service that assists Diagnostic tools while debugging and is continously pinging your website/webapi/web app you are debugging. I do not need debugging. Diagnostic tools at this time so I just disabled it in Visual Studio

In regards to disabling VSHUB.exe, I was tempted to do that, until I read from someone at Microsoft, its best to not disable it for a better Visual Studio 2015 experience and they add new features to Visual Studio that utilize VSHUB.exe over time:

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

2
  • @BrianOgden Phew! Thank you. Finally, a VS 2015 answer. Visual Studio's menus have changed a lot over each releases. All of a sudden this tool -- VsHub -- went wonky, and I don't know why. With Windows 10 automatic updates, it could have been that without my knowing. Commented Feb 24, 2017 at 13:58
  • Note for anyone doing it this way, if you do this while in the middle of a debug session, your requests will not stop being captured in Fiddler until you stop & restart your debug session.
    – vapcguy
    Commented Apr 23, 2018 at 21:31
21

The issue is caused by Visual Studio's Diagnostic Tools while debugging.

You can disable them by going to ToolsOptions, and then following the steps: enter image description here

2
  • Nice graphic. Brian Ogden already beat you to it, though - duplicate answer. Note for anyone doing it this way, if you do this while in the middle of a debug session, your requests will not stop being captured in Fiddler until you stop & restart your debug session.
    – vapcguy
    Commented Apr 23, 2018 at 21:30
  • @vapcguy I gotta admit my answer isn't different but I was the first to post a graphic. Brian edited his answer later to include the graphic. It's fine though, as long as people get their answers.
    – Sergey
    Commented Apr 25, 2018 at 19:50
20

This is an easier alternative to hide the vshub traffic.

Go to Tools > Fiddler Options > Connections tab and add http://localhost:49155 to the bypass list. This will skip all traffic posted to that URL.

*Edit: Fiddler may need to be restarted after adding to the bypass list.

2
  • 2
    This change was applied only after I restarted Fiddler.
    – Bassem
    Commented Jul 13, 2016 at 1:29
  • @Bassem, It also without restarting for mine.
    – Smit Patel
    Commented Dec 3, 2016 at 11:12
9

The easiest way to resolve this is to setup a filter in fiddler. In the OnBeforeResponse, add the second if with your vshub host/port:

  static function OnBeforeResponse(oSession: Session) {
    if (m_Hide304s && oSession.responseCode == 304) {
        oSession["ui-hide"] = "true";
    }

    if (oSession.HostnameIs("localhost:49155")){
        oSession["ui-hide"] = "hiding vshub"; // String value not important
    }


    }
0
2

SpokaneDJ's answer was very helpful for me and worked great, but I don't spend a lot of time with Fiddler so it took me a minute to remember how to do this! Here are the specific instructions.


First, within the Fiddler UI, go to Rules > Customize Rules. Search for the OnBeforeResponse function. It should look like this:

static function OnBeforeResponse(oSession: Session) {
  if (m_Hide304s && oSession.responseCode == 304) {
    oSession["ui-hide"] = "true";
  }
}

Now add the following if block after the existing one (substituting your vshub host/port if different):

    if (oSession.HostnameIs("localhost:49155")){
      oSession["ui-hide"] = "hiding vshub"; // String value not important
    }

Your OnBeforeResponse function should now look like this:

  static function OnBeforeResponse(oSession: Session) {
    if (m_Hide304s && oSession.responseCode == 304) {
        oSession["ui-hide"] = "true";
    }

    if (oSession.HostnameIs("localhost:49155")){
        oSession["ui-hide"] = "hiding vshub"; // String value not important
    }
  }
0

The above didn't work for me, as such. It seemed to shut down ALL fiddler monitoring of the localhost host.

A bit of judicious googling gave me another solution - to block the port specifically by adding this to the bottom of the OnBeforeRequest section:

if (oSession.host=="localhost:49155"){
    oSession["ui-hide"] = "true";
}

This seems to block the port from being reported in Fiddler, without disrupting further localhost traffic.

2
  • 1
    You should mention which answer you're referring to as "the above" since answers here can shift up and down based on multiple factors.
    – Sergey
    Commented Feb 27, 2017 at 19:18
  • Fair point. At the time it applied to all of the other solutions, but it appears more have been added since. I'll bear that in mind in the future. Commented Apr 26, 2017 at 8:29

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