Esta mañana, como todas las demás, me he puesto a picar código y me he dado cuenta de que, cada vez que hacía algo en Visual Studio, éste comenzaba a usar un 30% de CPU y se quedaba ahí un buen rato aunque no estuviera haciendo nada.

Algo muy sospechoso ocurre con Visual Studio 2015, y aquí os voy a contar hasta donde han llegado mis investigaciones.

ACTUALIZACIÓN: El uso de la CPU se debe a ReSharper. Desinstalándolo (ojo si lo deshabilitas sigue pasando) deja de usar esa tremenda cantidad de CPU). Y de hecho, la cantidad de conexiones en el proceso descrito aquí baja sensiblemente, así como el tráfico de datos, al razonable nivel que puede significar la actualización de la configuración y la sincronización entre equipos.

Todo comenzó con la drástica subida de revoluciones del ventilador de mi portátil cada vez que pulsaba un simple “enter” o me desplazaba por el código fuente de mi proyecto. Eso hizo que me diera una vuelta por el Administrador de Tareas y viera cómo Visual Studio disparaba el uso de CPU.

Pero como el Administrador de Tareas es una herramienta muy básica, decidí emplear la increíblemente buena Process Explorer. Ahí vi que dentro del árbol de procesos de Visual Studio, había uno que era el causante de todo el consumo de CPU. Se llama “VsHub.exe” y lo firma Microsoft. Ved la captura.

Veréis cómo la devenv.exe consume el 85% de CPU y el único causante de ello es el programa que os digo. A la derecha os muestro que la aplicación tiene su firma correcta, por lo que no he sufrido ningún tipo de pirateo.

De ahí pasé a buscar por internet, aunque la pestaña de TCP/IP resulta un tanto curiosa. Ved las dos siguientes capturas:

Aparte de conexiones locales, hay algunas que salen al exterior. ¿Al exterior? Sí. Hagamos una colecta de esas IP:

• 68.232.34.200
• 168.62.105.45
• 65.52.55.39
• 65.52.0.51
• 191.232.139.254
• 23.102.160.172 (esta no está en la captura, la pillé antes)

Vemos como la mayoría se conectan por HTTPS, que es el protocolo encriptado de HTTP para que nadie pueda ver qué se envía y como. En principio no se trata de nada extraordinario ya que en la actualidad la mayoría de funcionalidad Web se hace así.

Luego hice un tracert rápido para ver por dónde pasaban esas IP:

Suficiente con tres. Todas pasan a servidores de Microsoft. Como la captura principal, llegan a un punto en el que dejan de responder a los ping y, cosa curiosa, el servidor en cuestión corta toda comunicación con mi Visual Studio.

Tampoco es raro ya que también suele ser lo habitual. Cuando un servidor detecta que le están intentando meter mano, corta y que te den. Solo sospechoso.

Visto lo visto, el siguiente paso es hacer un WHOIS IP, aunque ya tengo claro a quién pertenecen esas IP. En lugar de poner capturas, os dejo que lo miréis vosotros:

• 68.232.34.200
• 168.62.105.45
• 65.52.0.51 y 65.52.55.39
• 23.102.160.172

La mayoría están registradas a Microsoft. La primera de ellas lo está a una empresa que se llama EdgeCast Networks, que es una CDN. Quizás la primera sí que sea válida y pertenezca a una consulta para determinar si tengo actualizaciones o no. Claro, las otras podrían serlo tembién, pero ¿se tiene que comprobar cada vez que hago alguna tarea en Visual Studio?

—

Finalmente una última comprobación, aunque sirva de poco ya que al ser la comunicación por HTTPS, no se puede ver nada de lo que se envía y recibe a través de esas IP:

En fin, que me pregunto qué cojones hace Microsoft enviando cosas y usando mi tiempo de CPU…

(NOTA: todo el problema también podría venir de las últimas dos actualizaciones de Windows 10, las de ayer, porque antes al menos el consumo de CPU no se disparaba -e ignoro si enviaba algo o no-. Ya sabéis, gato escaldado del agua fría huye. Si una reparación de Visual Studio 2015 no resuelve el problema del uso de CPU, otra razón más para volver a Windows 8.1).