Windows-Meldung: Programm funktioniert nicht mehr

[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

[Jasocul]

Vielleicht stochere ich jetzt ein wenig im Nebel, aber die Zeile 10 im Dump und der Hinweis, dass du .Net-Assemblies eingebunden hast, könnte auch auf Probleme mit dem Garbage-Collector oder clrjit Dll hinweisen.

[Mossi]

Zitat von 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

Das hatte ich auch schon mal vor einiger Zeit. Ist's aber in diesem Fall nicht.

Zitat von MichaelT:

Das irritiert mich auch ein bisschen, was diese Methode machen soll und hab auch keine weiteren Informationen dazu gefunden. Ich find auch keinen Hinweis darauf, welche Assembly da aufgerufen werden sollte. ich verwende zwar ein paar Assemblies, aber die haben ebenfalls alle ein Logging drin und da finde ich nirgends ein Problem.
RuntimeDLLs hab ich bereits geprüft. Die sollten passen.

Von den Betriebssystemen kann ich es mittlerweile einschränken auf Windows 7 64 Bit. Weitere Einschränkung. Es handelt sich immer um Core2Duo Prozessoren. Aber es fehlen noch weitere Einschränkungen, weil es bei anderen Kunden mit gleicher Hardware keine Probleme gibt. Weitere Gemeinsamkeiten konnte ich jetzt noch nicht finden.

Ist auch schwierig auszuprobieren, weil das Problem eben immer erst nach ca. einer Stunde auftritt. Das macht das Fehlersuchen nicht gerade einfacher.

[MichaelT]

Deswegen auch meine Vermutung.

Ich kenne das Sterben bspw. wenn ich einen Apache oder ein PHP nehme und manuell installiere.

Die Funktion kommt vermutlich aus dem Kernel direkt. Müssen wir mal schauen.

Handelt es sich um ein 32-bit Anwendung (also deine ist gemeint).

Das gab es mal Troubles mit .net auf Win64 und Core Duo. Erkennen der Bittigkeit des Prozessors usw...

Ich bin kein Systemhacker. Deswegen bin ich nicht immer so up to date mit den letzen Entwicklungen.

Zitat von Mossi:

Von den Betriebssystemen kann ich es mittlerweile einschränken auf Windows 7 64 Bit. Weitere Einschränkung. Es handelt sich immer um Core2Duo Prozessoren. Aber es fehlen noch weitere Einschränkungen, weil es bei anderen Kunden mit gleicher Hardware keine Probleme gibt. Weitere Gemeinsamkeiten konnte ich jetzt noch nicht finden.

Ist auch schwierig auszuprobieren, weil das Problem eben immer erst nach ca. einer Stunde auftritt. Das macht das Fehlersuchen nicht gerade einfacher.

[Mossi]

Zitat von MichaelT:

Es handelt sich um eine 32 Bit Anwendung.

Mittlerweile hab ich evtl. eine Vermutung, an was es liegt. Wenn das aber zutrifft, wäre es fast so wie ein 6er Im Lotto (hätte vielleicht doch spielen sollen)
Was ich bisher noch nicht erwähnt habe: Das Programm ist mit Codemeter (einem Hardware-Dongle) verschlüsselt. Diese Verschlüsselung prüft in gewissen Zeitabständen, ob der Dongle noch vorhanden ist. Scheinbar überschneidet sich das genau mit dem erwähnten Fehler.
Dazu kommt noch eine Info von einem Kunden, dass der immer wieder mal Probleme mit seinem Dongle hat, dass der plötzlich nicht mehr erkannt wird und er ihn dann erst ein paar mal ein und ausstecken muss, bis er wieder funktioniert.
Hört sich alles sehr verdächtig an.

Desweiteren wie ich bereits vermutet habe (mein Bauchgefühl eben), tritt der Fehler jetzt mit den Debug-Symbolen nicht auf. Dazu muss ich sagen, dass ich diese Version mit den Debug-Symbolen auch nicht verschlüsselt habe.

Ende vom Lied: Ich hab jetzt einem Kunden eine unverschlüsselte Version zur Verfügung gestellt und der probiert jetzt heute Abend, ob das Problem damit dann immer noch auftritt.

[MichaelT]

Ok. Das wäre aber schon mal verdächtig. Timeout ist immer heiß. Die Funktion kommt nicht zurück, daraufhin ist Sense.

Erklärt nicht so wirklich, warum das bei dir reproduzierbar auf den (Test)Rechnern genauso nicht funktioniert. Außer die Rechner wären alle halbwegs gleich.

Ich halte die Daumen, aber ganz so sicher bin ich mir nicht.

Win64 auf einem Core Duo habe/hatte ich nicht (mehr) nur auf ein Quad Core Phenom.

Mein XPS Laptop aus dieser Zeit lässt sich nicht hinter 4GB aufrüsten und es macht wenig Sinn dies zu tun. Der muss immer herhalten für meine Experimente mit Millionen von Records und Bäumen, damit ich überhaupt mal ans Speicherlimit komme und dann habe ich einen mit einem gepatchten Kernel (aber Win32) und der läuft auf einem alten AMD Phenom.

Mir wäre nie aufgefallen, dass .net selbst auf den Rechner ein weitreichenderes Problem gehabt hätte. Win 7 64 auf den Rechnern kenne ich so gut wie nicht. Mir wäre aber auch nicht aufgefallen, dass ein Delphi Programm in einer 32-bit 'Box' mit 4GB Speicher Probleme gemacht hätte egal ob auf Win 64 oder gepatchten Kernel. Würde der Speicher zusehends voller, dann ginge der Rechner zuerst merklich in die Knie.

Heiteres Raten ist trotzdem immer lustig.

Zitat von Mossi:

Zitat von MichaelT:

Hört sich alles sehr verdächtig an.

Desweiteren wie ich bereits vermutet habe (mein Bauchgefühl eben), tritt der Fehler jetzt mit den Debug-Symbolen nicht auf. Dazu muss ich sagen, dass ich diese Version mit den Debug-Symbolen auch nicht verschlüsselt habe.

Ende vom Lied: Ich hab jetzt einem Kunden eine unverschlüsselte Version zur Verfügung gestellt und der probiert jetzt heute Abend, ob das Problem damit dann immer noch auftritt.