WCF Tracing. How I can get the exact reason for closing connection?

rem picture rem · Dec 19, 2009 · Viewed 16.3k times · Source

In my WCF service, when trying transfer large data I constantly get an error: The underlying connection was closed: The connection was closed unexpectedly

I want to know what particular reason invokes this error, so I set up WCF Tracing and can read traces.svclog file.

The problem is, that I can see in this file a lot of information about flow of processes, I can see exact time when exception is appeared, but I can't see the exact reason for that. Is it due to MaxReceivedMessageSize or something like that.

Is it so that traces.svclog can not contain such information or am I doing something wrong?

How such information could be obtained?

Edited (added):

From my server-side app.config:

    <system.serviceModel>
    <bindings>
        <basicHttpBinding>
            <binding name="NAVBinding_ICustomer_Service"
                closeTimeout="01:50:00"
                openTimeout="01:50:00" receiveTimeout="01:50:00" sendTimeout="01:50:00"
                allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
                maxBufferSize="2147483647" maxBufferPoolSize="2147483647"
                maxReceivedMessageSize="2147483647" messageEncoding="Text"
                textEncoding="utf-8" transferMode="Buffered" useDefaultWebProxy="true">
                <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647"
                    maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
                <security mode="None">
                    <transport clientCredentialType="None" proxyCredentialType="None"
                        realm="" />
                    <message clientCredentialType="UserName" algorithmSuite="Default" />
                </security>
            </binding>
        </basicHttpBinding>
    </bindings>
    <services>
        <service name = "Customer_Service"  behaviorConfiguration="returnFaults">
            <endpoint name="NAVBinding_ICustomer_Service"
               address  = "http://localhost:8000/nav/customer"
               binding  = "basicHttpBinding"
               bindingConfiguration= "NAVBinding_ICustomer_Service"
               contract = "NAVServiceReference.ICustomer_Service"/>
        </service>
    </services>
    <behaviors>
        <serviceBehaviors>
            <behavior name="returnFaults" >
                <serviceDebug includeExceptionDetailInFaults="true" />
                <serviceMetadata httpGetEnabled="true" />
            </behavior>
        </serviceBehaviors>
    </behaviors>
 </system.serviceModel>

Edited (added):

What is the right and best way to turn WCF service from a "black box" to an easily troubleshooted service, which tells the reason why something goes not the expected way? What tools, techniques you use to troubleshoot WCF service?

Answer

Andrew Patterson picture Andrew Patterson · Dec 29, 2009

Ignoring the problems with the maxRequestLength (which have been answered by others), I will have a go at answering your original question about how to troubleshoot WCF.

If you are already using the Service Trace Viewer (I couldn't tell from the question if you were just viewing them by hand) - it is possible that all the details aren't going into the file.

When I want to get really hardcore, I enable all the logging parameters for message logging. (This will generate some big service logs though so don't leave it on)

 <system.serviceModel>
  <diagnostics>
   <messageLogging logEntireMessage="true" logMalformedMessages="true" logMessagesAtServiceLevel="true" logMessagesAtTransportLevel="true" maxMessagesToLog="-1" />
  </diagnostics>
 </system.serviceModel>

If you are not using the Microsoft Service Trace Viewer I recommend that. It gives all the information I need to track down those tricky message handshake, message size exceptions etc. Here is an MSDN reference to get you started http://msdn.microsoft.com/en-us/library/aa751795.aspx

Trace interactions that have potential problems are hilighted in yellow on the left, and the detailed pane on the top right will normally hilight the exceptional service event in red. Sometimes you will get multiple problems as the inner error cascades through the service stack - but you can see it all in the trace viewer.

Troubleshooting Using the Service Trace Viewer

If you get nothing in your server 'service log', then it is possible your exceptions are entirely at the client end - theoretically you could exceed some of the client side security parameters (message size etc) before any message has actually reached the web service end - but client problems are generally easier to track down because you know you only have to worry about editing the config file at the client end (i.e. it's not because of any interaction between the client and server settings).