Ich rufe eine Methode in einem WCF-Proxy auf, wo die Bindung Pipes heißt. Im Moment schlägt der Code mit einer Ausnahme fehl (im Zusammenhang mit wmi - was der Code tut), aber wenn ich dann eine andere Methode im selben Proxy ausführe, bekomme ich diesen Fehler:
Beim Schreiben in die Pipe ist ein Fehler aufgetreten: Unbekannter Fehler 232 (0xe8).
Offensichtlich hilft das nicht viel. Stacktrace ist:
Server-Stack-Ablaufverfolgung: bei System.ServiceModel.Channels.StreamConnection.BeginWrite (Byte [] -Puffer, Int32-Offset, Int32-Größe, Boolean-Unmittelbar, TimeSpan-Timeout, AsyncCallback-Callback, Objektzustand) bei System.ServiceModel.Channels.FramingDuplexSessionChannel.SendAsyncResult.WriteCore () bei System.ServiceModel.Channels.FramingDuplexSessionChannel.SendAsyncResult..ctor (FramingDuplexSessionChannel-Kanal, Nachricht, TimeSpan-Timeout, AsyncCallback-Callback, Objektzustand) bei System.ServiceModel.Channels.FramingDuplexSessionChannel.OnBeginSend (Nachricht, TimeSpan-Timeout, AsyncCallback-Callback, Objektstatus) bei System.ServiceModel.Channels.OutputChannel.BeginSend (Nachricht Nachricht, TimeSpan Timeout, AsyncCallback Callback, Objektstatus) bei System.ServiceModel.Dispatcher.DuplexChannelBinder.BeginRequest (Nachricht Nachricht, TimeSpan Timeout, AsyncCallback Callback, Object-Status) at System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.StartSend (Boolean completedSynchronously) bei System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.FinishEnsureOpen (IAsyncResult-Ergebnis, Boolean completeSynchronous) bei System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.StartEnsureOpen (Boolean completedSynchronously) bei System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.FinishEnsureInteractiveInit (IAsyncResult-Ergebnis, Boolean completeSynchronously) bei System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.StartEnsureInteractiveInit () bei System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.Begin () bei System.ServiceModel.Channels.ServiceChannel.BeginCall (String-Aktion, boolesche Methode, ProxyOperationRuntime-Operation, Object [] ins, TimeSpan-Zeitlimit, AsyncCallback-Callback, Object asyncState) bei System.ServiceModel.Channels.ServiceChannel.BeginCall (String-Aktion, boolesche Methode, ProxyOperationRuntime-Operation, Object [] ins, AsyncCallback-Callback, Object asyncState) bei System.ServiceModel.Channels.ServiceChannelProxy.InvokeBeginService (IMethodCallMessage-MethodeCall, ProxyOperationRuntime-Vorgang) bei System.ServiceModel.Channels.ServiceChannelProxy.Invoke (IMessage-Nachricht)
Ausnahme bei [0] erneut ausgelöst: bei System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage (IMessage reqMsg, IMessage retMsg) bei System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (MessageData & amp; msgData, Int32 type) bei x.xxx.xxxxx (String-Pfad, AsyncCallback-Callback, Objektstatus) unter x.xproxy.begininstall (String-Pfad, AsyncCallback-Callback, Objektstatus) in C: \ Benutzer \ Projekt \ AsyncProxy.cs: Zeile 38 bei xxx.MainForm.begininstall (Objektabsender, EventArgs e) in C: \ Benutzer \ Projekt \ MainForm.cs: Zeile 647 bei XPrintV7.MainForm.b__e () in C: \ Benutzer \ Gurdip \ Desktop \ xproject \ MainForm.cs: Zeile 664 bei System.Windows.Forms.Control.InvokeMarshaledCallbackDo (ThreadMethodEntry tme) bei System.Windows.Forms.Control.InvokeMarshaledCallbackHelper (Object Obj) bei System.Threading.ExecutionContext.runTryCode (Objekt userData) bei System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup (TryCode-Code, CleanupCode-BackoutCode, Object-userData) bei System.Threading.ExecutionContext.RunInternal (ExecutionContext executionContext, ContextCallback-Callback, Objektstatus) bei System.Threading.ExecutionContext.Run (ExecutionContext executionContext, ContextCallback-Callback, Objektstatus) bei System.Windows.Forms.Control.InvokeMarshaledCallback (ThreadMethodEntry tme) bei System.Windows.Forms.Control.InvokeMarshaledCallbacks ()
Was ist der wahrscheinliche Grund?
Die Fehlermeldung besagt, dass der Win32-Fehler ERROR_NO_DATA aufgetreten ist, als der clientseitige Channel-Stack versucht hat, über die Named Pipe eine Nachricht an den Service zu senden. Es ist schwierig, darüber hinaus nur mit den von Ihnen bereitgestellten Informationen zu diagnostizieren, aber es zeigt wahrscheinlich an, dass die Client- und Server-Enden der Named Pipe aufgrund des vorhergehenden WMI-Fehlers in inkonsistente Zustände geraten sind. Möglicherweise verwaltet der clientseitige Code den Status der Service-Proxy-Instanz nicht korrekt, wenn die WMI-Ausnahme auftritt.
Sie sollten die ausführliche WCF-Ablaufverfolgung sowohl auf der Client- als auch auf der Service-Seite aktivieren, um ein klareres Bild der Vorgänge zu erhalten.
Wenn Sie einen Teil Ihres Client-Codes angeben, um anzuzeigen, wo die WMI-Ausnahme auftritt und wie der Service-Proxy in der Ausnahmebehandlung behandelt wird, kann jemand Ihre Frage präziser beantworten.
Tags und Links wcf named-pipes