WinDbg - TraceListener e saturi ThreadPool

Question

Ho un multithreading .NET servizio Windows che si blocca a intermittenza - forse una volta ogni due settimane di funzionamento 24/7. Quando si blocca verifica ThreadPool è completamente saturo, perché le chiamate al nostro costume TraceListener iniziano bloccando per qualche motivo. Non ci sono le serrature nel codice incriminato, né nulla di blocco in base alla windbg, ma sono sicuramente il blocco da qualche parte. Non ci sono eccezioni nello stack sia. C'è un Thread.Sleep (1), che a volte si ha colpito nel codice BufferedStream.Write, ma la mia domanda è che cosa è il ReOpenMetaDataWithMemory, CreateApplicationContext, e DllCanUnloadNow dire?

Quasi tutti i 2.000 appeso thread di lavoro (! Non funzionamento normale) sul ThreadPool hanno uno stack simile al seguente:

0:027> !dumpstack
OS Thread Id: 0x1638 (27)
Child-SP         RetAddr          Call Site
000000001d34df58 0000000077d705d6 ntdll!ZwDelayExecution+0xa
000000001d34df60 000006427f88901d kernel32!SleepEx+0x96
000000001d34e000 000006427f454379 mscorwks!DllCanUnloadNowInternal+0xf53d
000000001d34e080 000006427fa34749 mscorwks!CreateApplicationContext+0x41d
000000001d34e0e0 0000064280184902 mscorwks!ReOpenMetaDataWithMemory+0x1ff59
000000001d34e290 0000064280184532 Company_Common_Diagnostics!Company.Common.Diagnostics.BufferedStream.Write(Byte[], Int32, Int32)+0x1b2
000000001d34e300 00000642801831fd Company_Common_Diagnostics!Company.Common.Diagnostics.XmlRollingTraceListener+TraceWriter.Write(System.String)+0x52
000000001d34e350 00000642801b3304 Company_Common_Diagnostics!Company.Common.Diagnostics.XmlRollingTraceListener.InternalWrite(System.Text.StringBuilder)+0x3d
000000001d34e390 0000064274e9d7ec Company_Common_Diagnostics!Company.Common.Diagnostics.XmlRollingTraceListener.TraceTransfer(System.Diagnostics.TraceEventCache, System.String, Int32, System.String, System.Guid)+0xc4
000000001d34e410 00000642801b2f59 System_ni!System.Diagnostics.TraceSource.TraceTransfer(Int32, System.String, System.Guid)+0x2ec

Answer 1

capito credo. Ho preso l'BufferStream e ho visto che era in uno stato in cui tutto ciò che ha chiamato in TraceListener sarebbe solo rimanere bloccati in un Thread.Sleep (1) loop. Spero che questo sia la correzione perché non posso per la vita di me ricreare il problema.

ho avuto usegloballock = false e autoflush = true nella configurazione traccia. Il metodo di colore al TraceListener non è stato thread-safe - l'ascoltatore ha lo scopo di utilizzare il buffer dei dati, in modo a volte la TraceListener otterrebbe in cattivo stato quando c'era concorrenza delle vampate e scrive. La correzione è stato quello di impostare semplicemente autoflush = false. Non posso credere che non ho capito questo prima.

Answer 2

Non proprio una risposta, ma qualcosa da controllare ...

Assicurarsi che non si ha ancora la DefaultTraceListener registrata nell'origine traccia. Se non lo fai in modo esplicito Cancella o Rimuovi DefaultTraceListener può ancora essere lì. Il DefaultTraceListener 's IsThreadSafe i rendimenti di proprietà false , nel qual caso le classi System.Diagnostics.Trace creano un Blocco () in tutto il TraceEvent () le chiamate ..

Solo una cosa da guardare fuori per.

Ulteriori informazioni:

TraceListener.IsThreadSafe Proprietà

  

Il valore di IsThreadSafe viene utilizzato per determinare se utilizzare un blocco globale durante la scrittura per l'ascoltatore. Se il valore di IsThreadSafe è falsa, il blocco globale viene utilizzato indipendentemente dal valore di UseGlobalLock. Il blocco globale non viene utilizzato solo se il valore di IsThreadSafe è vero e il valore di UseGlobalLock è falso. Il comportamento predefinito è quello di utilizzare il blocco globale ogni volta che la scrittura per l'ascoltatore.

Grazie, Aaron

Answer 3

Il fatto che compensato in queste funzioni sembrano modo per i grandi (mscorwks! ReOpenMetaDataWithMemory + 0x1ff59), dirò non si dispone di simboli per mscorwks.

Imposta un negozio simbolo locale tramite:

.symfix + c: \ websymbols
.reload Mscorwks.dll

dove c: \ websymbols è un percorso di vostra scelta per i simboli del sistema. Che dovrebbe darvi i nomi delle funzioni ragionevoli dove kernel32! Il sonno viene richiamato dalla.

Per quanto riguarda il resto, che cosa fa uno stack per tutti gli altri appeso le discussioni assomigliano? Inoltre, si potrebbe inviare uno stack nativo (kb) così?

Answer 4

Hai ragione.

Ci sono circa 2000 appeso le discussioni e l'analisi dello stack su di essi è quasi identico. C'è una funzione KeepAlive nel codice che dings ogni 1 secondo. C'è un monitor.tryenter intorno al codice ding. Se non è possibile acquisire il blocco emette una traccia. Questo è ciò che tutte queste discussioni stanno facendo. Il filo che ha il blocco (18) ha la stessa analisi dello stack più o meno.

C'è un modo per vedere le variabili locali in classe BufferedStream per vedere se è bloccato in un ciclo?

0:047> kb
RetAddr           : Args to Child                                                           : Call Site
00000000`77d705d6 : ffffffff`fffffffe 00000000`00000000 00000000`00000000 00000000`1ef7f160 : ntdll!ZwDelayExecution+0xa
00000642`7f88901d : 00000000`00000029 00000642`00000001 00000000`00000000 00000000`1c00f820 : kernel32!SleepEx+0x96
00000642`7f454379 : 00000000`00c70128 00000642`7fa2b159 00000000`00000001 00000000`00000001 : mscorwks!EESleepEx+0x2d
00000642`7fa34749 : 06000000`00000001 00000000`1c00f820 00000000`00c6ff08 00000000`00000001 : mscorwks!Thread::UserSleep+0x71
00000642`80184902 : 00000000`00000001 00000642`782f1950 00000000`015695e0 00000000`00000000 : mscorwks!ThreadNative::Sleep+0xf9
00000642`80184532 : 00000000`00c6fe90 00000642`783924e2 00000000`00db11d8 00000000`00000008 : 0x642`80184902
00000642`801831fd : 00000000`00c6fe90 00000000`00000008 00000642`80043680 00000000`00c02d58 : 0x642`80184532
00000642`74e9e494 : ffffffff`fffffffe 00000000`00000001 0000c0c9`0263a71f 00000642`7f361300 : 0x642`801831fd
00000642`8018d3d3 : 00000000`00c02d58 00000000`00000008 00000000`00000000 00000000`00db11d8 : System_ni+0x61e494
00000642`782f173b : 00000000`00c036a0 00000642`7834901c 00000642`78431598 00000000`77ef9971 : 0x642`8018d3d3
00000642`7834d696 : 00000000`00a061b0 00000000`00400080 00000000`00000000 00000642`7f529408 : mscorlib_ni+0x2f173b
00000642`7f602672 : 00000000`00db0cb8 000007ff`7d370000 000007ff`7d370000 000007ff`fffdb000 : mscorlib_ni+0x34d696
00000642`7f50c053 : 00000642`7f39f3f6 00000000`77dbc178 00000000`00000000 00000000`00000000 : mscorwks!CallDescrWorker+0x82
00000642`7f51449a : 00000000`1ef7f9f8 ffffffff`fffffffe 00000000`00000000 00000000`77d6f447 : mscorwks!CallDescrWorkerWithHandler+0xd3
00000642`7f46b023 : 00000000`00000001 00000000`77d6f491 00000000`00000000 00000000`1ee81000 : mscorwks!DispatchCallDebuggerWrapper+0x3e
00000642`7f41729e : 00000000`1ef7fb88 00000000`1c00f801 00000000`00000001 00000000`1c00f820 : mscorwks!DispatchCallNoEH+0x5f
00000642`7f447ee8 : 00000000`00db0cb8 00000000`00db0cb8 00000000`00000001 00000642`7f50946a : mscorwks!AddTimerCallback_Worker+0x92
00000642`7f556aa9 : 00000000`00000001 00000000`00000000 ffffffff`fffffffe 00000000`1ef7fba8 : mscorwks!Thread::DoADCallBack+0x488
00000642`7f43afdd : 00000000`001597d0 00000000`1c00f820 00000000`1ef7fab0 00000000`0019fcb0 : mscorwks!CNgenEntryBind::Create+0x15d
00000642`7f435296 : 00000000`1ef7fba8 ffffffff`ffffffff 00000000`1c00f820 00000642`7f885bdb : mscorwks!MethodTable::IsAbstract+0x49
0:047> !dumpstack
OS Thread Id: 0x15b0 (47)
Child-SP         RetAddr          Call Site
000000001ef7f138 0000000077d705d6 ntdll!ZwDelayExecution+0xa
000000001ef7f140 000006427f88901d kernel32!SleepEx+0x96
000000001ef7f1e0 000006427f454379 mscorwks!EESleepEx+0x2d
000000001ef7f260 000006427fa34749 mscorwks!Thread::UserSleep+0x71
000000001ef7f2c0 0000064280184902 mscorwks!ThreadNative::Sleep+0xf9
000000001ef7f470 0000064280184532 Company_Common_Diagnostics!Company.Common.Diagnostics.BufferedStream.Write(Byte[], Int32, Int32)+0x1b2
000000001ef7f4e0 00000642801831fd Company_Common_Diagnostics!Company.Common.Diagnostics.XmlRollingTraceListener+TraceWriter.Write(System.String)+0x52
000000001ef7f530 0000064274e9e494 Company_Common_Diagnostics!Company.Common.Diagnostics.XmlRollingTraceListener.InternalWrite(System.Text.StringBuilder)+0x3d
000000001ef7f570 000006428018d3d3 System_ni!System.Diagnostics.TraceSource.TraceEvent(System.Diagnostics.TraceEventType, Int32, System.String)+0x2b4
000000001ef7f620 00000642782f173b Company_Common_Routing_Service!Company.Common.RouterService.KeepAlive(System.Object)+0x2a3
000000001ef7f6f0 000006427834d696 mscorlib_ni!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)+0x9b
000000001ef7f740 000006427f602672 mscorlib_ni!System.Threading._TimerCallback.PerformTimerCallback(System.Object)+0x86
000000001ef7f790 000006427f50c053 mscorwks!CallDescrWorker+0x82
000000001ef7f7e0 000006427f51449a mscorwks!CallDescrWorkerWithHandler+0xd3
000000001ef7f880 000006427f46b023 mscorwks!DispatchCallDebuggerWrapper+0x3e
000000001ef7f8e0 000006427f41729e mscorwks!DispatchCallNoEH+0x5f
000000001ef7f960 000006427f447ee8 mscorwks!AddTimerCallback_Worker+0x92
000000001ef7f9f0 000006427f556aa9 mscorwks!Thread::DoADCallBack+0x488
000000001ef7fa40 000006427f43afdd mscorwks!CNgenEntryBind::Create+0x15d
000000001ef7fb10 000006427f435296 mscorwks!MethodTable::IsAbstract+0x49
000000001ef7fb50 000006427f4162bb mscorwks!AddTimerCallbackEx+0xba
000000001ef7fc10 000006427f495fa7 mscorwks!ThreadpoolMgr::AsyncTimerCallbackCompletion+0x53
000000001ef7fc70 000006427f4aad0a mscorwks!UnManagedPerAppDomainTPCount::DispatchWorkItem+0x157
000000001ef7fd10 000006427f41f9a0 mscorwks!ThreadpoolMgr::WorkerThreadStart+0x1ba
000000001ef7fdb0 0000000077d6b6da mscorwks!Thread::intermediateThreadProc+0x78
000000001ef7ff80 0000000000000000 kernel32!BaseThreadStart+0x3a