终结者中的WCF NullReferenceException

我们有WCF的问题，我们花了很长时间来诊断，所以我在这里发布他们的情况下，有人有类似的问题（没有find一个参考其他地方）。

我们的进程经常会因下列未处理的exception而崩溃：

System.NullReferenceException: Object reference not set to an instance of an object. at System.ServiceModel.Channels.OverlappedContext.CompleteCallback(UInt32 error,UInt32 numBytes,NativeOverlapped* nativeOverlapped) at System.Runtime.Fx.IOCompletionThunk.UnhandledExceptionFrame(UInt32 error,UInt32 bytesRead,NativeOverlapped* nativeOverlapped) at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode,NativeOverlapped* pOVERLAP) System.NullReferenceException: Object reference not set to an instance of an object. at System.Threading.Overlapped.Free(NativeOverlapped* nativeOverlappedPtr) at System.ServiceModel.Channels.OverlappedContext.Free() at System.ServiceModel.Channels.OverlappedContext.FreeOrDefer() at System.ServiceModel.Channels.socketConnection.Abort(TraceEventType traceEventType,String timeoutErrorString,TransferOperation transferOperation) at System.ServiceModel.Channels.CommunicationPool`2.EndpointConnectionPool.CloseIdleConnection(TItem connection,TimeSpan timeout) at System.ServiceModel.Channels.IdlingCommunicationPool`2.IdleTimeoutEndpointConnectionPool.IdleTimeoutIdleConnectionPool.OnIdle() at System.Runtime.IOThreadScheduler.ScheduledOverlapped.IOCallback(UInt32 errorCode,NativeOverlapped* pOVERLAP) System.NullReferenceException: Object reference not set to an instance of an object. at System.Threading.Overlapped.Free(NativeOverlapped* nativeOverlappedPtr) at System.Net.AsyncRequestContext.dispose(Boolean disposing) at System.Net.RequestContextBase.Finalize()

例外情况通常发生在几个小时后，有时在几分钟后。

奇怪的是，他们只会在安装2013年1月的Windows更新（并卸载它们后离开）后才会显示。

无声无息地被Windows捕获的exception，如何手动处理？

获取有关结构化exception的详细信息

如何dllexport派生自std :: runtime_error的类？

如何禁用浮点单元（FPU）？

C ++：安全使用longjmp和setjmp？

如何使用grep从日志文件中捕获Javaexception（包括堆栈跟踪）？

为什么linux在exception处理程序的序言中将数据段设置为__USER_DS

Linux是否logging守护进程抛出的未捕获的exception？

如何将引发的exception映射到事件ID以进行日志logging？

显示可变消息的自定义exception，不同编译器中的不同行为

问题原来是IClientChannel 。

我们忘记了使用后的通道，并从终结器线程调用dispose() 。

我的猜测是，IClientChannel使用非托管资源，必须从创建它们的相同线程释放。

从同一个线程调用dispose()后，问题就消失了。