How to troubleshoot the exception CommunicationObjectFaultedException when we have the attribute [System.ServiceModel.ServiceKnownTypeAttribute(typeof(xxx))]

[nicoclau]

We updated a web service in java to the next version with the new wsdl. We use .net Core 3.1 with system.servicemodel.primitives and System.ServiceModel.Http version 4.7.0

We get the following error:

System.ServiceModel.CommunicationObjectFaultedException HResult=0x80131500 Message=The communication object, System.ServiceModel.ChannelFactory1[zzz], cannot be used for communication because it is in the Faulted state. Source=System.Private.ServiceModel StackTrace: at System.ServiceModel.Channels.CommunicationObject.<System-ServiceModel-IAsyncCommunicationObject-CloseAsync>d__66.MoveNext() at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter.GetResult() at System.ServiceModel.Channels.CommunicationObject.<CloseAsyncInternal>d__65.MoveNext() at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter.GetResult() at System.Runtime.TaskHelpers.WaitForCompletion(Task task) at System.ServiceModel.Channels.CommunicationObject.Close(TimeSpan timeout) at System.ServiceModel.ClientBase1.System.ServiceModel.ICommunicationObject.Close(TimeSpan timeout) at System.ServiceModel.ClientBase1.Close() at System.ServiceModel.ClientBase`1.System.IDisposable.Dispose() at cccc.CreateToken() in wwwwe 135

This exception was originally thrown at this call stack: [External Code] zzzz.CreateToken() in XmlSelectBroker.cs`

I "solved" the problem by commenting out the following "ServiceKnowTypeAttribute"

//[System.ServiceModel.ServiceKnownTypeAttribute(typeof(yyy))]

[System.ServiceModel.ServiceKnownTypeAttribute(typeof(zzz))] xxxResponse CreateToken(xxxRequest request);

Unfortunately the exception doesn't explain what is the problem exactly. It seems to me that the serialization failed when the request is sent.

Is there a way to solve this with better info about the exception. By the way I don't have any control to the server codebase in java. We use .NET Core here

[mconnew]

My personal favorite tool for diagnosing problems like this is perfview. You can use perfview to collect a trace which will include all exceptions which were thrown as well as some event logging by WCF with any errors it encountered. You can run the following command from an administrative command prompt:

PerfView.exe  "/DataFile:PerfViewData.etl" /BufferSizeMB:256 /StackCompression /CircularMB:500 /KernelEvents:Process,Thread,ImageLoad,ProcessCounters,DiskIO,DiskFileIO,DiskIOInit,MemoryHardFaults,NetworkTCPIP /NoGui /NoNGenRundown collect

This will collect events into an .etl.zip file. You can stop the tracing by typing s. This can be loaded in perfview and you can examine all the exceptions and view WCF events.

[nicoclau]

Thanks Matthew! I will try your suggestion and keep you posted as soon as possible. Congrats for your work on WCF and of course we can thank for the thousands contributors all around the world.

Too bad we need outside EWT tool to investigate :( Could you explain why the exception is not visible with details? Cheers 👍

[mconnew]

If I know the specific root cause I can investigate why the root cause isn't in the message or an inner exception. Sometimes this is due to general purpose exception handling code being hit and that doesn't propagate inner details.
You can investigate without an outside tool, you can use the command line tools logman and tracerpt, but they are a lot harder to use than perfview. I used to use them before perfview was created and it was really frustrating trying to parse through the output and understand what's going on which is why I didn't recommend them. You can use logman on a production system without too much difficulty, and then use perfview to analyze the captured trace and that's not too bad. But if you are going to use perfview, usually it's easiest to use it for capture too. It's not intuitive to capture all the correct information as you need private obscure guids to be configured in logman, so again easier to just use perfview.

I'm closing this issue as there was no further followup. If you want me to look into why the inderlying cause wasn't included, as many stack traces as possible that are involved would be helpful (original exception, or etw event id) and I can try and work it out, and maybe improve things.

[nicoclau]

Thanks for your comment i will try it and send you the perfview traces

[zijianhuang]

I had some deep dive into this issue in 2011:

• Enforce Proper Disposal of WCF Channels against a WCF Defect
• Proper Disposal of WCF Channels against a WCF Defect. Follow up

Along with a few references about the details of the defects, while I had used the workaround in a few enterprise WCF applications.