WCF service FaultException is not written to database using Enterprise library blocks

Question

Hi

using Enterprise Library: Logging and Data application blocks to log service exceptions to database.

As the service exceptions are thrown as FaultException it is NOT traced/logged into database. Service exception is logged to database except the FaultException, which is the important . 

Logged exception is copied below, which is ignoring the exception caught using FaultException in service.

Callstack= at System.Environment.GetStackTrace(Exception e, Boolean needFileInfo) at System.Environment.get_StackTrace()
at System.Diagnostics.TraceEventCache.get_Callstack() at System.Diagnostics.TraceListener.WriteFooter(TraceEventCache eventCache) at System.Diagnostics.TraceListener.TraceEvent(TraceEventCache eventCache, String source, TraceEventType eventType, Int32 id, String message) at System.Diagnostics.TraceListener.TraceTransfer(TraceEventCache eventCache, String source, Int32 id, String message, Guid relatedActivityId)
at Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.TraceListenerWrapper.TraceTransfer(TraceEventCache eventCache, String source, Int32 id, String message, Guid relatedActivityId) at Microsoft.Practices.EnterpriseLibrary.Logging.LogSource.TraceData(TraceEventType eventType, Int32 id, LogEntry logEntry, TraceListenerFilter traceListenerFilter, TraceEventCache traceEventCache) at Microsoft.Practices.EnterpriseLibrary.Logging. LogWriterImpl.ProcessLog(LogEntry log, TraceEventCache traceEventCache) at Microsoft.Practices.EnterpriseLibrary.Logging.LogWriterImpl. <>c_DisplayClass1.b_0() at Microsoft.Practices.EnterpriseLibrary.Logging.LoggingUpdateCoordinator.ExecuteReadOperation(Action action) at Microsoft.Practices.EnterpriseLibrary.Logging.LogWriterImpl.Write(LogEntry log) at Microsoft.Practices.EnterpriseLibrary.Logging. TraceListeners.EntLibLoggingProxyTraceListener.TraceTransfer(TraceEventCache eventCache, String source, Int32 id, String message, Guid relatedActivityId) at System.Diagnostics.TraceSource.TraceTransfer(Int32 id, String message, Guid relatedActivityId) at System.Runtime.Diagnostics.DiagnosticTrace.TraceTransfer(Guid newId) at System.ServiceModel.Diagnostics.ServiceModelActivity.TransferActivity.Dispose() at System.ServiceModel.Diagnostics.ServiceModelActivity.Dispose() 
at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs) at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage41(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage4(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage3(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage2(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage11(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage1(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.ServiceModel.Dispatcher.ChannelHandler.OnAsyncReceiveComplete(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.EnqueueAndDispatch(Item item, Boolean canDispatchOnThisThread)
at System.Runtime.InputQueue1.EnqueueAndDispatch(T item, Action dequeuedCallback, Boolean canDispatchOnThisThread)
at System.ServiceModel.Channels.SingletonChannelAcceptor3.Enqueue(QueueItemType item, Action dequeuedCallback, Boolean canDispatchOnThisThread)
at System.ServiceModel.Channels.HttpChannelListener.HttpContextReceived(HttpRequestContext context, Action callback)
at System.ServiceModel.Activation.HostedHttpTransportManager.HttpContextReceived(HostedHttpRequestAsyncResult result)
at System.ServiceModel.Activation.HostedHttpRequestAsyncResult.HandleRequest()
at System.ServiceModel.Activation.HostedHttpRequestAsyncResult.BeginRequest() at System.ServiceModel.Activation.HostedHttpRequestAsyncResult.OnBeginRequest(Object state) at System.ServiceModel.AspNetPartialTrustHelpers.PartialTrustInvoke(ContextCallback callback, Object state) at System.ServiceModel.Activation.HostedHttpRequestAsyncResult.OnBeginRequestWithFlow(Object state) 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 

Help is appreciated to trace/log actual FaultException.

---

Apriori algorithm [association rule]

Answer 1

Catch the FaultException<tdetail></tdetail> object in a client application to handle a SOAP fault that has been contractually specified in an operation contract. It usually used to gracefully return a generic exception to client without faulting the channel so that client can use the channel for other operation without recreating it. When you want to log the error in faultexception how are you doing that? You need to revisit that code-part. You need to log it when a generic exception occured and before sending it back to client.

---

Tanvir Huda Application Architect/Consultant http://thetechnocrate.wordpress.com/

Answer 2

Catch the FaultException<tdetail></tdetail> object in a client application to handle a SOAP fault that has been contractually specified in an operation contract. It usually used to gracefully return a generic exception to client without faulting the channel so that client can use the channel for other operation without recreating it. When you want to log the error in faultexception how are you doing that? You need to revisit that code-part. You need to log it when a generic exception occured and before sending it back to client.

Exceptions in service are caught as FaultExceptions as below. Logging these exceptions from service (Not from client) to database using logging and data application blocks.

All the excepiton strack is written to log database except the FaultException stack.

---

Apriori algorithm [association rule]

Answer 3

Cant tell you much without looking the code. Can you step through the service and see what is happening

---

Tanvir Huda Application Architect/Consultant http://thetechnocrate.wordpress.com/

Answer 4

Cant tell you much without looking the code. Can you step through the service and see what is happening

---

Stepping through doesn't help as all the tracing is implemented in Web.config. At the moment except the Service FaultException rest of the stack trace has been logged. It is the objective to log actual exception stack trace.

Here is the Catch block of service method and here is the Web.config

catch (Exception ex)
{
ServiceException oe = new ServiceException();
oe.Content = ex.Message;
throw new FaultException<ServiceException>
(oe, new FaultReason(oe.Content));
}

---

Apriori algorithm [association rule]

Answer 5

Where you are logging in the code .... 

In your code you are just trapping the exception and creating a generic fault exception and sending it back to client. 

Should you do something like the following before throwing the fault exception 

Tracer.TraceError(ex.message); 

throw new FaultException<ServiceException> .... 

---

Tanvir Huda Application Architect/Consultant http://thetechnocrate.wordpress.com/

Answer 6

Where you are logging in the code .... 

In your code you are just trapping the exception and creating a generic fault exception and sending it back to client. 

Should you do something like the following before throwing the fault exception 

Tracer.TraceError(ex.message); 

throw new FaultException<ServiceException> ....

Note that tracing service logs All (Information, Errors etc), refer http://msdn.microsoft.com/en-us/library/ms733025.aspx

It is NOT required to implement manually as suggested. At the moment the exception is writtent to database , BUT the FaultException stack is NOT written.

EDIT: All working as expected. Service exceptions thrown as FaultExceptions are written to database using Logging application block.

Refer http://entlib.codeplex.com/discussions/361057 for configuration.

---

Apriori algorithm [association rule]