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
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
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. –