I think WCF is a pretty sweet technology stack. It makes things work with each other quite easily..... until you use it for more than the default it was setup to handle. This usually results in some strange and hard to diagnose error messages.

The #1 tip I have so far is to use the SvcConfigEditor.exe file that comes with the Windows SDK to edit your configuration files as it allows you to edit the configuration in a simple and visual fashion and makes it much harder to make errors in your config file.

Problem: The content type text/html; charset=utf-8 of the response message does not match the content type of the binding.
Usual Reason: Your service is returning an HTTP error and not a WCF message. This most often occurs because your config file is not valid or the page is not found.
Solution: The first thing is to narrow down the error by opening the service in your browser and making sure it can return wsdl (i.e. http://localhost/MyFirstService/HelloWorldService.svc?wsdl). This will point you to the problem 99% of the time (and for me 99% of the time was I put in some configuration that was not valid)

Problem: The Server was unable to process the request due to an internal error.
Usual Reason: The service probably threw an exception so the message could not be returned.
Solution: On the server turn on IncludeExceptionDetailInFaults so that the client can see the error message if that is what you desire. Otherwise fix the reason why the application is throwing an exception.

Problem: The message could not be processed. This is most likely because the action '...' is incorrect or because the message contains an invalid or expired security context token or because there is a mismatch between bindings
Usual Reason: The server says it is behaving in one fashion and the client expects another.
Solution: You could look over the client and server configuration files until your eyes bleed or take what I have found to be the easy way out: Use the SvcConfigEditor.exe to regenerate your client configuration file.

Problem: Exceeded MaxItemsInObjectGraph quota. Maximum number of items that can be serialized or deserialized in an object graph is '65536'.
Usual Reason: There amount of objects to be serialized exceeds the default limit. This is probably a limit put in place to prevent a denial of service attack so you can set this to be a reasonable level for your application.
Solution:

Change the server/client to increase the maximum objects serialized

Change the server:
<service behaviorConfiguration="LargeMessageBehaviour" name="MyFirstService.HelloWorldService">
        <endpoint address="http://localhost/MyFirstService/HelloWorldService.svc"
                    binding="basicHttpBinding"
                    contract="MyFirstService.IHelloWorldService" />
      </service>

<behaviors>
  <serviceBehaviors>
    <behavior name="LargeMessageBehaviour">
      <dataContractSerializer maxItemsInObjectGraph="6553600" />
    </behavior>
  </serviceBehaviors>
</behaviors>

Change the client:

 <client>
      <endpoint address="http://localhost/MyFirstService/HelloWorldService.svc"
        behaviorConfiguration="LargeMessageBehavior" binding="basicHttpBinding" />
</client>

<behaviors>
  <endpointBehaviors>
     <behavior name="LargeMessageBehavior" >
         <dataContractSerializer maxItemsInObjectGraph="6553600"/>
      </behavior>
   </endpointBehaviors>
</behaviors>

Problem: System.Net.WebException: The underlying connection was closed: The connection was closed unexpectedly
Usual Reason: This is the really generic error message I find and can be for multiple reasons. So far I have only had it when hosting a service in IIS.
Solution: As there are several possible causes there are several possible solutions
1. If you are sending lots of data IIS will reject anything over a certain limit by default. You can change this setting with:
<system.web>
    <httpRuntime maxRequestLength="734000"/>
</system.web>
2. If your request takes a long time to process IIS can timeout. You can change this via:
<system.web>
    <httpRuntime executionTimeout="500" />
</system.web>
3. Something else went wrong and instead of responding the webserver just decided to shut down. In this case you will have to enable tracing on the server and or client to narrow down the error (see debugging steps below)


Debugging Steps
Here are the usual steps I take to narrow down a problem. Each problem is unique though so some of these steps may not apply:
1. Open up the service wsdl in a browser to make sure that the service is working: (i.e. http://localhost/MyFirstService/HelloWorldService.svc?wsdl).
2.  Often issues arise because of configuration issues. I often find myself editing the configuration files using the SvcConfigEditor.exe file that comes with the windows SDK which can help you find the right spot to make configuration changes.
3.   I also find that mirroring my changes from the server behaviour to the client is a source of issues. You can use the SvcConfigEditor.exe tool to generate the client configuration based on a server configuration file.
4.   Enable tracing. This will allow you to log a lot more information about the client/server interaction and usually reveals more details about an issue. This is easiest to enable via the SvcConfigEditor.exe again and the logs can be easily viewed with the SvcTraceViewer.exe file (Both are part of the Windows SDK)