C#/C++应用调用ntdll!TppIteWakeWaiters崩溃对应什么上层代码？

TppIteWakeWaiters、TppCallbackEpilog、TppWorkerThread都属于Windows系统原生线程池的内部实现函数，你遇到的访问违例不是系统函数的问题，而是上层提交到线程池的回调任务执行过程中发生了内存破坏，把线程池内部的任务控制块结构写坏了，等到线程池执行后续清理逻辑时才触发崩溃。

你当前拿到的崩溃栈已经是回调任务执行完毕、退回线程池框架代码后的栈，所以看不到上层的C#/C业务代码，属于典型的「内存破坏延时崩溃」场景。你猜测和.NET的Thread/Task有关是对的，.NET的Task默认就是靠系统线程池调度执行，如果你在Task的回调里调用了C COM对象的方法，就是这类问题的高发场景。

排查方向 #

• 优先检查C++ COM对象的内存操作逻辑：重点排查野指针访问、堆内存越界写、重复释放、跨线程释放内存的问题，尤其是COM对象的异步方法实现、或者C++代码中主动调用Win32线程池API提交回调的逻辑，内存破坏大概率出在这部分代码中。
• 其次检查C#侧的COM调用逻辑：确认你的COM对象的线程单元模型，如果是STA（单线程单元）模型，不要直接从属于MTA的.NET线程池线程（比如Task.Run创建的任务执行线程）调用，跨单元调用的COM列集过程如果涉及非托管内存指针传递，非常容易出现内存提前释放的问题。
• 调试优化方案：你可以通过WinDbg的gflags工具为你的程序开启全页堆（gflags /p /enable 你的程序名.exe /full），开启后内存破坏会在发生的瞬间直接触发崩溃，此时抓取的转储就能直接看到出问题的上层业务代码栈。也可以在现有崩溃转储中执行!tp命令查看线程池历史执行的回调记录，定位到出问题的回调函数。

你提到的大量包含ntdll!NtWaitForWorkViaWorkerFactory的栈都是正常的，属于线程池中空闲等待新任务的线程，和本次崩溃无关。

内容的提问来源于stack exchange，提问作者Anton Serov