.NET Debugging - System.Threading.ExecutionContext.runTryCode

Wir haben diesen Fehler, der nur 30% der Zeit für den Release-Build erscheint. Öffnen der Crash-Dump in WinDbg (snipped Ausgang "analyze -v!"):.NET Debugging - System.Threading.ExecutionContext.runTryCode

FAULTING_IP: 
+4 
00000000`00000004 ??    ??? 

EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff) 
ExceptionAddress: 0000000000000004 
    ExceptionCode: c0000005 (Access violation) 
    ExceptionFlags: 00000000 
NumberParameters: 2 
    Parameter[0]: 0000000000000008 
    Parameter[1]: 0000000000000004 
Attempt to execute non-executable address 0000000000000004 
ERROR_CODE: (NTSTATUS) 0xc0000005 - 
    The instruction at 0x%08lx referenced memory at 0x%08lx. 
    The memory could not be %s. 
WRITE_ADDRESS: 0000000000000004 
MANAGED_STACK: 
(TransitionMU) 
0000000024B9E370 000007FEEDA1DD38 
    mscorlib_ni! 
    System.Threading.ExecutionContext.runTryCode(System.Object)+0x178 
(TransitionUM) 
(TransitionMU) 
0000000024B9DFB0 000007FF00439010 MyLibrary!DocInfo.IsStatusOK()+0x30

Nun IsStatusOK() nur PrintSystemJobInfo.Get() nennt, aber das scheint nicht einmal in dem Stapel erscheinen.

Irgendwelche Ideen zum Debuggen? Ich bin sicher runTryCode() ist wirklich nicht das Problem ... aber .. ich bin fest.

Danke! (Ich taste wirklich hier).

Quelle

2010-03-18 moogs

Da niemand nach einer Stunde noch geantwortet hat, würde ich vorschlagen, dass Sie versuchen würden, jemanden unter http://blogs.msdn.com/ntdebugging/ zu erreichen. Für was es wert ist, nehme ich an, dass ein Zeiger auf eine Prozedur in runTryCode übergeben werden sollte. Aus irgendeinem Grund wurde dieser Zeiger verschlüsselt (überschrieben?) Und enthält 000 ... 4. Vielleicht könnten Sie herausfinden, welche Prozedur hätte aufgerufen werden sollen und von dort aus arbeiten, um herauszufinden, wer diese spezifische Adresse überschrieben hat. –

Erhalten Sie immer genau diesen Crash Dump? Ein Teil des Problems mit dem Debugging von Zugriffsverletzungen ist, dass sie tatsächlich Nebeneffekte eines anderen Codes sein können, der * nicht * abgestürzt ist, aber sich dazu entschieden hat, über den gesamten Speicher zu kritzeln (was normalerweise durch zeitweilige Abstürze und Inkonsistenzen belegt wird) Stapelspuren). – Aaronaught

Danke allen! Endlich herausgefunden.

Es gibt einige native Interop hier und der GC bewegt sich offenbar um einige Variablen im Speicher. Dies ist derjenige, der auf der Interop-Seite Chaos anrichtet. Lösung: Verwenden Sie IntPtr oder GCHandle.Alloc()

(zugegeben, diese Antwort wurde in einer Eile geschrieben, wird versuchen, eine richtige Antwort zu füllen, wenn ich Zeit habe).

Quelle

2010-03-29 06:41:41 moogs

Moogs, die Sie in Eile geschrieben haben, können Sie eine richtige Antwort und eine Beschreibung der Lösung schreiben, die Sie verwendet haben, wie Sie IntPtr und GCHandle.Alloc verwendet haben – dbw

Ein Stich im Dunkeln - aber möglicherweise mit dem Drucken verbunden, könnte es durch einen zwielichtigen Druckertreiber verursacht werden?

Tritt das Problem auf verschiedenen oder nur auf bestimmten Computern auf?

Quelle

2010-03-26 06:11:50

Die Zugriffsverletzung muss vom systemeigenen Code kommen, so dass entweder die Datenstrukturen, die dort herunter gehen, falsch sind oder etwas an der Definition liegen könnte. Rufen Sie p-auf systemeigene Aufrufmethoden auf oder senden Sie Datenstrukturen an andere verwaltete Methoden, die die nativen aufrufen?

Da Threading erwähnt wird, wird dieser Code Multithread ausgeführt? Ist es möglich, dass Sie ein Threading-Problem haben, bei dem die Datenstrukturen, die Sie verwenden, um mit dem systemeigenen Code zu kommunizieren, von anderen Threads beschädigt werden?

Quelle

2010-03-28 17:49:27 Tollo

.NET Debugging - System.Threading.ExecutionContext.runTryCode

Antwort

Verwandte Themen