Debug di arresto anomalo di Winform – C #

System.AccessViolationException was unhandled Message=Attempted to read or write protected memory. This is often an indication that other memory is corrupt. Source=System.Windows.Forms StackTrace: at System.Windows.Forms.UnsafeNativeMethods.PeekMessage(MSG& msg, HandleRef hwnd, Int32 msgMin, Int32 msgMax, Int32 remove) at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData) at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context) at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context) at System.Windows.Forms.Application.Run(Form mainForm) at ABC.Program.Main() in C:\Documents and Settings\...\Program.cs:line 17 InnerException: 

Questa eccezione difficile da riprodurre è molto imprevedibile. Ho collegato il mio debugger di Visual Studio e ho eseguito il test 7-10 volte ed è stato in grado di catturare con successo questa traccia dello stack. Si noti che niente di questo è il mio codice, quindi qualcosa di spettrale accade a livello di Windows. BTW usiamo PInvoke per aprire / chiudere windows come iexplore, blocco note ecc.

Dopo un po ‘- search – e sulla base del consiglio fornito da quel ragazzo di Microsoft ho provato ADPlus per ottenere il dump di memoria e Windbg da analizzare, ma le informazioni che ricevo dal windbg sono ancora più criptici rispetto all’eccezione stessa.

 This dump file has an exception of interest stored in it. The stored exception information can be accessed via .ecxr. (904.1cf4): Access violation - code c0000005 (first/second chance not available) eax=003c4d10 ebx=00000000 ecx=00000000 edx=00000000 esi=003c4d2a edi=0012f1a0 eip=003c4b64 esp=0012f11c ebp=0012f138 iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246 003c4b64 8b410c mov eax,dword ptr [ecx+0Ch] ds:0023:0000000c=???????? 0:000> .ecxr eax=003c4d10 ebx=00000000 ecx=00000000 edx=00000000 esi=003c4d2a edi=0012f1a0 eip=003c4b64 esp=0012f11c ebp=0012f138 iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246 003c4b64 8b410c mov eax,dword ptr [ecx+0Ch] ds:0023:0000000c=???????? 

Ci possono essere degli esperti che possono dare l’impressione di questa informazione, non posso.

Quindi, cosa fate voi ragazzi per analizzare questo tipo di problemi? Qualcosa come un “heap dump analyzer per JVM” per .Net?

Ambiente: Windows XP SP3 [accesso completo, admin]

In Visual Studio, vai alle proprietà del progetto e triggers il “degrocaggio del codice non gestito”, quindi avvia il debugger.

[non so se è necessario eseguire il passaggio successivo, ma l’ho appena fatto] eseguire. caricare SOS.dll nella finestra Immediata di Visual Studio

Sono stato in grado di trovare la causa principale del problema : è stata effettuata una richiamata su un delegato garbage collection di tipo “ABC.Form1 + SendMessageDelegate :: Invoke”. Ciò potrebbe causare arresti anomali dell’applicazione, danneggiamento e perdita di dati. Quando si passano i delegati al codice non gestito, devono essere tenuti in vita dall’applicazione gestita finché non viene garantito che non verranno mai chiamati.

Grazie a tutti coloro che hanno inviato una risposta o commenti.