NullReferenceException in ExceptionShieldingErrorHandler

Topics: Exception Handling Application Block
Sep 28, 2007 at 3:32 PM
Hi,
We have a WCF service hosted by a Windows Service.
We have created an Exception Handling Policy and added a Fault Contract Exception Handler that convert all exceptions in FaultExceptions of specified type.
Sometimes there is a strange exception, that turn the servicehost in a faulted state.

Here are the details:

Message: System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.WCF.ExceptionShieldingErrorHandler.GetFaultAction(FaultContractWrapperException faultContractWrapper)
at Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.WCF.ExceptionShieldingErrorHandler.HandleFault(FaultContractWrapperException faultContractWrapper, Message& fault)

What could be the cause of this exception? Shall we do something to prevent this issue?

Daniele.
Aug 12, 2008 at 5:58 AM

Hi Daniele,

Have you solved the problem?I m getting the same exception in my service too.Can you help me with that.

Aug 12, 2008 at 2:24 PM

Hi,

Is this a random failure? If you can reproduce it consistently, can you debug it to determine exactly exactly which line is failing?

Fernando

Aug 13, 2008 at 12:27 PM

Hi Fernando,

No this failure is occuring freqently .This is happening when some exception occurs in service and while is getting logged (enterprise library ).I have configured the Enterpise library correctly.But i have no idea why this error is happening.

 

Aug 13, 2008 at 2:19 PM
Can you attach a debugger to determine the line where the failure occurs? Failing that, can you come up with a repro project?

Fernando
Feb 3, 2009 at 1:57 PM
Hi there,

I've an identical problem to this and it only seems to occur when I'm hosting an MSMQ endpoint. In this case OperationContext.Current.RequestContext is null - the documentation states that this is always the case for IsOneWay operations. Understandably faults will never actually be seen by the caller in this case, but we're using this in order to prevent the service host from falling over by wrapping unhandled exceptions in faults.

Ideally OperationContext.Current.RequestContext.RequestMessage.Headers.Action should be replaced with OperationContext.Current.IncomingMessageHeaders.Action as this works for all operations.

Cheers,

Dean