Windows-Meldung: Programm funktioniert nicht mehr

[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.