.net – wcf callback exception after updating to .net 4.0

exceptioniisnetwcf

I have a wcf service that uses callbacks with DualHttpBindings. The service pushes back a datatable of search results the client (for a long running search) as it finds them.

This worked fine in .Net 3.5. Since I updated to .Net 4.0, it bombs out with a System.Runtime.FatalException that actually kills the IIS worker process. I have no idea how to even go about starting to fix this. Any recommendations appreciated.

The info from the resulting event logs is pasted below:

An unhandled exception occurred and
the process was terminated.

Application ID: /LM/W3SVC/2/ROOT/CP

Process ID: 5284

> Exception:
System.Runtime.FatalException

> Message: Object reference not set to
an instance of an object.

StackTrace: at
System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage4(MessageRpc&
rpc) at
System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(MessageRpc&
rpc) at
System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean
isOperationContextSet) at
System.ServiceModel.Dispatcher.ChannelHandler.DispatchAndReleasePump(RequestContext
request, Boolean cleanThread,
OperationContext
currentOperationContext) at
System.ServiceModel.Dispatcher.ChannelHandler.HandleRequest(RequestContext
request, OperationContext
currentOperationContext) at
System.ServiceModel.Dispatcher.ChannelHandler.AsyncMessagePump(IAsyncResult
result) at
System.Runtime.Fx.AsyncThunk.UnhandledExceptionFrame(IAsyncResult
result) at
System.Runtime.AsyncResult.Complete(Boolean
completedSynchronously) at
System.Runtime.InputQueue1.AsyncQueueReader.Set(Item
item) at
System.Runtime.InputQueue1.Dispatch()
at
System.ServiceModel.Channels.ReliableDuplexSessionChannel.ProcessDuplexMessage(WsrmMessageInfo
info) at
System.ServiceModel.Channels.ReliableDuplexSessionChannel.HandleReceiveComplete(IAsyncResult
result) at
System.ServiceModel.Channels.ReliableDuplexSessionChannel.OnReceiveCompletedStatic(IAsyncResult
result) at
System.Runtime.Fx.AsyncThunk.UnhandledExceptionFrame(IAsyncResult
result) at
System.Runtime.AsyncResult.Complete(Boolean
completedSynchronously) at
System.ServiceModel.Channels.ReliableChannelBinder1.InputAsyncResult1.OnInputComplete(IAsyncResult
result) at
System.Runtime.Fx.AsyncThunk.UnhandledExceptionFrame(IAsyncResult
result) at
System.Runtime.AsyncResult.Complete(Boolean
completedSynchronously) at
System.Runtime.InputQueue1.AsyncQueueReader.Set(Item
item) at
System.Runtime.InputQueue1.Dispatch()
at
System.Runtime.IOThreadScheduler.ScheduledOverlapped.IOCallback(UInt32
errorCode, UInt32 numBytes,
NativeOverlapped* nativeOverlapped)
at
System.Runtime.Fx.IOCompletionThunk.UnhandledExceptionFrame(UInt32
error, UInt32 bytesRead,
NativeOverlapped* nativeOverlapped)
at
System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32
errorCode, UInt32 numBytes,
NativeOverlapped* pOVERLAP)

> InnerException:
> System.NullReferenceException

Message: Object reference not set to
an instance of an object.

StackTrace: at
System.Web.HttpApplication.ThreadContext.Enter(Boolean
setImpersonationContext) at
System.Web.HttpApplication.OnThreadEnterPrivate(Boolean
setImpersonationContext) at
System.Web.AspNetSynchronizationContext.CallCallbackPossiblyUnderLock(SendOrPostCallback
callback, Object state) at
System.Web.AspNetSynchronizationContext.CallCallback(SendOrPostCallback
callback, Object state) at
System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage4(MessageRpc&
rpc)

Best Answer

OK - I found the answer. Very Strange, but simply put the following attribute on the WCF callback wrapper class:

[CallbackBehavior(UseSynchronizationContext=false)]

Thanks to Cauldwell.net for the answer: http://www.cauldwell.net/patrick/blog/CategoryView,category,CodeGen.aspx

From cauldwell.net:

The problem, it turned out, was that ASP.NET uses (by default) a little thing called the SynchronizationContext. As near as I can tell (I haven't researched this thoroughly, to be honest) one of it's jobs it to make sure that any callbacks get run on the UI thread, thereby obviating the need to call Control.Invoke like you do in WinForms. In my case, that additional lock was giving something fits, and it was trying to clean stuff up on a thread that wasn't around any more, hence to NullReferenceException.

Related Topic