Произошла ошибка записи в канал: Нераспознанная ошибка 232 (0xe8) - PullRequest
10 голосов
/ 15 мая 2011

Я вызываю метод в прокси WCF, где привязка именуется pipe.На данный момент код завершается с ошибкой (связанной с wmi - что делает код), но когда я затем выполняю другой метод в том же прокси, я получаю эту ошибку:

Произошла ошибка записи втруба: Нераспознанная ошибка 232 (0xe8).

Очевидно, это не очень помогает.Трассировка стека:

Трассировка стека сервера: в System.ServiceModel.Channels.StreamConnection.BeginWrite (буфер Byte [], смещение Int32, размер Int32, немедленное логическое значение, тайм-аут TimeSpan, обратный вызов AsyncCallback, состояние объекта)в System.ServiceModel.Channels.FramingDuplexSessionChannel.SendAsyncResult.WriteCore () в System.ServiceModel.Channels.FramingDuplexSessionChannel.SendAsyncResult..ctor (FramingDuplexSessionChannel канал, обратный вызов состояния объекта.FramingDuplexSessionChannel.OnBeginSend (сообщение-сообщение, тайм-аут TimeSpan, обратный вызов AsyncCallback, состояние объекта) в System.ServiceModel.Channels.OutputChannel.BeginSend (сообщение-сообщение, тайм-аут TimeSpan, обратный вызов AsyncCallback, состояние объекта) в System..DginupRealReader.ReaderSecreader.InterСообщение, время ожидания TimeSpan, обратный вызов AsyncCallback, состояние объекта) в System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.StartSend (Booнаклоняться completedSynchronously) на System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.FinishEnsureOpen (IAsyncResult результат, Boolean completedSynchronously) в System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.StartEnsureOpen (Boolean) completedSynchronously в System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.FinishEnsureInteractiveInit(Результат IAsyncResult, логическое завершение в синхронном режиме) в System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.StartEnsureInteractiveInit () в System.ServiceModel.Channels.ServiceChannel.SendAsyncRelnelShanChannel.hange.Sec.oneway, операция ProxyOperationRuntime, Object [] ins, тайм-аут TimeSpan, обратный вызов AsyncCallback, Object asyncState) в System.ServiceModel.Channels.ServiceChannel.BeginCall (операция String, логическая операция oneway, ProxyOperationRuntime, обратный вызов Object [], обратный вызов объекта AsyncCall)в System.ServiceModel.Channels.ServiceChannelProxy.InvokeBeginService (метод IMethodCallMessageCall, операция ProxyOperationRuntime) в System.ServiceModel.Channels.ServiceChannelProxy.Invoke (сообщение IMessage)

Исключение, переброшенное в [0]: в System.Runtime.HessalProPro (IMessage reqMsg, IMessage retMsg) в System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (MessageData & msgData, тип Int32) в x.xxx.xxxxx (обратный вызов String, AsyncCallback, состояние объекта) в x.xproxy.begininstall, Обратный вызов AsyncCallback, состояние объекта) в C: \ Users \ project \ AsyncProxy.cs: строка 38 в xxx.MainForm.begininstall (отправитель объекта, EventArgs e) в C: \ Users \ project \ MainForm.cs: строка 647 в XPrintV7.MainForm.b__e () в C: \ Users \ Gurdip \ Desktop \ xproject \ MainForm.cs: строка 664 в System.Windows.Forms.Control.InvokeMarshaledCallbackDo (ThreadMethodEntry tme) в System.Windows.Forms.Control.InvokeMarshaledCbackobj) в System.Threading.ExecutionContext.runTryCode (Object userData) в System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup (код TryCode, backoutCode CleanupCode, объект userData) в System.Threading.ExecutionContext.RunInternal (обратный вызов ExecutionContext executeContext, обратный вызов ContextCallback, состояние ExecutionContextContextExtext)Состояние объекта) вSystem.Windows.Forms.Control.InvokeMarshaledCallback (ThreadMethodEntry tme) в System.Windows.Forms.Control.InvokeMarshaledCallbacks ()

Какова вероятная причина?

1 Ответ

5 голосов
/ 16 мая 2011

Сообщение об ошибке сообщает, что ошибка Win32 ERROR_NO_DATA произошла, когда стек каналов на стороне клиента попытался отправить сообщение службе через именованный канал.Кроме того, сложно диагностировать только с помощью предоставленной вами информации, но это, вероятно, указывает на то, что клиентский и серверный концы именованного канала попали в противоречивые состояния в результате предыдущей ошибки WMI.Возможно, ваш код на стороне клиента неправильно управляет состоянием экземпляра прокси-сервера службы при возникновении исключения WMI.

Вы должны включить подробную трассировку WCF как на стороне клиента, так и на стороне службы, что обеспечит более четкое представление о происходящем.

Кроме того, публикуя часть своего клиентского кода, чтобы показать, где находится WMIвозникает исключение, и то, как служебный прокси-сервер обрабатывается при обработке исключения, может позволить кому-то более точно ответить на ваш вопрос.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...