vb.net - org - mapwindows 5
.NET Application Crash sin información de depuración (4)
Tengo un programa de respaldo que se está ejecutando actualmente en nuestro entorno corporativo en aproximadamente 70 máquinas. Una mezcla de computadoras portátiles, computadoras de escritorio y Windows (xp-32, vista-32, vista-64, 7-32-7-64) sin problemas.
Hay una excepción, y es la razón por la que estoy publicando aquí para obtener ayuda.
En una máquina que es una Dell Latitude que ejecuta Windows 7 64 bit con .Net 4 Framework instalado, la aplicación de la consola se bloqueará inmediatamente antes de que comience Sub Main. Simplemente da el error genérico de Windows "Un problema hizo que el programa dejara de funcionar correctamente". sin opción para ver información de depuración.
Cosas que he intentado:
- Desinstalar todo el software no estándar
- Comentando varias declaraciones que pensé que podrían causar problemas
- Recompilado para Auto CPU, x86 y x64 para ver si marcó la diferencia
- Desactivado el escáner de virus
- El usuario es un administrador, pero traté de ejecutarme como administrador
- Se agregó un cuadro de mensaje como lo primero en Sub Main para determinar dónde se bloquea.
- Se han agregado capturas de prueba a todos los códigos relevantes
Pude obtener un poco más de información del Visor de eventos:
Nombre del módulo de error: KERNELBASE.dll, versión: 6.1.7600.16385, marca de tiempo: 0x4a5bdbdf
Código de excepción: 0xe0434f4d Compensación de error: 0x0000b727
Estas siguientes entradas me parecen extrañas:
ID del proceso de fallas: 0x% 9
Tiempo de inicio de la aplicación con errores: 0x% 10
Ruta de aplicación de error:% 11
Ruta del módulo de fallas:% 12
También pude extraer el archivo .wer (archivo plano del informe de errores de Windows) y regurgitó la mayor parte de la misma información, pero también incluyó algunos dll cargados y otros archivos que se estaban utilizando.
Gracias por tomarse el tiempo para leer mi muro de texto y espero que alguien tenga algunas ideas sobre cómo proceder.
Joshua
editar:
Estoy pensando en que las siguientes llamadas a la API de Win32 pueden estar causando los problemas y fueron las únicas cosas que no pude comentar fácilmente sin una nueva escritura de código grande.
Si lo son, ¿por qué solo en esta máquina?
'' Obtain a handle to the console application window by passing the title of your application.
Dim hWnd As Integer = Process.GetCurrentProcess().MainWindowHandle
Dim hMenu As Integer = GetSystemMenu(hWnd, False)
''WIN API Functions to assist in disabling the Close button on the Console Window
Private Declare Function DeleteMenu Lib "user32" (ByVal hMenu As Integer, ByVal uPosition As Integer, ByVal uFlags As Integer) As Boolean
Private Declare Function GetForegroundWindow Lib "user32" () As Integer
Private Declare Function GetSystemMenu Lib "user32" (ByVal hWnd As Integer, ByVal bRevert As Boolean) As Integer
Private Declare Function GetWindow Lib "user32" (ByVal hWnd As Integer, ByVal uCmd As Integer) As Integer
Private Declare Function GetWindowText Lib "user32" Alias "GetWindowTextA" (ByVal hWnd As Integer, ByVal lpString As String, ByVal nMaxCount As Integer) As Integer
Private Declare Function ShowWindow Lib "user32.dll" (ByVal hWnd As Integer, ByVal nCmdShow As Int32) As Boolean
Public Declare Function WNetGetConnection Lib "mpr.dll" Alias "WNetGetConnectionA" (ByVal lpszLocalName As String, ByVal lpszRemoteName As String, ByRef cbRemoteName As Integer) As Integer
Cambiaría todas las referencias de identificadores (hwnd) a IntPtr, ya que este tipo de datos funcionará en cualquier .NET Framework, pero no creo que el tipo de datos entero funcione en el entorno de 64 bits para handle handle.
El siguiente también es sniipet de un artículo de Microsft:
En general, los ensamblados de .NET Framework escritos en Visual Basic se ejecutarán igual independientemente de la plataforma. Sin embargo, hay algunos casos que se comportan de manera diferente en diferentes plataformas. Estos casos comunes son:
Estructuras que contienen miembros que cambian de tamaño según la plataforma, como cualquier tipo de puntero.
Aritmética del puntero que incluye tamaños constantes.
Invocación de plataforma incorrecta o declaraciones COM que usan Integer para identificadores en lugar de IntPtr.
Casting IntPtr a Entero.
Usar invocación de plataforma o interoperabilidad COM con componentes que no existen en todas las plataformas.
El artículo completo se puede encontrar aquí: http://msdn.microsoft.com/en-us/library/8ck8e1y2(v=vs.80).aspx
primero verificaría que el blog de Tess Ferrdandez tiene información sobre cómo crear un archivo de depuración y mirarlo con windbg
segundo, intentaría reparar el marco en una de estas máquinas ya que teníamos un problema similar en una implementación y eso resolvió el problema.
Ese error ocurre a veces cuando tiene DLL de 32 bits (o DLL mixtos de 32 y 64 bits), compila para cualquierCPU y se ejecuta en un sistema de 64 bits. Sé que dijiste que intentaste compilar para x86, pero asegúrate de que TODOS los archivos DLL sean de 32 bits y compila para x86.
Mire el registro de fusión para ver los ensamblajes de su carga. Posiblemente, no encontrar un ensamblaje está tratando de cargar.
Cómo habilitar el registro de fallas de enlace de ensamblaje (Fusion) en .NET
EDITAR: disparo salvaje en la oscuridad ... ¿Esta máquina tiene activada la función de cambio rápido de usuario? Si es así, intente desactivarlo.