C# WCF服务中的奇怪异常

从两个月前开始我就有点迷茫了。我真的不知道这是从哪里来的。我认为这是并发垃圾收集框架中的一个bug。所以我禁用了它。但我仍然得到这个。我希望我能从社区中找到一些见解

线程20-系统ID 8552

入口点clr！线程：：intermediateThreadProc 创建时间2016年6月2日上午7:37:30 在用户模式下花费的时间0天00:00:00.000 在内核模式下花费的时间0天00:00:00.000

此线程未完全解决，可能是问题，也可能不是问题。可能需要对这些螺纹进行进一步分析

.NET调用堆栈

[[DebuggerU2MCatchHandlerFrame]]

完整调用堆栈

内核库！升高异常+68 MSVCR120_CLR0400_CxxCallCatchBlock+169 ntdll！RcConsolidateFrames+3 clr！ManagedThreadBase_DispatchMiddle+6c clr！ManagedThreadBase_DispatchOuter+75 [[DebuggerU2MCatchHandlerFrame]] clr！ManagedThreadBase_FullTransitionWithAD+2f clr！AppDomainTimerCallback+7f clr！ThreadpoolMgr:：AsyncTimerCallbackCompletion+6d clr！UnmanagedPerAppDomainMaintpCount:：DispatchWorkItem+19b clr！ThreadpoolMgr:：ExecuteWorkRequest+64 clr！ThreadpoolMgr:：WorkerThreadStart+3b5 clr！线程：：intermediateThreadProc+7d 内核32！BaseThreadInitThunk+22 ntdll！RtlUserThreadStart+34

例外信息

在w3wp\uuuuuuuu DefaultAppPool\uuuuuuuuu PID\uuuuuuu2920\uuuuuuuuuuu日期\uuuuuuuuu 06\uu 02\uu 2016\uuuuuuuuuuuu 07\u37\uuu52am\uuuuuuuuuuuu 167\uuuuuuuuuuuu首次机会异常0XE06D7363！从Microsoft Corporation在C:\Windows\System32\KERNELBASE.dll中提出异常+68 此异常源于MSVCR120_CLR0400_CxxCallCatchBlock。已在线程20上导致未知异常（0xe06d7363）

此异常源于MSVCR120_CLR0400_CxxCallCatchBlock+169

模块信息

图像名称：C:\Windows\System32\KERNELBASE.dll符号类型：PDB 基址：0x00000003

00905a4d时间戳：2016年3月10日星期四18:31:13

校验和：0x00000000

00000000注释：
COM DLL:错误的公司名称：Microsoft Corporation ISAPIExtension:错误文件描述：Windows NT基本API客户端DLL ISAPI过滤器：错误文件版本：6.3.9600.18264（winblue_ltsb.160310-0600） 托管DLL:错误内部名称：Kernelbase.DLL VB DLL:虚假合法版权：微软公司©版权所有。版权所有。 加载的图像名称：KERNELBASE.dll合法商标：
映射图像名称：原始文件名：Kernelbase.dll 模块名称：KERNELBASE私有构建：
单线程：错误产品名称：Microsoft Windows操作系统 模块大小：1.08 MB产品版本：6.3.9600.18264 符号文件名：c:\symbols\kernelbase.pdb\64DCF0326E4AD7A4397D79BA8A9BEE2\kernelbase.pdb特殊构建：&

---

这是单独发生的，服务器没有收到任何请求或任何东西。只有另一个测试服务器在某个时间段请求一个页面，以检查服务器是否在线。除此之外，没有其他事情发生。我的所有调用都被try/catch包围，但这是来自非托管的，因此服务器崩溃，看门狗再次启动它。

可能会引起兴趣：谢谢，但这些调用也来自非托管代码，但属于访问冲突。我得到了一个C++异常。我觉得这个信息很有趣。ntdll！RcConsolidateFrames+3看起来像是启动了某个线程（不是通过我的代码）。然后看起来像是试图合并堆并抛出C++异常。只是猜测。我在研究，这个函数实际上与堆无关，它是关于堆栈帧的。我想现在一个好问题是谁创建了这个线程，它提供了堆栈跟踪的很少线索。