visual studio solucion sitio publicar proyecto aplicacion .net visual-studio-2008 crash-dumps

.net - sitio - publicar solucion visual studio 2017



¿Qué causaría que CUALQUIER aplicación.NET se bloquee inmediatamente... excepto un proyecto que creo y depuro dentro de Visual Studio? (14)

Mi software se implementó recientemente en un cliente que dijo que la aplicación se estaba fallando inmediatamente después de iniciarse. Después de una depuración inicial, el cliente me proporcionó acceso remoto a una de las computadoras que no pudo ejecutar la aplicación. Encontré que el bloqueo no fue específico para mi aplicación. Cualquier aplicación que dependiera del marco .NET se bloqueó inmediatamente.

Convenientemente, se instaló Visual Studio 2008, por lo que creé una aplicación rápida hello world y hice clic en Depurar. La aplicación funcionó bien. Pero luego, cuando intenté ejecutar los archivos binarios generados en el directorio /bin/Debug/HelloWorld.exe fuera de Visual Studio, se bloqueó.

Lista de cosas que he probado (ACTUALIZADO) :

  • Verifiqué que "Todos" tiene permisos de lectura y ejecución para c: / Windows.
  • Para probar que el problema era con .NET Framework (y no con mi aplicación), intenté descargar Paint .NET en las computadoras. La configuración de la interfaz se estrelló de la misma manera.
  • Realicé una reparación del marco .NET como se describe en http://support.microsoft.com/kb/908077 (Boy fue tan divertido y lento). Sin suerte.
  • Instalé .NET 3.5 SP1 (antes de que solo tuviera .NET 3.5) Nota: mi aplicación apunta a 2.0, así que lo hice más como una posibilidad remota ... pero aprendí en el proceso que .NET 3.5 SP1 también actualiza los marcos subyacentes.
  • La herramienta de verificación de configuración .NET de Aaron Aaron Stebner . Esta herramienta indicó que .NET fue instalado con éxito. (Olvido si verifiqué todas las versiones pero al menos 2.0 funcionó).
  • Probé algunas aplicaciones mini hola mundo que estaban dirigidas a .NET 2.0 y .NET 3.5 y ambas fallaron de la misma manera.
  • Intenté lanzar aplicaciones .NET a través de la línea windbg cmd. Hacer esto me permitió invocar mis sencillas aplicaciones de hello world. Entonces, el simple .NET hello world funciona cuando lo invoca windbg o se inicia a través de la depuración en Visual Studio ... pero no lo hace si intento ejecutarlo de forma independiente.

He creado un archivo de volcado utilizando WinDbg. No fue todo lo que me reveló.

FAULTING_IP: mscorwks!PEImage::GetEntryPointToken+21 79f4ff9d f6401010 test byte ptr [eax+10h],10h EXCEPTION_RECORD: 0012f710 -- (.exr 0x12f710) ExceptionAddress: 79f4ff9d (mscorwks!PEImage::GetEntryPointToken+0x00000021) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 00000000 Parameter[1]: 00000010 Attempt to read from address 00000010 FAULTING_THREAD: 00000b44 PROCESS_NAME: MyProcess.exe ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint has been reached. EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid DETOURED_IMAGE: 1 NTGLOBALFLAG: 0 APPLICATION_VERIFIER_FLAGS: 0 MANAGED_STACK: !dumpstack -EE OS Thread Id: 0xb44 (0) Current frame: ChildEBP RetAddr Caller,Callee EXCEPTION_OBJECT: !pe cb10b4 Exception object: 00cb10b4 Exception type: System.ExecutionEngineException Message: <none> InnerException: <none> StackTrace (generated): <none> StackTraceString: <none> HResult: 80131506 MANAGED_OBJECT_NAME: System.ExecutionEngineException CONTEXT: 0012f72c -- (.cxr 0x12f72c) eax=00000000 ebx=00000000 ecx=00000000 edx=0000000e esi=001a1490 edi=00000001 eip=79f4ff9d esp=0012f9f8 ebp=0012fa1c iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246 mscorwks!PEImage::GetEntryPointToken+0x21: 79f4ff9d f6401010 test byte ptr [eax+10h],10h ds:0023:00000010=?? Resetting default scope READ_ADDRESS: 00000010 FOLLOWUP_IP: mscorwks!PEImage::GetEntryPointToken+21 79f4ff9d f6401010 test byte ptr [eax+10h],10h BUGCHECK_STR: APPLICATION_FAULT_NULL_CLASS_PTR_DEREFERENCE_SHUTDOWN PRIMARY_PROBLEM_CLASS: NULL_CLASS_PTR_DEREFERENCE_SHUTDOWN DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE_SHUTDOWN LAST_CONTROL_TRANSFER: from 79ef02b5 to 79f4ff9d STACK_TEXT: 79f4ff9d mscorwks!PEImage::GetEntryPointToken+0x21 79ef02b5 mscorwks!PEFile::GetEntryPointToken+0xa0 79eefeaf mscorwks!SystemDomain::ExecuteMainMethod+0xd4 79fb9793 mscorwks!ExecuteEXE+0x59 79fb96df mscorwks!_CorExeMain+0x15c 7900b1b3 mscoree!_CorExeMain+0x2c 7c817077 kernel32!BaseProcessStart+0x23 SYMBOL_STACK_INDEX: 0 SYMBOL_NAME: mscorwks!PEImage::GetEntryPointToken+21 FOLLOWUP_NAME: MachineOwner MODULE_NAME: mscorwks IMAGE_NAME: mscorwks.dll DEBUG_FLR_IMAGE_TIMESTAMP: 471ef729 STACK_COMMAND: .cxr 0012F72C ; kb ; dds 12f9f8 ; kb FAILURE_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE_SHUTDOWN_80000003_mscorwks.dll!PEImage::GetEntryPointToken BUCKET_ID: APPLICATION_FAULT_NULL_CLASS_PTR_DEREFERENCE_SHUTDOWN_DETOURED_mscorwks!PEImage::GetEntryPointToken+21 WATSON_STAGEONE_URL: http://watson.microsoft.com/StageOne/MyProcess_exe/2_4_4_39/4a8a192c/unknown/0_0_0_0/bbbbbbb4/80000003/00000000.htm?Retriage=1 Followup: MachineOwner

Edición 1: los detalles del registro de eventos para este error dicen que es una versión 2.0.50727.3053 de Runtime .NET - Error grave del motor de ejecución (7A097706) (80131506).

DotNetFatalExecutionErrorScreenshot http://www.blakerobertson.com/storage/perm/dotNetFatalCrash.jpg

Edición 2 (10-7-09): Este problema aún está activo.

Edición 3 (3-29-10): esta actualización es para que todos sepan que nunca resolví el problema correctamente. El cliente que está en la máquina fue porque perdió el interés en resolverlo y simplemente cambió la imagen de la máquina :(. Gracias por todas las contribuciones.

Asegúrese de que el usuario no esté iniciando la aplicación desde un recurso compartido de red. De forma predeterminada, .Net lanza una excepción de seguridad al intentar iniciar una aplicación desde una fuente no confiable.

Puede cambiar este comportamiento utilizando la utilidad de configuración de Microsoft .Net Framework en Herramientas administrativas.

Dado que no ocurre en todas las máquinas cliente, ¿podría ser RAM? ¿Puede reiniciar la máquina defectuosa y ejecutar la herramienta de diagnóstico de memoria?

¿Se podría haber encendido DEP para esta máquina en algún momento en el pasado? No obtendrías una excepción .Net para este tipo de seguridad porque tu aplicación simplemente no se ejecuta, por lo que hay pocas posibilidades de lanzar un error.

Hace poco tuve un problema que se manifestaba de una manera muy similar. Resultó que ciertas DLL de terceros no formaban parte de mi implementación (solo estaba copiando cosas del directorio bin). Creé una aplicación de configuración que recogió todas las DLL y una vez que se implementaron correctamente, dejó de fallar. Es extraño que haya sido un duro fracaso en lugar de una excepción.

Es posible que esto no se aplique a usted ya que dice que se aplica a cualquier aplicación .NET. ¿Quizás está trabajando en un archivo de proyecto antiguo con algunas referencias de sobra?

Iniciarlo utilizando WinDbg. Usando Son of Strike deberías poder ver exactamente por qué se está estrellando. Puede haber un error de carga de ensamblaje de bajo nivel. He pasado por problemas similares con WinDbg en el pasado.

No hay una solución de bala de plata y no creo que sea un problema de permiso.

Esto es lo que intentaría

  1. Si se trata de una máquina de 64 bits, intente cambiar al modo de 32 bits, he visto esto con las DLL de 32 bits que intentan ejecutarse en 64 bits.
  2. Cree un nuevo sitio web en el servidor y ejecute aspnet_regiis en él.
  3. Desinstala y vuelve a instalar los frameworks 2.0 y 3.5. Asegurar y ejecutar aspnet_regiis cuando esté completo

Parece que te conseguiste un "divertido" allí. No tengo ni idea, pero aquí están mis sugerencias de apuñalamiento en la oscuridad de karma de todos modos.

1) Además de los permisos de usuario regulares asignados por Windows, también hay un conjunto separado de configuraciones de seguridad específicamente para el marco .NET. Si tiene instalado .NET SDK, busque la herramienta "Configuración de Microsoft .NET Framework" en su Panel de control (puede estar en Herramientas administrativas). Vea si alguna de las configuraciones es diferente de su máquina dev.

2) Supongo que su cliente está bajo el control de un régimen de TI en su lugar de trabajo. Vea si usted o su cliente pueden obtener una nueva instalación de Windows donde funciona el programa y luego, trabajando con su grupo de TI, aplique uno de sus requisitos (configuración de seguridad, programas antivirus, etc.) hasta que su programa se detenga. trabajando. Un buen viejo último estado de trabajo caza de errores. Por supuesto, esto supone la cooperación de su departamento de TI, por lo que espero que su programa sea importante para un ejecutivo en algún lugar.

Según su salida de windbg, parece que alguien ha inyectado una DLL en el proceso durante el inicio del proceso, y que la inyección no está diseñada para ninguna versión de mscorwks que se haya cargado. Si se trata de una estación de trabajo informal (p. Ej., Una secretaria), la confiscaría para que MIS / IT la inspeccionara en busca de malware. Si se trata de una máquina que se encuentra en una sala de servidores, miraría al cliente para realizar una reubicación en otra máquina.

No sospecho que esto le sucederá a ningún otro cliente, y en 8 años de desarrollo .NET, lo único que puede (probablemente) causar que el comportamiento que está describiendo es un intento de ejecutar una aplicación .NET en un sistema con una versión anterior. La versión de la estructura instalada (por ejemplo, la falta de soporte, da como resultado un cuadro de diálogo estándar de depuración / cancelación en la mayoría de las versiones de Windows) y ese NO es el problema. Esto tampoco está relacionado con la arquitectura del procesador, la versión de Framework o el nivel SP, no está relacionado con ningún software AV comercial, ni con ningún software comercial de seguridad de la red.

Claramente no es algo en su código, y no veo que sea algo que pueda arreglar para su cliente. No conozco ninguna herramienta ni serie de pasos que pueda usar para resolver este problema, salvo que el cliente vuelva a crear una imagen de la máquina de destino. Antes de que lo hagan, una vez más, haga que MIS / IT lo haga pasar por un malware potencial (específicamente, un malware que no se distribuiría entre el público en general).

Para obtener información relacionada, visite: http://research.microsoft.com/apps/pubs/default.aspx?id=68568

Buena suerte.

Tenía el mismo problema y se solucionó con el asistente de publicación. Así es como descubrí que la máquina de destino no tenía instalado el paquete Visual Basic Powerpack 3.0. Después de instalar eso, funciona como un encanto.

Tuve un problema similar hace unos meses (aunque no recuerdo el código de error). Después de probar muchas cosas, lo siguiente resolvió el problema (hasta donde puedo recordar):

Eliminar todos los archivos temporales en la carpeta temporal .net (y también comprobar el permiso de esa carpeta)

Tuvimos un problema muy similar en una implementación a gran escala en todos los casos, al ejecutar la reparación en el marco se solucionó el problema que probaría.

Un par de sugerencias más para probar:

  • Solo para asegurarme de que no es el problema vshost.exe, intentaría ejecutar MyProcess.exe en cdb / windbg y vería el comportamiento.
  • El problema se parece a un AV de lectura y si la aplicación funciona correctamente en el depurador, intentaría reparar mi instalación .Net, en caso de que exista una posible corrupción en la ejecución del handsover del SO de un ensamblado .Net a mscorwks.dll.