2010-08-23 14 views
5

Cuando emití el comando ~ * e! Clrstack en WinDbg para identificar la pila de llamadas clr de subprocesos en una aplicación de consola, se enumeraban 5 subprocesos. 3 de ellos son hilos gestionados (hilo principal, hilo que he almacenado, hilo de recogida de basura (espero)). 2 son hilos nativos. No creé ningún hilo nativo.Subprocesos nativos en una aplicación .Net

¿Qué hacen estos hilos nativos? ¿Dónde podría obtener más información?

La salida del ~ * e! Comando clrstack se enumeran a continuación

0:004> ~* e !clrstack 
OS Thread Id: 0x1ab8 (0) 
ESP  EIP  
0012f3c0 7c90e514 [HelperMethodFrame: 0012f3c0] System.Threading.Thread.SleepInternal(Int32) 
0012f414 79299275 System.Threading.Thread.Sleep(Int32) 
0012f418 00c602bf testlock.LockTest.Test() 
0012f458 00c60131 testlock.Program.Main(System.String[]) 
0012f69c 79e71b4c [GCFrame: 0012f69c] 
OS Thread Id: 0x1008 (1) 
Unable to walk the managed stack. The current thread is likely not a 
managed thread. You can run !threads to get a list of managed threads in 
the process 
OS Thread Id: 0x209c (2) 
Failed to start stack walk: 80004005 
OS Thread Id: 0x1490 (3) 
ESP  EIP  
00d6f74c 7c90e514 [GCFrame: 00d6f74c] 
00d6f81c 7c90e514 [HelperMethodFrame_1OBJ: 00d6f81c] System.Threading.Monitor.Enter(System.Object) 
00d6f874 00c602b3 testlock.LockTest.Test() 
00d6f8b4 00c6022c testlock.Program+<>c__DisplayClass1.<Main>b__0() 
00d6f8c0 792d6d66 System.Threading.ThreadHelper.ThreadStart_Context(System.Object) 
00d6f8cc 792e01ef System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object) 
00d6f8e4 792d6ce4 System.Threading.ThreadHelper.ThreadStart() 
00d6fb0c 79e71b4c [GCFrame: 00d6fb0c] 
OS Thread Id: 0x1cb8 (4) 
Unable to walk the managed stack. The current thread is likely not a 
managed thread. You can run !threads to get a list of managed threads in 
the process 
+0

No es una respuesta a su pregunta, pero quiero mencionar que también aparecen en la ventana de depuración * Thread * mientras se depura la aplicación en Visual Studio. Se pueden congelar y descongelar allí, pero no hay una pila de llamadas ni una ubicación de origen para ellos. – Timwi

+1

No lo sé. Pero cuando creas un ejecutable administrado, lo que realmente ocurre es que estás alojando un proceso administrado dentro del * host CLR predeterminado *. El host CLR predeterminado vive en mscorlib.dll (creo) y existe como código nativo (el sistema operativo no sabe nada del código * managed *). Por lo tanto, estos dos hilos proporcionan soporte de alojamiento para su programa administrado. En versiones pasadas/futuras, la cantidad de hilos puede cambiar. –

Respuesta

4

Cuando Windows se ejecuta la aplicación, en ella se establece varios hilos no administrados. Esto es completamente normal.

Usted puede obtener un seguimiento de pila de subprocesos no administrados de diversos comandos como:

.kb100 
!dumpstack 

Personalmente, me gusta la salida de dumpstack, que le da la pila combinado administrado y no administrado!.

Si desea ver sólo los subprocesos administrados, tratar

!threads 

Tess Ferrandez describe algunas de las theads normales verá durante la depuración en her blog:

http://blogs.msdn.com/b/tess/archive/2005/12/20/things-to-ignore-when-debugging-an-asp-net-hang.aspx

0

Puede utilice el siguiente comando para obtener detalles sobre qué otros hilos son para

! Hilos -Special

Éstos son algunos de esos tipos

IOCompletion, Puerta, DbgHelper, GC, finalizador, temporizador, ADUnloadHelper

clrstack espectáculos => ThreadpoolWorker

Cuestiones relacionadas