.NET Debugging - System.Threading.ExecutionContext.runTryCode

Tenemos este error que solo aparece el 30% del tiempo para la versión de lanzamiento. La apertura de la de volcado en WinDbg (cortado con tijeras de salida "analizar -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

Ahora, IsStatusOK() simplemente llama PrintSystemJobInfo.Get(), pero que no parecen aparecer incluso en la pila.

¿Alguna idea sobre cómo depurar esto? Estoy seguro de que runTryCode() realmente no es el problema ... pero ... estoy atascado.

Gracias! (Estoy realmente buscando a tientas aquí).

Fuente

2010-03-18 moogs

Como nadie ha respondido aún después de una hora, le sugiero que intente comunicarse con alguien en http://blogs.msdn.com/ntdebugging/. Por lo que vale, supongo que se debe pasar un puntero a un procedimiento en runTryCode. Por alguna razón, ese puntero se revolvió (¿se sobrescribió?) Y contiene 000 ... 4. Quizás puedas averiguar qué procedimiento debería haberse llamado y trabajar desde allí para encontrar quién ha sobrescrito esa dirección específica. –

¿Siempre obtiene este volcado de emergencia exacto? Parte del problema con las infracciones de acceso a la depuración es que en realidad pueden ser efectos colaterales de otro código que * no * se bloqueó, pero decidieron garabatear todo el recuerdo de lo que * se * bloqueó (generalmente evidenciado por bloqueos intermitentes e inconsistentes rastros de pila). – Aaronaught

¡Gracias a todos! Finalmente lo descubrí.

Aquí hay algo de interoperabilidad nativa y, al parecer, el GC está moviendo algunas variables en la memoria. Este es el que está causando estragos en el lado de Interop. Solución: Use IntPtr o GCHandle.Alloc()

(sin duda, esta respuesta fue escrita con un poco de prisa, intentará completar una respuesta correcta cuando tenga tiempo).

Fuente

2010-03-29 06:41:41 moogs

moogs que ha respondido por escrito con prisa, ¿puede escribir una respuesta adecuada y una descripción de la solución en la que ha implementado cómo utilizó IntPtr y GCHandle.Alloc? – dbw

Una puñalada en la oscuridad, pero dado que posiblemente esté relacionada con la impresión, ¿podría ser causada por un controlador de impresora poco fiable?

¿El problema ocurre en máquinas diferentes o solo en algunas específicas?

Fuente

2010-03-26 06:11:50

La infracción de acceso debe provenir del código nativo, por lo que las estructuras de datos que se despliegan son incorrectas o puede haber algo sobre la definición. ¿Hace una invocación p a los métodos de llamada nativos o envía estructuras de datos a otros métodos administrados que invocan a los nativos?

Como se menciona el roscado, ¿se está ejecutando este código multiproceso? ¿Es posible que tenga un problema de subprocesamiento donde las estructuras de datos que está utilizando para hablar con el código nativo están siendo corrompidas por otros subprocesos?

Fuente

2010-03-28 17:49:27 Tollo

.NET Debugging - System.Threading.ExecutionContext.runTryCode

Respuesta

Cuestiones relacionadas