在Process Explorer的调试RtlUserThreadStart [英] Debugging RtlUserThreadStart in Process Explorer

问题描述

我必须建立在3.5多线程WPF应用程序。当我看到通过Process Explorer中正在运行的线程我看到8个线程都具有相同的起始地址，NTDLL.DLL！RtlUserThreadStart和所有八个具有3-6 +在CPU值，具有较高的周期三角洲。我无法找出这些线程在做什么。它始终是相同的线程。它从未应用程序的相同实例内变化。当调试我在同一时间的应用程序，并暂停调试器，所有这些线程都显示堆栈或者System.Threading.ConcurrencyScheduler.Scheduler.WaitForWork（）或System.Threading.Monitor.Wait（）一行。

I have a multi-threaded wpf application built on 3.5. When I look at the running threads through Process Explorer I see 8 threads all with the same start address, ntdll.dll!RtlUserThreadStart and all eight have a CPU value from 3-6+ and have a high Cycles Delta. I can't figure out what these threads are doing. It is always the same threads. It never varies within the same instance of the application. When I debug my application at the same time and pause the debugger, all these threads are showing a single line for the stack either System.Threading.ConcurrencyScheduler.Scheduler.WaitForWork() or System.Threading.Monitor.Wait().

我启用了Visual Studio中的符号文件，我看到那些线程下面的堆栈：

I enabled the symbol files for Visual Studio and I see the following stack on those threads:

System.Threading.Monitor.Wait() Normal
mscorlib.dll!System.Threading.Monitor.Wait(object obj, int millisecondsTimeout) + 0x19     bytes
System.Threading.dll!System.Threading.ConcurrencyScheduler.Scheduler.WaitForWork() + 0xd0 bytes  
System.Threading.dll!System.Threading.ConcurrencyScheduler.InternalContext.Dispatch() + 0x74a bytes
System.Threading.dll!System.Threading.ConcurrencyScheduler.ThreadInternalContext.ThreadStartBridge(System.IntPtr dummy) + 0x9f bytes     

当我看在提供过程监控中的线程我看到下面的例子为在堆栈：

When I look at the stack provided on the thread within process monitor I see the following as examples:

0  ntoskrnl.exe!KeWaitForMultipleObjects+0xc0a
1  ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x732
2  ntoskrnl.exe!KeWaitForSingleObject+0x19f
3  ntoskrnl.exe!_misaligned_access+0xba4
4  ntoskrnl.exe!_misaligned_access+0x1821
5  ntoskrnl.exe!_misaligned_access+0x1a97
6  mscorwks.dll!InitializeFusion+0x990b
7  mscorwks.dll!DeleteShadowCache+0x31ef

或：

0  ntoskrnl.exe!KeWaitForMultipleObjects+0xc0a
1  ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x732
2  ntoskrnl.exe!KeWaitForSingleObject+0x19f
3  ntoskrnl.exe!_misaligned_access+0xba4
4  ntoskrnl.exe!_misaligned_access+0x1821
5  ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x93d
6  ntoskrnl.exe!KeWaitForMultipleObjects+0x26a
7  ntoskrnl.exe!NtWaitForSingleObject+0x41f
8  ntoskrnl.exe!NtWaitForSingleObject+0x78e
9  ntoskrnl.exe!KeSynchronizeExecution+0x3a23
10 ntdll.dll!ZwWaitForMultipleObjects+0xa
11 KERNELBASE.dll!GetCurrentProcess+0x40
12 KERNEL32.dll!WaitForMultipleObjectsEx+0xb3
13 mscorwks.dll!CreateApplicationContext+0x10499
14 mscorwks.dll!CreateApplicationContext+0xbc41
15 mscorwks.dll!StrongNameFreeBuffer+0xc54d
16 mscorwks.dll!StrongNameFreeBuffer+0x2ac48
17 mscorwks.dll!StrongNameTokenFromPublicKey+0x1a5ea
18 mscorwks.dll!CopyPDBs+0x17362
19 mscorwks.dll!CorExitProcess+0x3dc9
20 mscorwks.dll!TranslateSecurityAttributes+0x547f
21 mscorlib.ni.dll+0x8e6bc9

作为一个额外的纸条给这个项目。我的电脑是单CPU有4个内核。当我们运行4个核心，我们看到这个数字的线程去8至16双CPU上的相同的应用程序。

As an additional note to this item. My computer is a single CPU with 4 cores. When we run the same app on a dual CPU with 4 cores we see this number of threads go from 8 to 16.

推荐答案

你的问题是远远不足的记载，但一个合理的猜测是，你似乎使用PPL库。这使各地的线程来完成并行作业池。你无疑看到高的CPU周期数，因为这些线程确实做你要求他们做的工作。

Your question is woefully under-documented, but a reasonable guess is that you appear to use the PPL library. Which keeps a pool of threads around to get the parallel jobs done. You are no doubt seeing high cpu cycle counts because these threads are indeed doing the job you asked them to do.

作为典型的线程池的PPL保持这些线程周围接下来的工作要做，这就是为什么你看到他们等待WaitForWork（）。本机堆栈跟踪是由于缺乏调试符号的垃圾。 RtlUserThreadStart否则是一个Windows的功能，你会经常看到早在一个非托管堆栈跟踪，这是一个线程如何被启动。

As is typical with thread pools, the PPL keeps these threads around for the next job to do, that's why you see them waiting on WaitForWork(). The native stack traces are junk due to a lack of debugging symbols. RtlUserThreadStart is otherwise a Windows function you'll always see back in an unmanaged stack trace, that's how a thread gets started.

这是一切完全正常。值得注意的唯一其他信息身价这个答案发布的微软员工：

This is all entirely normal. The only other info worth of note is this answer posted by a Microsoft employee:

并发运行时的缓存，供以后再次使用线程。他们被释放，只有当所有的并发运行时的调度一直关机。 （通常情况下，有只在过程单个默认调度）。调度器处于关闭状态时，所有排队的工作给它的外螺纹已退出。因此，如果主线程调度的工作（通过调用main（）中说parallel_for时），则缺省调度程序只会在进程关闭被删除。

The concurrency runtime caches threads for later re-use. They are released only when all the concurrency runtime schedulers have been shutdown. (Typically, there is just a single default scheduler in the process). A scheduler is shutdown when all the external threads that queued work to it has exited. So if the main thread scheduled work (by calling parallel_for from main() say) then the default scheduler would be deleted only on process shutdown.

有是一个上限缓存线程数。这是机器上的核心rougly人数的4倍（虽然也有类似的影响在调度政策的堆栈大小选项门槛等因素）。

There is an upper limit on the number of cached threads. It is rougly 4 times the number of cores on the machine (though there are some other factors affecting the threshold like the stack size option in scheduler policies).

这篇关于在Process Explorer的调试RtlUserThreadStart的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！