eConnect Error: Unrecognized error 232 (0xe8)

A couple of weeks ago, a client was testing Microsoft Dynamics GP 2010 R2 and reported that some of their postings from an external system were not arriving in GP (these postings are transferred using eConnect).

When I installed eConnect I enabled Journalling on the econnect_incoming queue so we would have a record of messages which had been submitted. After receiving the error I went to make sure the messages had reached the GP server (Start menu >> Control Panel >> Administrative Tools >> Computer Management >> Services and Applications >> Message Queuing >> Private Queues >> econnect_incoming >> Journal Messages);

Computer Management - Journal messages

Postings to Payables Management and the General Ledger were showing in the list of journal messages so the next step was to check the Event Viewer for eConnect (Start menu >> Control Panel >> Administrative Tools >> Computer Management >> System Tools >> Event Viewer >> Applications and Services Logs >> eConnect);

Computer Management - Event Viewer

There were three errors showing up for eConnect all with the same error description;

Event Properties - Event 906, eConnect Incoming Service

The full error description;


eConnect Incoming Service Version=11.0.0.0
Message Label:PaymentPostingBatch844
mscorlib
System.ServiceModel.CommunicationException: There was an error writing to the pipe: Unrecognized error 232 (0xe8). ---> System.IO.IOException: The write operation failed, see inner exception. ---> System.ServiceModel.CommunicationException: There was an error writing to the pipe: Unrecognized error 232 (0xe8). ---> System.IO.PipeException: There was an error writing to the pipe: Unrecognized error 232 (0xe8).
   at System.ServiceModel.Channels.PipeConnection.StartSyncWrite(Byte[] buffer, Int32 offset, Int32 size, Object& holder)
   at System.ServiceModel.Channels.PipeConnection.WriteHelper(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout, Object& holder)
   --- End of inner exception stack trace ---
   at System.ServiceModel.Channels.PipeConnection.WriteHelper(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout, Object& holder)
   at System.ServiceModel.Channels.PipeConnection.Write(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout)
   at System.ServiceModel.Channels.BufferedConnection.WriteNow(Byte[] buffer, Int32 offset, Int32 size, TimeSpan timeout, BufferManager bufferManager)
   at System.ServiceModel.Channels.BufferedConnection.Write(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout)
   at System.ServiceModel.Channels.ConnectionStream.Write(Byte[] buffer, Int32 offset, Int32 count)
   at System.Net.Security.NegotiateStream.StartWriting(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.NegotiateStream.ProcessWrite(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
   --- End of inner exception stack trace ---
   at System.Net.Security.NegotiateStream.ProcessWrite(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.NegotiateStream.Write(Byte[] buffer, Int32 offset, Int32 count)
   at System.ServiceModel.Channels.StreamConnection.Write(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout)
   --- End of inner exception stack trace ---

Server stack trace:
   at System.ServiceModel.Channels.StreamConnection.Write(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout)
   at System.ServiceModel.Channels.StreamConnection.Write(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout, BufferManager bufferManager)
   at System.ServiceModel.Channels.FramingDuplexSessionChannel.OnSend(Message message, TimeSpan timeout)
   at System.ServiceModel.Channels.OutputChannel.Send(Message message, TimeSpan timeout)
   at System.ServiceModel.Dispatcher.DuplexChannelBinder.Request(Message message, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(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 Microsoft.Dynamics.GP.eConnect.IServiceInterface.CreateEntity(String connectionString, String xml)
   at Microsoft.Dynamics.GP.eConnect.ServiceProxy.CreateEntity(String connectionString, String xml)
   at Microsoft.Dynamics.GP.eConnect.eConnectMethods.EntityImportImplementation(String connectionString, String sXML, Boolean isTransaction)
   at Microsoft.Dynamics.GP.eConnect.eConnectMethods.CreateEntity(String connectionString, String sXML)
   at Microsoft.Dynamics.GP.eConnect.Incoming.eConnect_Incoming.MyReceiveCompleted(Object source, ReceiveCompletedEventArgs asyncResult)

I did some investigation and couldn’t really find anything relevant to Microsoft Dynamics GP and eConnect but some suggestions in general that this may be a timeout issue. I hunted down the configuration xml (span class=’path’>C:\Program Files\Microsoft Dynamics\eConnect 11.0\Service\Microsoft.Dynamics.GP.eConnect.Service.exe.config) and looked for the following section;


<binding name="eConnectNamedPipeConfig" closeTimeout="00:10:00"
   sendTimeout="00:02:00" transferMode="Buffered" hostNameComparisonMode="StrongWildcard"
   maxBufferPoolSize="2147483647" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647">
   <readerQuotas maxDepth="60" maxStringContentLength="2147483647"
      maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
   <security mode="Transport">
      <transport protectionLevel="EncryptAndSign" />
   </security>
</binding>

I amended the two timeout values (highlighted below) and made them both 20 minutes;


<binding name="eConnectNamedPipeConfig" closeTimeout="00:20:00"
   sendTimeout="00:20:00" transferMode="Buffered" hostNameComparisonMode="StrongWildcard"
   maxBufferPoolSize="2147483647" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647">
   <readerQuotas maxDepth="60" maxStringContentLength="2147483647"
      maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
   <security mode="Transport">
      <transport protectionLevel="EncryptAndSign" />
   </security>
</binding>

Unfortunately, the above setting was still resulting in an intermittent error. Even more unfortunately, my part in the investigation ended at this point as I left the company for a new opportunity and this blog post remained incomplete.

My former colleague, Andrew Cooper, took over the investigation and has kindly emailed the solution. He found the answer on the PartnerSource Knowledge Base, by searching for a slightly different but related error message, in KB article 2539263 (available to everyone on the Microsoft Help And Support site) and has kindly passed the answer onto me so I can complete this blog post;


<binding name="eConnectNamedPipeConfig" closeTimeout="00:20:00"
   sendTimeout="00:20:00" receiveTimeout="infinite" transferMode="Buffered" hostNameComparisonMode="StrongWildcard"
   maxBufferPoolSize="2147483647" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647">
   <readerQuotas maxDepth="60" maxStringContentLength="2147483647"
      maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
   <security mode="Transport">
      <transport protectionLevel="EncryptAndSign" />
   </security>
</binding>

The issue is that the WCF service-oriented application can remain active for only ten minutes without activity after which it is dropped. The above change, adding receiveTimeout=”infinite”, keeps it active and prevents the error we were seeing.

Ian Grieve

About Ian Grieve

Ian is a Microsoft Dynamics GP certified consultant specialising in the delivery of Microsoft Dynamics GP projects and currently working for Perfect Image Ltd., a Microsoft Partner and VAR in the North East of England. Ian has worked with Microsoft Dynamics GP since 2003 and, over the nine years since, has dealt with all aspects of the product life-cycle from presales, to implementation, to technical and functional training, to post go-live support and subsequent upgrades and process reviews. In his spare time, Ian runs the azurecurve | Ramblings of a Dynamics GP Consultant blog dedicated to Microsoft Dynamics GP and related products.
This entry was posted in Dynamics, eConnect, GP, Microsoft and tagged , , , , , , , . Bookmark the permalink.

2 comments on “eConnect Error: Unrecognized error 232 (0xe8)

  1. Pingback: eConnect Error: Unrecognized error 232 (0xe8) | Interesting Findings & Knowledge Sharing

  2. Pingback: Everything Dynamics GP #38 | Interesting Findings & Knowledge Sharing

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>