Dans VS2015, il y avait diverses choses en arrière-plan, comme "VsHub", etc. Il se connectait aux serveurs MS, et peut-être des fuites. Donc l'approche courante consistait à supprimer ces fichiers.
Dans VS2017, il y a encore plus de choses étranges en arrière-plan. Cependant, j'ai lu qu'il exécute plus de choses hors processus, donc la supprimer peut ne pas être possible.
J'ai en cours d'exécution:
... et j'ai vu d'autres choses apparaître et sortir de mon gestionnaire de tâches.
Je ne me soucie pas de l'utilisation des ressources/mémoire, comme d'autres se sont plaints. Dans notre cas, c'est une question de confidentialité/sécurité - nous ne nous connectons à aucun service en ligne de notre IDE, et nous prenons la confidentialité TRÈS au sérieux. Notre code est notre produit et notre moyen de subsistance, donc laisser l'outillage communiquer avec d'autres serveurs, pour qui sait quelle raison, est carrément idiot. Nous ne voulons pas que VS communique avec un service extérieur, jamais .
Certains d'entre vous suppriment-ils ces fichiers comme auparavant? Cela pose-t-il des problèmes? Quelque chose dans VS cesse de fonctionner?
J'utilise l'édition gratuite de Glasswire * ( https://www.glasswire.com/ ) pour surveiller le trafic réseau sortant. La version gratuite n'est pas idéale à 100% car elle ne signale que les connexions à mesure qu'elles se produisent, où la version payante a une option "demander d'abord", mais coûte 50 $ par pc! Si vous voulez dépenser de l'argent pour acheter la version complète, il dispose de quelques outils de pare-feu pour bloquer préventivement le trafic sortant, ce qui pourrait être suffisant pour vous donner la tranquillité d'esprit que VS n'envoie pas de données vers l'inconnu.
Aujourd'hui, il a intercepté VS (d:\program files (x86)\Microsoft visual studio\2017\community\common7\servicehub\hosts\servicehub.Host.clr.x86\servicehub.Host.clr.x86.exe
) initiant le trafic vers cs9.wpc.v0cdn.net
(v0cdn.net semble être enregistré par Verizon lors d'une recherche de bureau d'enregistrement https://www.whois.com/whois/v0cdn.net ) IP: 93.184.221.200
La meilleure solution que j'ai pu trouver était d'ajouter des entrées de fichier d'hôtes pour bloquer la communication et les rapports de télémétrie. (accordé, ce n'est pas une solution permanente)
Voici une liste que j'ai compilée à partir de divers blogs - examinez-la ligne par ligne pour votre propre usage car des choses comme skype et les mises à jour de Windows peuvent cesser de fonctionner en raison des blocs de fichiers hôtes.
# W10
0.0.0.0 cs1.wpc.v0cdn.net
0.0.0.0 df.telemetry.Microsoft.com
0.0.0.0 i1.services.social.Microsoft.com
0.0.0.0 i1.services.social.Microsoft.com.nsatc.net
0.0.0.0 oca.telemetry.Microsoft.com
0.0.0.0 oca.telemetry.Microsoft.com.nsatc.net
0.0.0.0 pre.footprintpredict.com
0.0.0.0 reports.wes.df.telemetry.Microsoft.com
0.0.0.0 sqm.telemetry.Microsoft.com
0.0.0.0 sqm.telemetry.Microsoft.com.nsatc.net
0.0.0.0 statsfe1.ws.Microsoft.com
0.0.0.0 telecommand.telemetry.Microsoft.com
0.0.0.0 telecommand.telemetry.Microsoft.com.nsatc.net
0.0.0.0 telemetry.appex.bing.net
0.0.0.0 telemetry.urs.Microsoft.com
0.0.0.0 vortex-sandbox.data.Microsoft.com
0.0.0.0 vortex-win.data.Microsoft.com
0.0.0.0 vortex.data.Microsoft.com
# http://www.dslreports.com/forum/r30676597-Complete-Win10-blocking-Host-file
#0.0.0.0 fe2.update.Microsoft.com.akadns.net
#0.0.0.0 sls.update.Microsoft.com.akadns.net
0.0.0.0 134.170.30.202
0.0.0.0 137.116.81.24
0.0.0.0 204.79.197.200
0.0.0.0 23.218.212.69
0.0.0.0 65.39.117.230
0.0.0.0 65.55.108.23
0.0.0.0 a-0001.a-msedge.net
0.0.0.0 a-0002.a-msedge.net
0.0.0.0 a-0003.a-msedge.net
0.0.0.0 a-0004.a-msedge.net
0.0.0.0 a-0005.a-msedge.net
0.0.0.0 a-0006.a-msedge.net
0.0.0.0 a-0007.a-msedge.net
0.0.0.0 a-0008.a-msedge.net
0.0.0.0 a-0009.a-msedge.net
0.0.0.0 a-msedge.net
0.0.0.0 a.ads1.msn.com
0.0.0.0 a.ads2.msads.net
0.0.0.0 a.ads2.msn.com
0.0.0.0 a.rad.msn.com
0.0.0.0 ac3.msn.com
0.0.0.0 ad.doubleclick.net
0.0.0.0 adnexus.net
0.0.0.0 adnxs.com
0.0.0.0 ads.msn.com
0.0.0.0 ads1.msads.net
0.0.0.0 ads1.msn.com
0.0.0.0 aidps.atdmt.com
0.0.0.0 aka-cdn-ns.adtech.de
0.0.0.0 apps.skype.com
0.0.0.0 arc.msn.com
0.0.0.0 az361816.vo.msecnd.net
0.0.0.0 az512334.vo.msecnd.net
0.0.0.0 b.ads1.msn.com
0.0.0.0 b.ads2.msads.net
0.0.0.0 b.rad.msn.com
0.0.0.0 bingads.Microsoft.com
0.0.0.0 bs.serving-sys.com
0.0.0.0 c.atdmt.com
0.0.0.0 c.msn.com
0.0.0.0 cdn.atdmt.com
0.0.0.0 cds26.ams9.msecn.net
0.0.0.0 choice.Microsoft.com
0.0.0.0 choice.Microsoft.com.nsatc.net
0.0.0.0 compatexchange.cloudapp.net
0.0.0.0 corp.sts.Microsoft.com
0.0.0.0 corpext.msitadfs.glbdns2.Microsoft.com
0.0.0.0 db3aqu.atdmt.com
0.0.0.0 df.telemetry.Microsoft.com
0.0.0.0 diagnostics.support.Microsoft.com
0.0.0.0 ec.atdmt.com
0.0.0.0 Edge.quantserve.com
0.0.0.0 fe2.update.Microsoft.com.akadns.net
0.0.0.0 feedback.Microsoft-hohm.com
0.0.0.0 feedback.search.Microsoft.com
0.0.0.0 feedback.windows.com
0.0.0.0 flex.msn.com
0.0.0.0 fpt.live-partner.com
0.0.0.0 g.msn.com
0.0.0.0 h1.msn.com
0.0.0.0 i1.services.social.Microsoft.com
0.0.0.0 i1.services.social.Microsoft.com.nsatc.net
0.0.0.0 lb1.www.ms.akadns.net
0.0.0.0 live.rads.msn.com
0.0.0.0 m.adnxs.com
0.0.0.0 m.hotmail.com
0.0.0.0 msedge.net
0.0.0.0 msftncsi.com
0.0.0.0 msnbot-65-55-108-23.search.msn.com
0.0.0.0 msntest.serving-sys.com
0.0.0.0 oca.telemetry.Microsoft.com
0.0.0.0 oca.telemetry.Microsoft.com.nsatc.net
0.0.0.0 onesettings-bn2.metron.live.com.nsatc.net
0.0.0.0 onesettings-cy2.metron.live.com.nsatc.net
0.0.0.0 onesettings-db5.metron.live.com.nsatc.net
0.0.0.0 onesettings-hk2.metron.live.com.nsatc.net
0.0.0.0 pre.footprintpredict.com
0.0.0.0 preview.msn.com
0.0.0.0 pricelist.skype.com
0.0.0.0 rad.live.com
0.0.0.0 rad.msn.com
0.0.0.0 redir.metaservices.Microsoft.com
0.0.0.0 reports.wes.df.telemetry.Microsoft.com
0.0.0.0 rpt.msn.com
0.0.0.0 s.gateway.messenger.live.com
0.0.0.0 s0.2mdn.net
0.0.0.0 sO.2mdn.net
0.0.0.0 schemas.Microsoft.akadns.net
0.0.0.0 secure.adnxs.com
0.0.0.0 secure.flashtalking.com
0.0.0.0 services.wes.df.telemetry.Microsoft.com
0.0.0.0 settings-sandbox.data.Microsoft.com
0.0.0.0 settings-win.data.Microsoft.com
0.0.0.0 settings.data.glbdns2.Microsoft.com
0.0.0.0 sls.update.Microsoft.com.akadns.net
0.0.0.0 sqm.df.telemetry.Microsoft.com
0.0.0.0 sqm.telemetry.Microsoft.com
0.0.0.0 sqm.telemetry.Microsoft.com.nsatc.net
0.0.0.0 ssw.live.com
0.0.0.0 static.2mdn.net
0.0.0.0 statsfe1.ws.Microsoft.com
0.0.0.0 statsfe2.update.Microsoft.com.akadns.net
0.0.0.0 statsfe2.ws.Microsoft.com
0.0.0.0 survey.watson.Microsoft.com
0.0.0.0 telecommand.telemetry.Microsoft.com
0.0.0.0 telecommand.telemetry.Microsoft.com.nsatc.net
0.0.0.0 telecommand.telemetry.Microsoft.com.nsatc.net
0.0.0.0 telemetry.appex.bing.net
0.0.0.0 telemetry.appex.bing.net:443
0.0.0.0 telemetry.Microsoft.com
0.0.0.0 telemetry.urs.Microsoft.com
0.0.0.0 ui.skype.com
0.0.0.0 v10.vortex-win.data.metron.live.com.nsatc.net
0.0.0.0 v10.vortex-win.data.Microsoft.com
0.0.0.0 view.atdmt.com
0.0.0.0 vortex-bn2.metron.live.com.nsatc.net
0.0.0.0 vortex-cy2.metron.live.com.nsatc.net
0.0.0.0 vortex-db5.metron.live.com.nsatc.net
0.0.0.0 vortex-hk2.metron.live.com.nsatc.net
0.0.0.0 vortex-sandbox.data.Microsoft.com
0.0.0.0 vortex-win.data.metron.live.com.nsatc.net
0.0.0.0 vortex-win.data.Microsoft.com
0.0.0.0 vortex.data.glbdns2.Microsoft.com
0.0.0.0 vortex.data.metron.live.com.nsatc.net
0.0.0.0 vortex.data.Microsoft.com
0.0.0.0 watson.live.com
0.0.0.0 watson.Microsoft.com
0.0.0.0 watson.ppe.telemetry.Microsoft.com
0.0.0.0 watson.telemetry.Microsoft.com
0.0.0.0 watson.telemetry.Microsoft.com.nsatc.net
0.0.0.0 wes.df.telemetry.Microsoft.com
0.0.0.0 wes.df.telemetry.Microsoft.comne
J'ai désactivé CodeLens et il est immédiatement tombé à 0%.
Dans VS: Tools-> Options: TextEditor-> AllLanguages-> CodeLens
Décochez Activer CodeLens
Si vous ne voulez pas le désactiver complètement, vous pouvez essayer de tourner différentes choses. Des choses liées à TFS comme les changements entrants expliqueraient l'activité du réseau comme souligné précédemment.
Je suis tombé sur cette question en cherchant moi-même une solution similaire. Dans mon cas ServiceHub.Host.CLR.x86.exe
seul consommait ~ 50% de CPU même lorsque Visual Studio n'exécutait rien.
J'ai pu tuer le processus sans aucun effet secondaire, à mi-parcours d'un projet aussi, et j'ai été heureux de constater qu'il ne s'est pas remis en place. ServiceHub.IdentityHost.exe
m'a semblé imperméable en essayant de mettre fin au processus, mais il ne consommait aucun processeur.
Les autres processus énumérés ci-dessus ne consommaient pas non plus beaucoup de CPU (~ 0%), donc je les laisse faire.
Tl; dr: Cela peut dépendre de ce que vous exécutez sur Visual Studio (j'exécutais un projet C #), mais ServiceHub.Host.CLR.x86.exe
peut être tué sans aucun effet secondaire.