visual tools studio remote remotas remota proceso para net herramientas depuracion debugger debug asp asociar application c# .net debugging visual-studio-debugging visual-studio-2015

c# - tools - remote debugger visual studio 2017 download



Visual Studio 2015 RTM: la depuración no funciona (25)

He instalado VS 2015 RTM (nada más) y no puedo depurar ninguna solución, no importa si es una existente o una nueva (creada con VS 2015 y compilada con .Net Framework 4.6), solo abre un nueva pestaña en VS que se llama Modo de interrupción con el siguiente texto: La aplicación está en modo de interrupción Su aplicación ha entrado en un estado de interrupción, pero no se está ejecutando ningún código que sea compatible con el motor de depuración seleccionado (por ejemplo, solo se está ejecutando el código de tiempo de ejecución nativo ) Y si verifico la ventana de depuración -> Módulo: VS2015Test.vshost.exe no hay símbolos cargados (incluso si hago clic en cargar símbolo no funciona) Símbolos VS2015Test.exe cargados

Y tampoco muestra el resultado en la consola (es una aplicación de consola que solo tiene las siguientes líneas de código:

class Program { static void Main(string[] args) { Console.WriteLine("TEST"); Console.ReadKey(); } }

Traté de reinstalar VS 2015, reinicié la computadora, eliminé todos los archivos en% temp% / AppData / Microsoft / Visual Studio / 14, comencé VS en modo administrador pero nada parece funcionar.

Una cosa que hace que la depuración funcione es esta opción: Herramientas -> Opciones -> Depuración -> Usar modo de compatibilidad administrada

^^ Pero esa no puede ser la solución para usar un modo antiguo / heredado.

Por cierto: la depuración en VS 2013 está funcionando bien.

Cualquier ayuda sería apreciada.


  1. Deja de depurar.
  2. Editar archivo csproj.user
  3. Encuentra la sección escrita a continuación:

    <SilverlightDebugging> Verdadero </SilverlightDebugging>

  4. Cambiar valor a "falso"
  5. Descargue y vuelva a cargar su proyecto en Visual Studio.
  6. A veces era necesario cerrar Visual Studio.

Cambié mi Target Platform de "Cualquier CPU" a "x64".

Configuración disponible en: Propiedades del proyecto -> Compilación -> General: "Objetivo de plataforma"

Yo uso VS 2015.


Descubrí que tenía que ir a la configuración del proyecto -> web y marcar la casilla de verificación Activar Editar y Continuar. Para empezar, no puedo decir por qué no estaba marcada, pero esto me resolvió.


Deshabilité el escudo del sistema de archivos avast y luego todo volvió a funcionar normalmente. rueda de ajuste de avast = protecciones activas- botón superior apagado.

Lo mismo se requiere para publicar proyectos. Una verdadera pesadilla


Después de la instalación de vs 2017, al depurar la solución, se produjo un error como "Webkit dejó de funcionar correctamente; Visual Studio ya no podrá depurar su aplicación". , esto hace que no se pueda continuar con la depuración. Para resolver este problema, vaya a Herramientas-> Opciones-> Depuración-> General y luego desactive la depuración de JavaScript para asp.net


En mi caso se debió al proyecto. Las plataformas Target eran diferentes.

Considere : Proyecto A (Entrada) -> Proyecto B

La plataforma de ProjectA en propiedades se estableció en x64 . Y la plataforma de ProjectB era '' AnyCPU ''.

Entonces, después de configurar la plataforma de destino de ProjectB en x64, este problema se solucionó.

Nota: Es solo que Target Platform debe estar sincronizada, ya sea x64 o '' Cualquier CPU ''


En mi caso,

He cambiado la plataforma de x86 a x64 en Debug Configuration Manager. A mi me funciono.


En mi caso, encontré una pista en la ventana de salida de que la excepción que detuvo el depurador fue una excepción ContextSwitchDeadlock, que se verifica de manera predeterminada en la Configuración de excepciones. Esta excepción generalmente ocurre después de 60 segundos en las aplicaciones de consola. Acabo de desmarcar la excepción y todo funcionó bien.


En mi caso, esta solución es útil:

Solución: deshabilite la opción "Solo mi código" en la configuración de Depuración / General.

Referencia: c-sharpcorner


Estaba teniendo este mismo problema con VS2015. Restablecí la configuración, como sugerí, pero aún tuve problemas.

Lo que tuve que hacer para solucionarlo fue marcar "Usar modo de compatibilidad administrado" y "Usar modo de compatibilidad nativo". No estoy seguro de cuál de esos 2 es necesario, pero verifico ambos y ya no tengo el problema del modo de interrupción.


He tenido problemas similares en mi aplicación svc ejecutada en Visual Studio 2015, la solución fue cambiar la plataforma de la solución de "Cualquier CPU" a "x86", si no puede ver la opción x86, haga clic en "Configuration Manager" y vaya a su proyecto de destino y cambiar la plataforma, deberá seleccionar el menú desplegable y hacer clic en "Nuevo", en la ventana emergente, hacer clic en la lista desplegable debajo de "nueva plataforma" y seleccionar x86, guardar los cambios y reconstruir (ver adjunto )


Me metí en este problema también. Estoy usando VS 2015 (Actualización 3) en Windows 10 y estaba tratando de depurar una aplicación de formularios Windows Forms. Ninguna de las sugerencias funcionó para mí. En mi caso tuve que deshabilitar IntelliTrace:

Herramientas> Opciones> IntelliTrace

No sé por qué, pero funcionó. Descubrí la raíz del problema cuando abrí el Monitor de recursos (desde el Administrador de tareas de Windows) y me di cuenta de que el proceso IntelliTrace estaba leyendo toneladas de datos. Sospecho que esto estaba causando bloqueos en el proceso vshost, porque este estaba consumiendo el 100% de un núcleo de CPU.


Mi solución de repente dejó de funcionar en la depuración. Recibí un mensaje durante la depuración.

[Título de la ventana] Microsoft Visual Studio [Instrucción principal] Está depurando una versión de lanzamiento de NettoProWin.exe. El uso de Just My Code con versiones de lanzamiento que utilizan optimizaciones del compilador da como resultado una experiencia de depuración degradada (por ejemplo, no se alcanzarán puntos de interrupción). [Detener depuración] [Desactivar solo mi código y continuar] [Continuar depuración] [Continuar depuración (no preguntar de nuevo)]

Elegí continuar depurando, pero aún así no funcionó.

La solución fue simple. Es necesario en las propiedades del proyecto -> en la sección de construcción -> remoto, marque la casilla "Código Optimiz"


Pensé en publicar esto en caso de que ayude a alguien. Instalé un Win 10 limpio y Visual Studio 2015, intenté depurar una solución existente y tuve problemas. Seguí algunos consejos enumerados aquí y en otros lugares, pero ninguno funcionó.

Cómo conseguí que la depuración funcionara normalmente fue cambiar la configuración de la solución justo debajo de los menús. Lo configuré previamente en modo Release, cambié esto a Debug y luego lo limpié / volví a compilar y listo, la depuración comenzó a funcionar normalmente. Vea la imagen para más información:


Tengo el mismo problema. Después de probar las otras soluciones aquí sin suerte, tuve que reparar la instalación a través del instalador.

Panel de control> Programas> Programas y características

Luego desplácese hacia abajo hasta Microsoft Visual Studio, haga clic con el botón derecho y luego "Cambiar". Luego, en la parte inferior de la ventana, haga clic en Reparar. El proceso de reparación tomará una cantidad de tiempo decente, y al final tendrá que reiniciar su computadora.

Esto me solucionó el problema y espero que te ayude.


Tuve el mismo problema. En mi caso, el dll que estaba tratando de depurar se instaló en el GAC. Si su punto de interrupción de depuración se produce cuando no hace referencia a ningún objeto en el ensamblado de destino, pero no cuando hace referencia al ensamblaje, este puede ser el caso para usted.


Tuve este problema después de la desinstalación de la versión de prueba de RemObjects Elements 8.3. Reinstalar Elements 8.3 es una corrección rápida de errores.


Tuve este problema, y ​​ninguna de las (innumerables) publicaciones aquí ayudó. La mayoría de las personas apuntan a configuraciones u opciones, activar el modo de depuración, etc. Todo esto ya lo había implementado (sabía que no era así, ya que ayer funcionaba bien).

Para mí resultó ser un problema de referencia, una combinación de archivos DLL incluidos fueron los culpables. No puedo decir exactamente cuál era el problema, pero tengo un par de clases que extendieron las clases base de otro proyecto, una interfaz implementada que se extiende desde otra interfaz, etc.

La prueba de fuego consistía en crear una nueva clase (en mi caso, una Prueba de unidad) dentro del mismo proyecto que la que no se depura, luego crear un método vacío y establecer un punto de interrupción. Esto funcionó, lo que validó aún más el hecho de que mi configuración / opciones / etc. eran buenas. Luego copié el cuerpo del método que no pudo depurar y, efectivamente, el nuevo método también comienza a fallar.

Al final eliminé todas las referencias y comenté todas las líneas en mi método. Agregándolos nuevamente uno por uno, verificando Debug en cada paso, hasta que encontré al culpable. Obviamente tenía una referencia maliciosa allí en alguna parte ...


Tuve un problema muy similar recientemente, relacionado con la configuración de depuración.

En primer lugar, ¿ha intentado restablecer todas sus configuraciones? Creo que puede estar relacionado con eso, ya que dice que es independiente del proyecto y ha eliminado todos los datos de la aplicación.

Herramientas-> Asistente de configuración de importación y exportación -> Restablecer todas las configuraciones

No se preocupe, le da la opción de guardar la configuración actual.

En segundo lugar, si esto falla, sugeriría mirar el registro de eventos.

Entrar en el modo de interrupción sugeriría que el DE (motor de depuración) está enviando un evento de parada sincronizado a Visual Studio como IDebugExceptionEvent2 . Echaría un vistazo al registro de eventos para ver excepciones como fallas en la carga de ensamblados a los que se hace referencia (como tiempos de ejecución de .NET, etc.) o restricciones de acceso al entorno.

Algo le dice al depurador que detenga su aplicación en ejecución, es solo un caso de encontrarla.


Tuve un problema similar a este al intentar usar Debugger. Inicie para depurar una aplicación web: la ventana de selección de depurador JIT nunca apareció. Sabía que no era un problema con el mecanismo de depuración VS en sí mismo porque se disparó muy bien con una aplicación de consola.

Finalmente, un colega mencionó una "configuración de registro de depurador global" que encendió una bombilla.

Estaba usando DebugDiag de Microsoft hace algunos meses para solucionar problemas de bloqueo de IIS, y tenía una regla registrada para capturar los volcados de bloqueo de IIS, que obviamente (en retrospectiva) registraron el Servicio de diagnóstico de depuración como el depurador para w3wp (proceso de trabajo IIS).

Al eliminar la regla en DebugDiag o al detener el Servicio de diagnóstico de depuración ("C: / Archivos de programa / DebugDiag / DbgSvc.exe") se volvió a habilitar la depuración JIT de Visual Studio.

Espero que esto ayude a alguien.


Tuvimos este problema, después de probar todas las demás opciones, como eliminar la carpeta .vs, cambiar el nombre del nombre de la carpeta IISExpress, actualizar varias configuraciones en las propiedades, etc., no funcionó. Sin embargo, lo que funcionó fue desinstalar IISExpress 10.0 y reinstalarlo junto con activar todas las características relacionadas con IIS desde las características de Windows. Espero que esto ayude a alguien.


Uhg Llegué al final de esta página, así que comencé a destrozar mi proyecto. Encontré una solución para mi problema particular.

Mi problema: no pude alcanzar el punto de ruptura dentro de un proceso roscado. Nada de lujos, solo estoy comenzando un nuevo hilo en una aplicación de consola y el depurador no se detenía en los puntos de interrupción. Noté que el hilo se estaba creando, pero se estaba colgando en llamadas externas de .Net Framework y específicamente en ThreadStart_Context. Eso explica por qué mis puntos de interrupción nunca se vieron afectados porque .Net Framework está colgando algo.

El problema: descubrí que podía resolver esto cambiando mi código de inicio. Por alguna razón, tenía un archivo program.cs que contenía Main () y estaba dentro de la clase Program como esperarías para una aplicación de consola. Dentro de Main (), estaba instanciando otra clase a través de este código;

new SecondClass();

Esto normalmente funciona bien y tengo un montón de otros proyectos con llamadas Threaded donde funciona bien (bueno, no los he depurado durante algún tiempo, por lo que tal vez apareció un service pack y está causando esta regresión).

La solución: mover Main () a mi SecondClass y en lugar de invocar el constructor SecondClass a través de ''new SecondClass ()'', actualizar el constructor SecondClass para que sea un método estático estándar y luego llamarlo desde Main. Después de hacer esos cambios, puedo depurar el hilo una vez más.

Espero que esto ayude.


Un amigo tuvo el mismo problema, no pudo depurar en VS2015 pero estuvo bien en VS2013. (nuestro proyecto está en .Net v4.0)

Hemos encontrado que era la opción "Tipo de código" en Debug / Attach to Process que se configuró en "Managed (v3.5, v3.0, v2.0)" en lugar de "Managed (v4.5, v4.0 ) "


Verifique el "Tipo de código" antes de adjuntarlo a un Proceso. Por ejemplo, tuve que cambiar de CoreCLR a v4. *


desde el Explorador de soluciones -> Web -> Propiedades

seleccione la pestaña Build -> cuadro combinado de configuración:

Simplemente cambie su configuración de "Release" a "Active (Debug)"