La aplicación C# se ejecuta con la depuración, pero no sin

Question

Estoy ejecutando un programa (principalmente) de subproceso único (hay un hilo principal que hace todo, los demás solo leen cosas). Puedo conseguir que la aplicación funcione correctamente en VS2008 después de un cambio menor (cambié el texto de un formulario y el orden de tabulación de otro formulario), pero ya no puedo hacerlo funcionar fuera del depurador. ¿Alguien sabe lo que podría causar esto?

Aclaración: Modo de publicación, iniciado con el depurador (F5) funciona. El modo de depuración, lanuched con depurador (F5) funciona. El ejecutable de depuración o el ejecutable de lanzamiento iniciado fuera de VS o con Ctrl + F5 falla.

Utiliza Virtual Earth 3D de Microsoft, y parece bloquearse justo cuando el 'anillo de esperanza' (anillo de carga) está por completarse.

registro de eventos dice: ".NET Runtime versión 2.0.50727.3053 - Fatal Error motor de ejecución (000006427F44AA6E) (80131506)"

culpable: esta línea:

 this.loader = PlugInLoader.CreateLoader(this.globeControl.Host); 

Causas que fallar Sin embargo, el formulario que estaba trabajando utiliza exactamente la misma línea sin problemas. Esta línea es nesseccary para que el programa funcione. No tengo idea de lo que está haciendo.

Otra ventaja el error parece estar dentro del .NET framework. La aplicación funcionó en otra máquina, intentando reinstalarla. Actualización: no hizo la diferencia, aunque cuando reparé VS no dejaba de decirme que Visual Studio se bloqueaba aunque no lo estaba ejecutando.

---

error Cuando inicio el programa después de un par de minutos me sale: aplicación ha generado una excepción que podría no controlarse.

Proccess ID = 0x9CC (2508), Thread ID = 0xF0C (3852).

Haga clic en Aceptar para finalizar la aplicación.
Haga clic en CANCELAR para depurar la aplicación.

---

El desmontaje es extraño:

0000000077EF2A90 int   3  
0000000077EF2A91 int   3  
0000000077EF2A92 int   3  
0000000077EF2A93 int   3  
0000000077EF2A94 int   3  
0000000077EF2A95 int   3  
0000000077EF2A96 xchg  ax,ax 
0000000077EF2A9A xchg  ax,ax 
0000000077EF2A9E xchg  ax,ax 
0000000077EF2AA0 int   3  <-- Crashes here 
0000000077EF2AA1 ret  

Se repite el mismo bloque de código varias veces (menos de hacha intercambiar con ella misma)

---

Además de mi equipo, que ha trabajado en cada máquina que lo he probado, a excepción de una VM en mi máquina que no instalará .NET Framework porque la configuración descarga 0 bytes de 0 bytes para el framework) ... wi encantadora sombras.

Answer 1

Lo arreglé, el .NET 2.0 Framework estaba corrupto y cuando lo reinstalé, todo mágicamente comenzó a funcionar nuevamente.

Answer 2

¿Buscar las directivas #if (DEBUG)? Buscar Debug.Assert (?

¿Ha buscado en Google el error?He encontrado el hilo this (no es terriblemente útil)

Answer 3

Here es un artículo de soporte con ese error. ¿Eso aplica?

Quizás el depurador está comiendo una excaption que está lanzando la API VE3D. En VS, haga un ctrl + alt + e y cámbielo para romper cada vez que se lanza una excepción. Esto puede ser tedioso, porque romperá todos tus bloques de captura de prueba, pero podría darte cierta información.

Here es alguna información. sobre ese PlugInLoader. Parece implicar que debe ser llamado desde el manejador de eventos FirstFrameRendered. ¿Tal vez una de tus formas está haciendo eso y otra no?

Answer 4

Tuve problemas similares cuando los conflictos de temporización causaban el error, y mi depuración (puntos de interrupción y paso a través del código) forzó al código a ejecutarse en el orden correcto.

Answer 5

Pruebe optimizaciones de despegue de la versión Release (en la configuración del proyecto) y vea si eso ayuda.

Answer 6

No puedo decirle exactamente cuál es el problema, pero esto es lo que podría hacer para obtener una idea de lo que realmente está sucediendo. Asumo que está utilizando VS2008 o 2005.

1. Cambiar a modo de liberar
2. Ir a debug \ excepciones, y Mark excepciones todos "lanzados", como se muestra aquí: ejecutable http://vvcap.net/db/JbWS_tzy2IpBoI7R7amm.htp
3. Ejecutar en el depurador, ignorar las advertencias de VS que no hay información de depuración

parece que hay una excepción Win32 arrojado algo de tiempo durante la ejecución, pero de esta manera o de otra, obtendrá uno o más mensajes de depuración que explica qué tipo de excepción sucedió y dónde. En la mayoría de los casos esos mensajes hacen que sea bastante claro qué fue exactamente equivocado

EDIT: Una cosa que me olvidé de mencionar es que la depuración no administrado también debe estar encendido, tales como here (when you start program directly from IDE) o here (when you attach to running process)

Answer 7

queda una cosa que creo que es usar WinDbg para intentar depurarlo. Estos son algunos enlaces sobre cómo usarlo:

1. http://www.codeproject.com/KB/debug/windbg_part1.aspx
2. http://blogs.msdn.com/johan/archive/2007/11/13/getting-started-with-windbg-part-i.aspx
3. http://blogs.msdn.com/tess/ (buen blog acerca de la depuración en general, en windbg)

Pensando en ello, sino que también podría haber alguna servicio o algo que está en conflicto. Intente detener todos los servicios innecesarios y cierre los programas innecesarios (incluidos los de inicio) y vea qué sucede entonces.

Answer 8

encontramos y solucionamos este problema con MSFT, nos enfrentamos a este problema con el desarrollo de VSTO. Aplique el siguiente parche de MSFT.

http://support.microsoft.com/kb/975954

http://support.microsoft.com/kb/974372

Answer 9

Una vez tuve un problema similar con exactamente el mismo comportamiento utilizando un plug-in-sistema. Al cargar un complemento de un MarshalByRef -objeto (ver código de ejemplo a continuación), parece que .NET crea un nuevo dominio de aplicación o contexto para el conjunto cargado. (¿Alguien puede confirmar esto? No he encontrado ninguna fuente en relación con esto.)

public class ProxyAssemblyLoader : MarshalByRefObject { 
    public Assembly GetAssembly(string path) { 
     return Assembly.LoadFrom(path); 
    } 
} 

Además, en mi caso, el plug-in de cargas una versión diferente de la mscorlib. (Mi aplicación es CLR2 y la cargada es CLR4) Después utilicé el complemento por reflexión e intenté acceder a un valor del nuevo mscorlib, que se cargó desde el otro dominio de la aplicación. Por lo general, ambos deben ser utilizables porque el mscorlib es un ensamblaje comúnmente utilizado y solo se carga una vez (consulte Global Assembly Cache). Pero parece como si este no fuera el caso. Pero en general, Microsoft advises to avoid eso.

No he averiguado exactamente cuál era el problema, pero calculé la llamada que hace que la aplicación falle sin ninguna pista. ¿Por qué sin alguna pista? Se bloqueó sin ninguna pista, porque la excepción arrojada solo estaba disponible en el dominio de aplicación "el otro" y no está disponible para el dominio principal/predeterminado de la aplicación.

La acción tomada fue simplemente copiar implícitamente el valor de otro ensamblado de appdomains a un valor sin tipo local (object) en el dominio de aplicación predeterminado. Esto fue suficiente para obtener un error de coincidencia de identidad de tipo debido a diferentes versiones del ensamblaje. Parece que Visual Studio podría manejarlo, pero si la aplicación se ejecuta de forma autónoma, se bloquea.

Esto también puede explicar por qué necesitó reinstalar su .NET. Tal vez su .NET-Framework instalado era una versión beta o algo así, que contenía una pequeña diferencia.

En conclusión algunas soluciones generales para el problema podría ser:

• Evitar el uso de diferentes versiones de los conjuntos con diferentes versiones del mismo tipo.
• En otros casos, puede intentar cargar ambos conjuntos dentro del mismo dominio de aplicación. (En la medida de lo posible con respecto al contexto de sondeo.)
• Una solución para cross appdomain communication could be serialization de los valores.
• (Asegúrese de que la correcta .NET Framework no está instalado la versión beta.)

Answer 10

que tenían el mismo problema exacto con una de mis aplicaciones de consola. Decidí que era mi antivirus (Avast) el que causaba el problema.

Agregue la carpeta BIN a la lista de exclusión y deshabilite "DeepScreen". ¡Luego reconstruye el proyecto y vuelve a intentarlo!