Violazione di accesso nel codice che non è mio

Question

Non sono sicuro di come eseguire il debug di questo. Ho un programma C# composto interamente da codice gestito, eseguito in .NET 4.5. Dopo averlo eseguito per un po ', in un momento apparentemente casuale, ricevo un errore "Un'eccezione non gestita di tipo' System.AccessViolationException 'si è verificata in mscorlib.dll". Dal momento che sono in esecuzione da Visual Studio (2012) clicco "break" e sono presentato con il seguente stack di chiamate:

mscorlib.dll!System.Threading._IOCompletionCallback.PerformIOCompletionCallback(uint errorCode, uint numBytes, System.Threading.NativeOverlapped* pOVERLAP) + 0x47 bytes  
[Native to Managed Transition] 
ntdll.dll!_NtRequestWaitReplyPort@12() + 0xc bytes 
kernel32.dll!_ConsoleClientCallServer@16() + 0x4f bytes  
kernel32.dll!_GetConsoleLangId@4() + 0x2b bytes  
kernel32.dll!_SetTEBLangID@0() + 0xf bytes 
KernelBase.dll!_GetModuleHandleForUnicodeString@4() + 0x22 bytes 
mdnsNSP.dll!7177aa48() 
[Frames below may be incorrect and/or missing, no symbols loaded for mdnsNSP.dll] 
mdnsNSP.dll!71775b06() 
mdnsNSP.dll!71774ded() 
mdnsNSP.dll!71774e8c() 
bcryptprimitives.dll!746d1159()  
bcryptprimitives.dll!746d1137()  
ntdll.dll!_LdrpCallInitRoutine@16() + 0x14 bytes 
ntdll.dll!_NtTestAlert@0() + 0xc bytes 
ntdll.dll!_NtContinue@8() + 0xc bytes 
ntdll.dll!_LdrInitializeThunk@8() + 0x1a bytes 

Una cosa interessante che ho notato è che nulla nello stack di chiamate è il mio codice.

Quale strategia consiglieresti di utilizzare per trovare il percorso del problema? O hai visto un problema simile a questo e hai qualche consiglio?

Poiché l'eccezione non sembra includere il mio codice, non so quali informazioni includere che sarebbero utili nel rispondere alla domanda, ma chiedetemi se c'è qualcos'altro che dovrei includere.

Poiché l'errore può essere correlato IO (poiché PerformIOCompletionCallback è in cima alla pila), questo è un elenco delle attività tipiche IO quali l'applicazione esegue:

• TcpListener.AcceptTcpClientAsync
• NetworkStream. scrivere/BeginRead/EndRead
• SqlCommand.BeginExecuteReader/EndExecuteReader
• StreamWriter.WriteLine

Altre note:

• sembra essere grosso modo ripetibile - ottengo lo stesso errore nello stesso luogo (PerformIOCompletionCallback), ma devono aspettare una lunghezza diversa di tempo per farlo (nell'ordine di minuti) .
• Non penso di poter produrre un piccolo programma che evidenzia in modo affidabile il problema. Il mio programma gestisce molte migliaia di operazioni di I/O simili prima di raggiungere questo errore.

Edit:

Sulla base del suggerimento di @ Kevin che Mdnsnsp.dll è da Bonjour, ho disinstallato Bonjour e ha cercato di nuovo. L'eccezione persiste, ma lo stack di chiamate è molto più pulito:

mscorlib.dll!System.Threading._IOCompletionCallback.PerformIOCompletionCallback(uint errorCode, uint numBytes, System.Threading.NativeOverlapped* pOVERLAP) + 0x47 bytes  
[Native to Managed Transition] 
kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes  
ntdll.dll!___RtlUserThreadStart@8() + 0x27 bytes 
ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes  

Sto assumendo l'installatore Bonjour installato qualche DLL gancio benigna per il traffico di rete, ma disinstallazione non ha risolto il problema.

Edit:

ho temporaneamente ri-codificato tutti i miei unsafe funzioni utilizzando lenti liquide "sicuri" per eliminare che come un sospetto. Ora nessuno degli assembly nell'applicazione è compilato utilizzando un interruttore non sicuro. Il problema persiste ancora. Per reiterare, ora non ho alcun codice non sicuro, nessun codice nativo e nessuna chiamata P/Invoke (nel codice utente) in questa applicazione, ma sto ancora vivendo il AccessViolationException come descritto sopra.

Answer 1

È possibile utilizzare debugdiag per vedere che cosa causa AccessViolationException sulla macchina. Configurare una regola di arresto anomalo per il processo ed esaminare i file di dump e di registro.Spero che riceverai più informazioni sull'argomento in questo modo. Assicurati inoltre che la tua macchina esegua gli ultimi aggiornamenti di Windows. Bcos Ho riscontrato un problema simile risolto in un aggiornamento di sicurezza per la versione CLR.

Answer 2

non so se può aiutarti ma sembra che abbiamo affrontato un problema simile diversi anni fa. Poiché ricordo che le nostre indagini puntavano su dll in altri programmi, abbiamo rilevato che le violazioni di accesso alla memoria possono essere causate da antivirus (NOD32 nel nostro caso), firewall o sniffer di rete/controllori del traffico.

Provare a controllare il registro delle applicazioni (Pannello di controllo -> Sistema e sicurezza -> Strumenti di amministrazione -> Visualizzatore eventi) per gli errori causati dalle applicazioni di cui sopra. Se il problema è con un altro programma, prova a disabilitarlo/disinstallarlo e controlla di nuovo se il crash continua a comparire nel tuo programma.

UPD Hai provato a riprodurre questo problema nell'ambiente di test pulito?

Answer 3

Poiché il suo PerformIOCompletionCallback causa l'errore, guarderei le mie chiamate IO asincrone.

• TcpListener.AcceptTcpClientAsync
• NetworkStream.Write/BeginRead/EndRead
• SqlCommand.BeginExecuteReader/EndExecuteReader

L'errore sembra accadere perché il manico che è stato registrato non è più valido. Poiché sta accadendo nel codice gestito, la causa sarà da un oggetto gestito e NON da una DLL nativa di terze parti.