Debug .NET - System.Threading.ExecutionContext.runTryCode

Abbiamo questo bug che appare solo il 30% del tempo per la versione di rilascio. Apertura del crash dump in WinDbg (snipped uscita "analizzare -v!"):Debug .NET - 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

Ora, IsStatusOK() solo chiamate PrintSystemJobInfo.Get(), ma che non sembrano comparire anche nella pila.

Qualche idea su come eseguire il debug di questo? Sono sicuro che runTryCode() non sia davvero il problema ... ma ... sono bloccato.

Grazie! (Sto davvero brancolando qui).

fonte

2010-03-18 moogs

Dato che nessuno ha ancora risposto dopo un'ora, ti suggerirei di provare a contattare qualcuno su http://blogs.msdn.com/ntdebugging/. Per quello che vale, presumo che un puntatore a una procedura debba essere passato in runTryCode. Per qualche ragione, quel puntatore è stato criptato (sovrascritto?) E contiene 000 ... 4. Forse potresti capire quale procedura avrebbe dovuto essere chiamata e lavorare da lì per trovare chi ha sovrascritto quell'indirizzo specifico. –

Hai sempre questo esatto crash dump? Parte del problema con le violazioni degli accessi al debug è che potrebbero essere effetti collaterali di qualche altro codice che * non * si blocca ma decide di scrivere tutta la memoria di qualunque * fatto * incidente (solitamente evidenziato da arresti intermittenti e inconsistenti pila tracce). – Aaronaught

Grazie a tutti! Finalmente capito.

C'è un po 'di interoperabilità nativa in corso qui e, il GC si sta apparentemente spostando alcune variabili in memoria. Questo è quello che sta provocando il caos nella parte di Interop. Soluzione: utilizzare IntPtr o GCHandle.Alloc()

(è vero che questa risposta è stata scritta con un po 'di fretta, proverò a rispondere correttamente quando avrò tempo).

fonte

2010-03-29 06:41:41 moogs

moog hai scritto risposta in fretta, puoi scrivere una risposta e una descrizione corrette sulla soluzione che hai implementato come hai usato IntPtr e GCHandle.Alloc – dbw

Una pugnalata al buio - ma visto che è probabilmente correlato alla stampa, potrebbe essere causato da un driver di stampante dubbia?

Il problema si verifica su macchine diverse o solo su macchine specifiche?

fonte

2010-03-26 06:11:50

La violazione di accesso deve provenire dal codice nativo in modo che le strutture di dati che scorrono laggiù siano errate o che qualcosa possa esserlo nella definizione. P-invoca metodi di chiamata nativi o invia strutture dati ad altri metodi gestiti che invocano quelli nativi?

Come è indicato il thread, questo codice è in esecuzione multithreading? È possibile che tu abbia un problema di threading in cui le strutture dati che stai utilizzando per comunicare con il codice nativo sono danneggiate da altri thread?

fonte

2010-03-28 17:49:27 Tollo

Debug .NET - System.Threading.ExecutionContext.runTryCode

risposta

Problemi correlati