Windows-Meldung: Programm funktioniert nicht mehr

[Mossi]

Hallo zusammen,

ich bin gerade ein bisschen am verzweifeln.
Bei einer Anwendung erscheint bei ein paar einzelnen Kunden die Fehlermeldung "<Programm> funktioniert nicht mehr". Es sind wirklich nur ein paar einzelne Kunden und das Problem ist nicht bei mir nachstellbar. Bei den Kunden, bei denen das Problem aber auftritt kann man das Problem jederzeit wieder nachvollziehen, indem man das Programm einfach so ca. eine Stunde laufen lässt.

Meine erste Vermutung war ein Speicherleck. Da hab ich auch was gefunden, aber damit konnte ich das Problem leider nicht lösen (Das Speicherleck wäre ohnehin harmlos gewesen, aber wieder eine Fehlerquelle weniger)
Dann hab ich mir gedacht, vielleicht irgendein Thread, der einen Fehler wirft. Also mal alle Threads mit Protokollierung versehen, aber wieder nix.
Generell hab ich sehr viel Logging in der Anwendung und dabei ist mir aufgefallen, dass der Fehler auch im Ablauf vollkommen zufällig auftritt. Also nicht immer an der gleichen Stelle sondern eben irgendwo, wo er gerade lustig ist.

Für die Fehlerausgabe verwende ich MadExcept, aber das spuckt mir da nichts aus.
Ansonsten wird in der Software sehr viel mit Bildern gearbeitet. Die Bilder kommen aus einer Datenbank (Advantage) und haben sind entweder JPG oder ein paar wenige PNG. Für das Handling mit den PNG-Bildern verwende ich die GR32 Grafik-Bibliothek. Und eben jede Menge GDI-Anweisungen, aber bisher hatte ich damit eigentlich auch keine Probleme.

Der Fehler tritt aktuell nur bei Windows 7 Betriebssystemen auf. Wobei mir mein Bauchgefühl sagt, dass das Zufall ist.

Die Ereignisanzeige von Windows ist irgendwie auch wenig hilfreich

Code:

Name der fehlerhaften Anwendung: pc_professional.exe, Version: 16.0.0.50, Zeitstempel: 0x2a425e19
Name des fehlerhaften Moduls: unknown, Version: 0.0.0.0, Zeitstempel: 0x00000000
Ausnahmecode: 0xc0000005
Fehleroffset: 0xb801eb11
ID des fehlerhaften Prozesses: 0x1998
Startzeit der fehlerhaften Anwendung: 0x01d3c692f34c5c56
Pfad der fehlerhaften Anwendung: <pfad>\pc_professional.exe
Pfad des fehlerhaften Moduls: unknown
Berichtskennung: 974e1817-328e-11e8-aaff-bc05430820ea

Wie kann ich denn noch nach der Ursache des Fehlers suchen? Hat da vielleicht jemand eine Idee?

[Jasocul]

Zitat von Mossi:

kann man das Problem jederzeit wieder nachvollziehen, indem man das Programm einfach so ca. eine Stunde laufen lässt.

Klingt für mich verdächtig nach einem Timeout.
Wird vielleicht die Verbindung zur DB nach einer Stunde getrennt, wenn dort nichts gemacht wird?

[Der schöne Günther]

Die einfachste Möglichkeit den "Programm funktioniert nicht mehr"-Dialog auftreten zu lassen ist wenn eine Exception das OnTerminate -Event eines Threads verlässt. Vielleicht hilft das?

[Mossi]

Danke für die Antworten.

Zitat von Jasocul:

Zitat von Mossi:

kann man das Problem jederzeit wieder nachvollziehen, indem man das Programm einfach so ca. eine Stunde laufen lässt.

Klingt für mich verdächtig nach einem Timeout.
Wird vielleicht die Verbindung zur DB nach einer Stunde getrennt, wenn dort nichts gemacht wird?

Ich kann mir nicht vorstellen, dass es damit zusammenhängt. Es handelt sich dabei um eine filebasierte Datenbank und die verwenden wir schon seit mehr als 10 Jahren in dieser Art. Das Problem müsste außerdem dann nachvollziehbar sein. Desweiteren wird immer auf die Datenbank zugegriffen (alle drei Sekunden wird ein Bild abgerufen)
Ich hatte im Vorfeld schon die Vermutung, dass die Datenbank-Datei vielleicht beschädigt ist und habe diese nochmal neu kopiert und per Filehash geprüft.

Außerdem: Würde ein Timeout nicht eine vernünftige Exception werfen, die ich dann per MadExcept angezeigt bekomme?

Zitat von Der schöne Günther:

Die einfachste Möglichkeit den "Programm funktioniert nicht mehr"-Dialog auftreten zu lassen ist wenn eine Exception das OnTerminate -Event eines Threads verlässt. Vielleicht hilft das?

Versteh ich jetzt glaub ich nicht ganz.
Du meinst also, dass in einem Thread im OnTerminate eine Exception auftritt und diese dann eben nicht korrekt abgefangen wird. Das kann ich mal prüfen, ob da überall ein sauberes Exception-Handlung drin ist. Würde das auch gelten, wenn OnTerminate gar nicht registriert ist?
Ist vielleicht ein Ansatz.

[Der schöne Günther]

Nein, OnTerminate muss schon zugewiesen sein.

Ich erkenne mich nur insofern wieder als ich genau so etwas auch mal hatte. Das Exception-Tracking der JCL hatte nichts mehr geloggt, aber das Programm verabschiedete sich definitiv mit "Programm funktioniert nicht mehr". Ursache war eine Exception im OnTerminate -Event eines Threads.

[Mossi]

War wohl nix... OnTerminate hab ich nur relativ selten benutzt und die haben alle ein sauberes Exception-Handlung oder machen nur simple Zuweisungen bei denen keine Exception auftreten kann.

Gibt es bei diesem Fehler nicht irgendwo einen Dump, den man analysieren kann? Ähnlich wie bei Windows Bluescreens.

[EWeiss]

Zitat von Mossi:

War wohl nix... OnTerminate hab ich nur relativ selten benutzt und die haben alle ein sauberes Exception-Handlung oder machen nur simple Zuweisungen bei denen keine Exception auftreten kann.

Gibt es bei diesem Fehler nicht irgendwo einen Dump, den man analysieren kann? Ähnlich wie bei Windows Bluescreens.

Ja..
C:\Users\Username\AppData\Local\CrashDumps

gruss

[KodeZwerg]

Könnte es sein das da wo dein Programm auf Daten zugreifen möchte, bei Wiederholten Aufruf der Cache benutzt wird und beim Nachladen nach einer Stunde ist der Festspeicher im Standby, womit dein Programm nicht klarkommt?
(Will was lesen von Quelle - im ersten Moment fehlt's - da Gerät im Standby)

[Mossi]

Zitat von KodeZwerg:

Könnte es sein das da wo dein Programm auf Daten zugreifen möchte, bei Wiederholten Aufruf der Cache benutzt wird und beim Nachladen nach einer Stunde ist der Festspeicher im Standby, womit dein Programm nicht klarkommt?
(Will was lesen von Quelle - im ersten Moment fehlt's - da Gerät im Standby)

Kann ich mir nicht vorstellen. Ich hab vorhin nebenbei auf dem Rechner "gearbeitet", also Dumps analysiert und Registry und Files mit einem anderen Rechner verglichen und auch währenddessen trat dann genau dieser Fehler auf. Aber die Idee ist gut. Hatte ich so noch nie, aber vielleicht kann man die Info mal brauchen

Die Analyse der Dumps war leider auch wenig erfolgreich.

Code:

Call stack with StackWalk


Index

Return Address

1 0x80000000`00000000 (0x00000000) 
2 0x000425e8 (0x000425e8) 
3 0x0015ca00 (0x0015ca00) 
4 0x110003e0 (0x110003e0) 
5 0x80000000`00000000 (0x00000000) 
6 0x08be1b1b (0x08be1b1b) 
7 pc_professional+37a5fb (0x0077a5fb) 
8 0x80000000`00000000 (0x00000000) 
9 0x80000000`00000000 (0x00000000) 
10 clrjit!Compiler::psiNewPrologScope+10 [f:\dd\ndp\clr\src\jit32\scopeinfo.cpp @ 910 + 9] (0x70be1b0b) 
11 0x1e055bfd (0x1e055bfd) 
12 0x80000000`00000000 (0x00000000) 
13 pc_professional+7ab7fa (0x00bab7fa) 
14 0x04000000 (0x04000000) 
15 0x4b000000 (0x4b000000) 
16 0x80000000`00000000 (0x00000000) 
17 0x80000000`00000000 (0x00000000) 
18 0x0c003020 (0x0c003020) 
19 0x28755511 (0x28755511) 
20 0x34003041 (0x34003041) 
21 0x08fffffd (0x08fffffd) 
22 xpdfviewerctrl (0x10000000) 
23 0x80000000`00000000 (0x00000000) 
24 0x4c000002 (0x4c000002) 
25 0x40000000 (0x40000000) 
26 0x1a000001 (0x1a000001) 
27 0x2277a5fb (0x2277a5fb) 
28 pc_professional+137a5fa (0x0177a5fa) 



Call stack - Heuristic


Index

Stack Address

Child EBP

Return Address

Destination

1 0x00000000`00000000 0x00000000`3c055bfd 0x00000000 0x00000000 

                       ^ Memory access error in 'u 0x000425e8  l1'
                       ^ Memory access error in 'u 0x0015ca00  l1'
                       ^ Memory access error in 'u 0x110003e0  l1'

Das es sich um einen memory access error handelt, hab ich davor auch schon gewusst durch den Fehlercode c0000005
Ich hab jetzt nochmal eine Version mit Debug-Symbolen zum Kunden kopiert und hoffe, dass ich dann mehr rauslesen kann. Aber irgendwie hab ich die dumme Vermutung, dass der Fehler jetzt nicht mehr auftreten wird... ein Bauchgefühl.

Aber beim analysieren der Dumps ist mir noch was anderes aufgefallen. Vielleicht hat da jemand eine Info, was das bedeuten könnte:
Ganz am Ende gibt es den Abschnitt "Analysis Rule Summary" und der sieht folgendermaßen aus:

Code:

CrashHangAnalysis - v (2.2.0.14) Failed Dump File:  D:\PC_Professional.exe.1788.dmp;

Type:  System.OverflowException

Message:  Der Wert für einen Int32 war zu groß oder zu klein.

Stack Trace:
 bei System.Convert.ToInt32(Double value)
 bei DebugDiag.AnalysisRules.StackFunctions.AnalyzeCorruptStack(ScriptThreadClass Thread)
 bei DebugDiag.AnalysisRules.AnalyzeCrash.AnalyzeAV(NetDbgException ExceptionObj, ScriptThreadClass ExceptionThread, Boolean suppressSummary)
 bei DebugDiag.AnalysisRules.AnalyzeCrash.AnalyzeException(NetDbgException ExceptionObj, ScriptThreadClass ExceptionThread, Boolean suppressSummary)
 bei DebugDiag.AnalysisRules.AnalyzeCrash.AnalyzeExceptionThread(ScriptThreadClass Thread)
 bei DebugDiag.AnalysisRules.CrashHangAnalysis.RunAnalysisRule(NetScriptManager manager, NetProgress progress)
 bei DebugDiag.DotNet.NetAnalyzer.RunAnalysisRulesInternal(DumpFileType bitness, NetProgress progress, String symbolPath, String imagePath, String reportFileFullPath, Boolean twoTabs, AnalysisModes analysisMode)

Intuitiv würde ich da jetzt sagen, dass es sich dabei um eine Exception vom DebugDiag handelt, die nichts mit meiner Anwendung zu tun hat. Oder lieg ich dabei falsch? Ansonsten müsste ich danach suchen, wo ich in einer .NET Assembly einen falschen Int zuweise und das wird dann endgültig keinen Spaß mehr machen.

[ConstantGardener]

....haben die Kunden evtl. TeamViewer (und hier die QuickConnect-Schaltfläche) am laufen. Hatte letztens genau dieses Verhalten, wenn das Dingen sich in die Systemleiste eingeklinkt hatte. Danach habe ich meine Anwendung in die Ausnahmenliste dieser TeamViewer-Funktion (es gibt recht viele unverträgliche Programme) verfrachtet und schon ging es. Aber finde sowas mal...

cu cg