none
APP Crash in KernelBase.dll RRS feed

  • Frage

  • Hallo Forum,

    ich habe immer sporadisch ein Probleme beim Ausführen einer Server Anwendung die von uns entwickelt wurde. Dabei werden so ziemlich alle Exceptions gefangen die auftreten können, dennoch stürzt das Programm häufig ab. Dabei ist zu beobachten, dass die Abstürze bei Windows 7 Professional SP1 64bit auftreten, nicht aber bei 32bit Rechnern. Die Serveranwendung muss aber bei Kunden 24/7 laufen. Momentan läuft er ein paar Tage und hängt dann.

    Kann man aufgrund des EventViewer Log Files herauslesen, wo das Problem ist? Wie kann man Fehler in der KernelBase.dll nachvollziehen?

    Hier das Ereignisanzeige Log:

     Protokollname: Application
    Quelle:        Application Error
    Datum:         02.03.2018 03:20:45
    Ereignis-ID:   1000
    Aufgabenkategorie:(100)
    Ebene:         Fehler
    Schlüsselwörter:Klassisch
    Benutzer:      Nicht zutreffend
    Computer:      LR22527001
    Beschreibung:
    Name der fehlerhaften Anwendung: Prosys.TM.ApplicationServer.exe, Version: 1.0.0.0, Zeitstempel: 0x573c17bb
    Name des fehlerhaften Moduls: KERNELBASE.dll, Version: 6.1.7601.23889, Zeitstempel: 0x598d50ba
    Ausnahmecode: 0xe0434f4d
    Fehleroffset: 0x000000000001a06d
    ID des fehlerhaften Prozesses: 0x16a4
    Startzeit der fehlerhaften Anwendung: 0x01d3ae8720d375f8
    Pfad der fehlerhaften Anwendung: C:\Promot\Toolmaster\Server\Prosys.TM.ApplicationServer.exe
    Pfad des fehlerhaften Moduls: C:\Windows\system32\KERNELBASE.dll
    Berichtskennung: 4fdd0be8-1dc0-11e8-8630-00010528f68f
    Ereignis-XML:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Application Error" />
        <EventID Qualifiers="0">1000</EventID>
        <Level>2</Level>
        <Task>100</Task>
        <Keywords>0x80000000000000</Keywords>
        <TimeCreated SystemTime="2018-03-02T02:20:45.000000000Z" />
        <EventRecordID>17073</EventRecordID>
        <Channel>Application</Channel>
        <Computer>LR22527001</Computer>
        <Security />
      </System>
      <EventData>
        <Data>Prosys.TM.ApplicationServer.exe</Data>
        <Data>1.0.0.0</Data>
        <Data>573c17bb</Data>
        <Data>KERNELBASE.dll</Data>
        <Data>6.1.7601.23889</Data>
        <Data>598d50ba</Data>
        <Data>e0434f4d</Data>
        <Data>000000000001a06d</Data>
        <Data>16a4</Data>
        <Data>01d3ae8720d375f8</Data>
        <Data>C:\Promot\Toolmaster\Server\Prosys.TM.ApplicationServer.exe</Data>
        <Data>C:\Windows\system32\KERNELBASE.dll</Data>
        <Data>4fdd0be8-1dc0-11e8-8630-00010528f68f</Data>
      </EventData>
    </Event>


    Freitag, 2. März 2018 09:40

Antworten

  • Ich denke, da helfen auf den Absturzrechnern nur die Debugging-Tools, die man auch separat installieren kann.
    Im Falle des Absturzes kann man sich dann den Callstack ansehen und die Parameter der aufgerufenen Funktionen.

    Da ihr die Software selber im Griff habt könnte man auch eine Debug-Version incl. Symboldatei installieren.
    Wichtig ist vor allem der Callstack, da man sonst nicht erkennen kann, was denn da aufgerufen wurde.

    Welche Sprache wurde verwendet (C++, .Net)?

    U.U. fehlt eine Redistributable abhängig von eurer Entwicklungsumgebung.

    Montag, 12. März 2018 16:03
  • Mir sind nur die allgemeinen Tools bekannt:

    https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/

    Im Falle eines Crashs wird dann ein Fenster zum Aufruf des Debuggers angeboten.
    Testweise kann man auch den ProzessExplorer von SysInternals bemühen.
    Wenn der Crash nicht zum Beenden des Prozesses führt sondern ein Fenster anzeigt, lässt sich per ProzessExplorer der Callstack dann noch anzeigen.

    Ist die Anwendung denn zwingend in 64-Bit zu fahren oder reicht ggf. nicht generell 32-Bit?

    Wenn du mit 1,4GB Speicher für die Anwendung auskommst kannst du ggf. dein Projekt fix auf i86 einstellen.
    Manchmal hat man das Problem ggf. mit Fremd-DLL's, die u.U. für bestimmte Frameworks nicht geeignet sind.

    Generell gilt nämlich:
    Innerhalb einer .NET-Anwendung können nicht verschiedene Frameworks zum Einsatz kommen.
    Welches Framework genommen wird, entscheidet der Start der EXE (Version, 32-/64-/Any).
    Jede geladene DLL wird dann ebenso mit derselben Version ausgeführt, deshalb lässt sich für Komponenten-Projekte (DLL's) die Version auch nicht festlegen.
    Bis Version 3.5 wurde dies auch durch getrennte Verzeichnisse gut realisiert.
    Seit Version 4.0 sind wir allerdings wieder in der alten DLL-Hölle, denn hier wird zur Laufzeit automatisch immer die neueste Version gezogen (4.0, 4.5, 4.6.n, 4.7) da es keine Unterscheidungen im Verzeichnis mehr gibt.
    Dies führte i.Ü. auch zu teilweisen Störungen durch die automatischen Updates zu 4.7.

    Hast du also u.U. 3.-Produkte für Framework < 3.5 im Einsatz könnten diese ggf. Inkompatibel zumindest bzgl. 64-Bit sein.
    Nun ist es ja auch so, dass selten alle Teile eines Projektes bei jedem Kunden durchlaufen werden was eben den sporadischen Fehler erklärt. das kann ich mit meinen eigenen Entwicklungen durchaus nachvollziehen.

    Donnerstag, 15. März 2018 09:35

Alle Antworten

  • May be, you need assistance from your vendor of the software.

    Freitag, 2. März 2018 10:25
  • Hallo,

    wir haben die Software entwickelt, um die es hier geht.
    Hab die Frage mal ins deutsche übersetzt, da es sich hierbei anscheinend um ein deutschsprachiges Forum handelt ;)

    Montag, 5. März 2018 06:44
  • Ich denke, da helfen auf den Absturzrechnern nur die Debugging-Tools, die man auch separat installieren kann.
    Im Falle des Absturzes kann man sich dann den Callstack ansehen und die Parameter der aufgerufenen Funktionen.

    Da ihr die Software selber im Griff habt könnte man auch eine Debug-Version incl. Symboldatei installieren.
    Wichtig ist vor allem der Callstack, da man sonst nicht erkennen kann, was denn da aufgerufen wurde.

    Welche Sprache wurde verwendet (C++, .Net)?

    U.U. fehlt eine Redistributable abhängig von eurer Entwicklungsumgebung.

    Montag, 12. März 2018 16:03
  • Hi,

    Danke für deine Unterstützung.

    Die Anwenung wird mit c# mit dem .net Framework 3.5 entwickelt. Fehlerbehandlungen mit Logging sind in allen Programmteilen enthalten, auch in der Main Methode wo die eigentliche Anwendung gestartet wird. Das Problem ist, dass die Fehlerbehandlung gar nicht zum Zug kommt, da keine Log-Einträge beim Absturz durch die KernelBase.dll erstellt werden. Der Einzige Hinweis ist der Eintrag im EventViewer oben. Dass eine Redistributeable fehlt denke ich nicht, da alle Dlls auf die Verwiesen wird mit kopiert werden.

    Welche Debugging Tools könnte man auf den Rechnern installieren bzw. welche würdest du mir empfehlen?

    Der Callstack würde mir bei der Behebung des Problems sehr helfen, aber aktuell kann ich das Problem nicht auf einen Programmteil eingrenzen.

    sg

    Donnerstag, 15. März 2018 06:56
  • Mir sind nur die allgemeinen Tools bekannt:

    https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/

    Im Falle eines Crashs wird dann ein Fenster zum Aufruf des Debuggers angeboten.
    Testweise kann man auch den ProzessExplorer von SysInternals bemühen.
    Wenn der Crash nicht zum Beenden des Prozesses führt sondern ein Fenster anzeigt, lässt sich per ProzessExplorer der Callstack dann noch anzeigen.

    Ist die Anwendung denn zwingend in 64-Bit zu fahren oder reicht ggf. nicht generell 32-Bit?

    Wenn du mit 1,4GB Speicher für die Anwendung auskommst kannst du ggf. dein Projekt fix auf i86 einstellen.
    Manchmal hat man das Problem ggf. mit Fremd-DLL's, die u.U. für bestimmte Frameworks nicht geeignet sind.

    Generell gilt nämlich:
    Innerhalb einer .NET-Anwendung können nicht verschiedene Frameworks zum Einsatz kommen.
    Welches Framework genommen wird, entscheidet der Start der EXE (Version, 32-/64-/Any).
    Jede geladene DLL wird dann ebenso mit derselben Version ausgeführt, deshalb lässt sich für Komponenten-Projekte (DLL's) die Version auch nicht festlegen.
    Bis Version 3.5 wurde dies auch durch getrennte Verzeichnisse gut realisiert.
    Seit Version 4.0 sind wir allerdings wieder in der alten DLL-Hölle, denn hier wird zur Laufzeit automatisch immer die neueste Version gezogen (4.0, 4.5, 4.6.n, 4.7) da es keine Unterscheidungen im Verzeichnis mehr gibt.
    Dies führte i.Ü. auch zu teilweisen Störungen durch die automatischen Updates zu 4.7.

    Hast du also u.U. 3.-Produkte für Framework < 3.5 im Einsatz könnten diese ggf. Inkompatibel zumindest bzgl. 64-Bit sein.
    Nun ist es ja auch so, dass selten alle Teile eines Projektes bei jedem Kunden durchlaufen werden was eben den sporadischen Fehler erklärt. das kann ich mit meinen eigenen Entwicklungen durchaus nachvollziehen.

    Donnerstag, 15. März 2018 09:35
  • Hallo Erich,

    Wie konntest du dieses Problem lösen?

    Vielen Dank.

    Montag, 22. Juli 2019 08:33