Question

I call a method in a WCF proxy, where the binding is named pipes. At the moment, the code fails with an exception (related to wmi – what the code does), but when I then execute another method in the same proxy, I get this error:

There was an error writing to the pipe: Unrecognized error 232 (0xe8).

Obviously, this doesn’t help much. Stacktrace is:

Server stack trace: at
System.ServiceModel.Channels.StreamConnection.BeginWrite(Byte[]
buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout,
AsyncCallback callback, Object state) at
System.ServiceModel.Channels.FramingDuplexSessionChannel.SendAsyncResult.WriteCore()
at
System.ServiceModel.Channels.FramingDuplexSessionChannel.SendAsyncResult..ctor(FramingDuplexSessionChannel
channel, Message message, TimeSpan timeout, AsyncCallback callback,
Object state) at
System.ServiceModel.Channels.FramingDuplexSessionChannel.OnBeginSend(Message
message, TimeSpan timeout, AsyncCallback callback, Object state) at
System.ServiceModel.Channels.OutputChannel.BeginSend(Message message,
TimeSpan timeout, AsyncCallback callback, Object state) at
System.ServiceModel.Dispatcher.DuplexChannelBinder.BeginRequest(Message
message, TimeSpan timeout, AsyncCallback callback, Object state) at
System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.StartSend(Boolean
completedSynchronously) at
System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.FinishEnsureOpen(IAsyncResult
result, Boolean completedSynchronously) at
System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.StartEnsureOpen(Boolean
completedSynchronously) at
System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.FinishEnsureInteractiveInit(IAsyncResult
result, Boolean completedSynchronously) at
System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.StartEnsureInteractiveInit()
at System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.Begin()
at System.ServiceModel.Channels.ServiceChannel.BeginCall(String
action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins,
TimeSpan timeout, AsyncCallback callback, Object asyncState) at
System.ServiceModel.Channels.ServiceChannel.BeginCall(String action,
Boolean oneway, ProxyOperationRuntime operation, Object[] ins,
AsyncCallback callback, Object asyncState) at
System.ServiceModel.Channels.ServiceChannelProxy.InvokeBeginService(IMethodCallMessage
methodCall, ProxyOperationRuntime operation) at
System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage
message)

Exception rethrown at [0]: at
System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
reqMsg, IMessage retMsg) at
System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
msgData, Int32 type) at x.xxx.xxxxx(String Path, AsyncCallback
callback, Object state) at x.xproxy.begininstall(String path,
AsyncCallback callback, Object state) in
C:\Users\project\AsyncProxy.cs:line 38 at
xxx.MainForm.begininstall(Object sender, EventArgs e) in
C:\Users\project\MainForm.cs:line 647 at
XPrintV7.MainForm.b__e() in
C:\Users\Gurdip\Desktop\xproject\MainForm.cs:line 664 at
System.Windows.Forms.Control.InvokeMarshaledCallbackDo(ThreadMethodEntry
tme) at
System.Windows.Forms.Control.InvokeMarshaledCallbackHelper(Object obj)
at System.Threading.ExecutionContext.runTryCode(Object userData) at
System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode
code, CleanupCode backoutCode, Object userData) at
System.Threading.ExecutionContext.RunInternal(ExecutionContext
executionContext, ContextCallback callback, Object state) at
System.Threading.ExecutionContext.Run(ExecutionContext
executionContext, ContextCallback callback, Object state) at
System.Windows.Forms.Control.InvokeMarshaledCallback(ThreadMethodEntry
tme) at System.Windows.Forms.Control.InvokeMarshaledCallbacks()

What is the probable cause?

Answer 1

The error message tells you that the Win32 error ERROR_NO_DATA occurred when the client-side channel stack tried to send a message to the service over the named pipe. It’s difficult to diagnose beyond that with just the info you have provided, but it probably indicates that the client and server ends of the named pipe have got into inconsistent states as a result of the preceding WMI error. Possibly your client-side code is not managing the state of the service proxy instance correctly when the WMI exception happens.

You should enable verbose WCF tracing on both client and service sides, which will provide a clearer picture of what is going on.

Also, posting some of your client code to show where the WMI exception occurs, and how the service proxy is dealt with in the exception handling, may enable someone to answer your question more precisely.