2010-11-09 11 views
6

Ich habe ein Backup-Programm, das derzeit in unserer Unternehmensumgebung auf etwa 70 Maschinen läuft. Eine Mischung aus Laptops, Desktops und Windows (xp-32, Vista-32, Vista-64, 7-32-7-64) ohne Probleme..NET Application Crash ohne Debug Info

Es gibt eine Ausnahme, und das ist der Grund, warum ich hier für Hilfe poste.

Auf einem Rechner, der ein Dell Latitude unter Windows 7 64 Bit mit installiertem .Net 4 Framework ist, stürzt die Konsolenanwendung unmittelbar vor dem Start von Sub Main ab. Es gibt einfach den generischen Windows-Fehler "Ein Problem hat dazu geführt, dass das Programm nicht mehr ordnungsgemäß funktioniert." ohne Möglichkeit, Debug-Informationen zu sehen.

Dinge, die ich habe versucht:
- Deinstallieren Sie alle unstandard Software
- mehrere Erklärungen kommentierte heraus, die ich dachte, könnte Probleme verursachen
- neu kompiliert für Auto CPU, x86 und x64, um zu sehen, ob es einen Unterschied
gemacht - Behinderte das Virus Scanner
- Benutzer ist ein Administrator aber ich versuchte, als Administrator ausführen
- eine messagebox als das erste, was in Sub Main hinzugefügt, um zu bestimmen, wo es
stürzt - Added versuchen Fänge zu allen relevanten Code

konnte ich ein bisschen mehr Informationen aus der Ereignisanzeige erhalten:

Fehlgeschlagene Modulname: KERNELBASE.dll, Version: 6.1.7600.16385, Zeitstempel: 0x4a5bdbdf
Ausnahmecode: 0xe0434f4d Fehler Offset: 0x0000b727

diesen nächsten paar Einträge scheinen mir seltsam:

Fehlgeschlagene Prozess-ID: 0x% 10
Fehlgeschlagene applicati: 0x% 9
Fehlgeschlagene Anwendung Startzeit auf dem Pfad:% 11
Fehlgeschlagene Modulpfad:% 12

konnte ich auch die .wer Datei (Windows Error Report Flat File) nach oben ziehen und die meisten der gleichen Informationen erbrochen aber enthalten auch einige geladene DLL und andere Dateien werden verwendet.

Danke, dass Sie sich die Zeit genommen haben, meine Textwand zu lesen, und hoffentlich hat jemand ein paar Ideen, wie es weitergeht.

Joshua

edit:

Ich bin der folgenden Win32-API-Aufrufe denken könnten die Probleme verursachen und sie waren die einzigen Dinge, die ich ohne großen Code neu schreiben nicht einfach kommentieren Sie könnte .

Wenn sie sind, warum nur auf dieser einer Maschine :(

' 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 
+0

ich mich gefragt, warum ich nicht den Benutzer erreichen konnte. Er musste nach Brasilien fliegen, also werde ich die Ergebnisse dieser Bemühungen veröffentlichen, wenn ich in ein paar Tagen an seine Maschine zurückkomme :( – JoshF

+0

Entschuldigung für das Fehlen eines Updates. Der Benutzer kam aus Brasilien zurück und einige Wochen später das Problem schien sich selbst zu arbeiten. Ich habe nie die Ursache gefunden :( – JoshF

Antwort

1

zuerst würde ich Tess Ferrdandez blog Besuche es hat Informationen über eine Crash-Debug-Datei erstellen und es bei der Suche mit windbg

zweiten I würde versuchen, das Framework auf einer dieser Maschinen zu reparieren, da wir in einer Bereitstellung ein ähnliches Problem hatten und das Problem dadurch behoben wurde.

+0

Wenn ich die Maschine bekomme ich werde deinstallieren. Net Framework 4.0 und versuchen Sie installieren 3.5 und sehen, ob das einen Unterschied macht. – JoshF

+0

@joshf Es ist wahrscheinlich für Am besten stell dir vor, warum es mit .NET Framework 4.0 schief geht. Stell dir das Chaos vor, wenn die anderen Maschinen von 3.5 auf 4.0 aktualisiert werden! :) –

+0

+1 für Tess link, sie rockt! :) windbg war mein Retter ein paar Mal und jeder Windows-Entwickler sollte die Grundlagen davon lernen. Sehen Sie Ingo Rammers NDC2010-Präsentation "Hardcore Production Debugging", es ist wirklich gut. –

0

Schauen Sie sich das Fusionsprotokoll an, um zu sehen, wie die Baugruppen geladen werden. Möglicherweise findet man keine Baugruppe, die versucht zu laden.

How to enable assembly bind failure logging (Fusion) in .NET

EDIT: Wilder Schuss im Dunkeln ... Hat diese Maschine haben schnelle Benutzerumschaltung aktiviert? Wenn ja, versuchen Sie es zu deaktivieren.

http://www.addictivetips.com/windows-tips/how-to-enable-disable-fast-user-switching-in-windows-xp-and-windows-vista/

0

Dieser Fehler tritt manchmal, wenn Sie 32-Bit-DLLs (oder gemischte 32-Bit- und 64-Bit-DLLs), kompiliert für AnyCPU, und auf einem 64-Bit-System. Ich weiß, dass Sie sagten, dass Sie versucht haben, für x86 zu kompilieren, aber versuchen Sie sicherzustellen, dass ALLE DLLs 32-Bit sind, dann kompilieren Sie für x86.

+0

Alle DLLS, die ich für diese Anwendung verwende, sollte win32 oder von der globalen Assembly sein. Ich habe keine Klassen-DLLs, die ich für diese spezielle Anwendung selbst erstellt habe. – JoshF

1

Ich würde alle Ihre Referenzen für Handles (HWND) zu IntPtr ändern, da dieser Datentyp in jedem. NET Framework funktioniert, aber ich glaube nicht, dass der Integer-Datentyp in der 64-Bit-Umgebung für Handle Handle funktioniert.

Die unten wird auch sniipet von einem Microsft Artikel:

Im allgemeinen Framework-Assembly in Visual Basic geschrieben wird das gleiche, unabhängig von der Plattform laufen. Es gibt jedoch einige Fälle, die sich auf verschiedenen Plattformen unterschiedlich verhalten. Diese häufigen Fälle sind:

Strukturen, die Elemente enthalten, die abhängig von der Plattform die Größe ändern, z. B. ein beliebiger Zeigertyp.

Zeigerarithmetik mit konstanten Größen.

Falsche Plattformaufruf oder COM-Deklarationen, die Integer für Handles anstelle von IntPtr verwenden.

Umwandlung von IntPtr in Integer.

Verwenden von Plattformaufruf oder COM-Interop mit Komponenten, die nicht auf allen Plattformen vorhanden sind.

Vollständiger Artikel finden Sie hier: http://msdn.microsoft.com/en-us/library/8ck8e1y2(v=vs.80).aspx

Verwandte Themen