none
How to debug an Application crashing on startup RRS feed

  • Allgemeine Diskussion

  • Hi together!

    I'm struggling with a very strange issue running out of ideas meanwhile.

    The situation:

    I got a bigger Tool written in VS2012/C#/.NET4 which is deployed on several machines.

    Now I got some machines in an of-site location where it crashes on startup with an exception 0xc0000409.

    This seems to occur before my code is even executed - at least all countermeasures to do some debugging in there (adding a individual crashhandler to save a crashdump or even showing simple messageboxes to see which steps on startup were passed) seem not to be reached before the crash.

    I'm now running out of ideas how to nail that issue down - especially since I do not have physical access to the machines.

    The user on the other side is willing to help debugging - If I only had an idea how ....

    Any hint's for me?

    Regards

    Carsten

    Mittwoch, 28. November 2012 08:30

Alle Antworten

  • Hi Carsten,

    Du musst alle unbehandelten Ausnahmen, die auftreten können behandeln. Dafür musst Du diesen Eventhandler hinzufügen: http://msdn.microsoft.com/en-us/library/system.windows.forms.application.threadexception.aspx


    Hannes

    If you have got questions about this, just ask.

    In a perfect world,
    users would never enter data in the wrong form,
    files they choose to open would always exist
    and code would never have bugs.

    C# to VB.NET: http://www.developerfusion.com/tools/convert/csharp-to-vb/



    • Bearbeitet Heslacher Mittwoch, 28. November 2012 08:48
    Mittwoch, 28. November 2012 08:41
  • Hallo Carsten,

    da dies ein deutschsprachiges Forum ist, die Antwort in deutsch.

    Das wäre ein Fall für WinDbg. Schau Dir mal an:
    How to debug a Stack Overflow for beginners?

    Für die Ursachen siehe u. a. http://www.cplusplus.com/forum/windows/39061/
    (Wobei auf .NET Seite der Grund ein ungültiger Interop Aufruf sein könnte)

    Gruß Elmar

    Mittwoch, 28. November 2012 08:43
    Beantworter
  • Hallo Carsten,

    Lass dir mal als erstes von einen Administrator über eventvwr.msc die Ausnahmen auflisten, die bei der Ausführung deiner Anwendung protokolliert wurden. Poste sie dann bitte im genauen und anonymisierten Wortlaut hier. Es ist nämlich möglich, dass sich der Fehler bereits in der Execution Engine ereignet, lange bevor deine Anwendung auch nur die leiseste Chance hatte, was zu protokollieren.

    Gruß
    Marcel

    Mittwoch, 28. November 2012 10:14
  • Hallo !

    Der Eventhandler ist schon drin - und sollte dazu führen das alle unhandled Exceptions via NBug erfasst werden.

    Das funktioniert auch wenn ich in meiner Applikation eine Exception auslöse, nicht aber bei dem hier beschriebenen Problem. Ich gehe also davon aus das meine Main() vor der Exception gar nicht aufgerufen wurde.

    Gruß

    Carsten

    Mittwoch, 28. November 2012 12:36
  • @Marcel:

    Hier is nun die Ausgabe aus dem Eventviewer - ich hoffe es ist alles korrekt übersetzt, denn die Originalmessage ist koreanisch:

    Application Program: MYAPPLICATION.exe Framework version: v4.0.30319

    Explanation: Process terminated by unprocessed exception.

    Exception Info.:System.TypeInitializationException

    stack:   

       Location: NBug.Handler.get_UnhandledException()   

        Location: HDAT.Program.Main()

    Donnerstag, 29. November 2012 06:52
  • Es sieht ganz danach aus, als könnte eine Assembly nicht geladen werden.
    Ein Ladefehler kann viele Gründe haben. Die häufigsten darunter:

    1. Falsche Prozessorarchitektur beim Kompilieren angegeben (z.B. "Any CPU" statt "x86"). Das kommt oft vor, wenn eine von deiner Anwendung referenzierte x86-Assembly auf einem 64-bit Rechner in einem 64-bit Prozess und nicht im WOW geladen werden soll.

    2. Überreste einer älteren Installation auf dem Zielcomputer. Nach der neuen Installation sind im Anwendungsordner z.B. ein Mix von .NET 3.5- und .NET 4.0-Assemblies zu finden, was die Execution Engine (genauer die Fusion-Engine) durcheinanderbringt.

    Ich würde dir empfehlen, für die Diagnose fuslogvw.exe zu verwenden.

    Donnerstag, 29. November 2012 10:09
  • Danke für die Info.

    1. hab ich gechecked, das passt.

    2. wäre sicherlich denkbar - obwohl der User angeblich bereits alles was war mit .NET zu tun hat deinstalliert - und dann .NET4 wieder installiert hat. Gibt es von fuslogvw irgendwie eine Version die leicht deploybar ist? Das komplette SDK auf besagtem Rechner zu installieren  könnte problematisch werden ....

    Gruß

    Carsten

    Donnerstag, 29. November 2012 15:09
  • Soviel ich weiß, gibt es für das .NET 4.0 Framework kein kompakteres Deployment.

    Freilich könntest Du nach einmaligem Installieren des SDKs auf einem Testrechner einfach in den Ordner %programfiles%\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools wechseln (bzw. ...\1031) und von dort flogvwrc.dll sowie fuslogvw.exe kopieren. Das sollte m.E. reichen.

    Gruß
    Marcel

    Donnerstag, 29. November 2012 15:22
  • OK,

    leider war auch dieser Versuch nicht von Erfolg gekrönt. Gemäß dem Bericht des Users werden in fuslog keine Fehler beim Crash angezeigt.

    Dienstag, 4. Dezember 2012 07:12
  • Ich fasse zusammen: Deine VS2012/C#/.NET4-Anwendung funktioniert auf den meisten Rechnern. Auf dem (koreanischen) Absturz-Rechner konnten keine Assemblyladefehler oder Bindungsfehler erkannt werden. Die Anwendung crasht mit einem 0xc0000409-Ausnahmefehler in HDAT.Program.Main(), wahrscheinlich in der (ersten) Zeile:

    AppDomain.CurrentDomain.UnhandledException += NBug.Handler.UnhandledException;

    Dort wird eine System.TypeInitializationException geworfen. Der Ausnahmetext lautet "Process was terminated due to an unhandled exception". Die InnerException ist unbekannt. Könntest Du das remote-konfigurieren/anfordern und posten? Zur Zeit sieht es nämlich nach einem NBug-Bug aus (fehlende Abhängigkeit oder so was).

    Wenn auch das nicht geht: Die Debugging Tools for Windows enthalten ein Tool namens GFlags (Global Flags), das sehr hilfreich für Crash-Dumping ist. Auf der Registerkarte Silent Process Exit hat man die Möglichkeit den Namen der zu testenden Anwendung einzugeben sowie die CheckBox Enable dump collection anzuklicken, was bei der Diagnose über den Endbenutzer sehr praxistauglich ist. Die Minidumps werden unter %TEMP%\Silent Process Exit gespeichert.


    • Bearbeitet Marcel Roma Dienstag, 4. Dezember 2012 11:38
    Dienstag, 4. Dezember 2012 09:18
  • ****************************************************************************************************************
    Dieser Thread wurde mangels weiterer Beteiligung des Fragestellenden ohne bestätigte Lösung abgeschlossen.
    Neue Rückfragen oder Ergänzungen zu diesem Thread bleiben weiterhin möglich.
    ****************************************************************************************************************

    Robert Breitenhofer, MICROSOFT   Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip Entwickler helfen Entwickler“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Donnerstag, 31. Januar 2013 12:11
    Moderator