Question

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 1

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.

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).