Why Does WCF Throw EndpointNotFoundException (2026 Guide)

If you have ever stared at a System.ServiceModel.EndpointNotFoundException in your WCF application and thought “but the service IS running,” you are not alone. This is one of the most frustrating errors in the .NET ecosystem because the message almost never points to the actual problem. I have spent more hours than I care to admit chasing this exception across client configs, server bindings, firewalls, and IIS settings, only to discover the root cause was something completely unexpected.

Here is the direct answer: a WCF service throws EndpointNotFoundException when the client cannot connect to the service endpoint. This happens most often because the endpoint address is wrong, the service is not running, a firewall blocks the connection, or the client and server bindings do not match. But here is the catch: the error can also appear when a server-side exception occurs during the operation call, making it one of the most misleading exceptions in WCF.

In this guide, I will walk you through every possible reason your WCF service throws EndpointNotFoundException, from the obvious to the obscure. I will cover the exception hierarchy, common causes, the notorious “red herring” problem where the error masks a server-side crash, binding-specific troubleshooting for basicHttpBinding, netTcpBinding, and webHttpBinding, a step-by-step diagnostic checklist, configuration deep dives with real code examples, WCF tracing setup, and modern alternatives if you are ready to move beyond WCF entirely.

Whether you are debugging a self-hosted service on localhost or troubleshooting a production IIS-hosted WCF service across multiple machines, this guide will help you systematically find and fix the problem. Let us start with the quick summary so you can jump straight to the fix that applies to your situation.

Quick Summary: Top Causes and Fixes

Before we go deep into the technical details, here is a quick reference table. I built this from my own debugging experience combined with patterns from Stack Overflow threads that have accumulated over 70,000 views. If you are in a hurry, scan the symptoms column and jump to the corresponding fix.

Symptom	Root Cause	Solution
Service runs fine in browser, fails from client code	Binding mismatch or SOAP action mismatch	Compare client and server binding configurations element by element
Error appears intermittently	Service throttling limits or receive timeout	Increase MaxConcurrentSessions and receiveTimeout in service behavior
SocketException with error code 10060	Firewall blocking or service not listening on port	Check Windows Firewall rules, verify with netstat -an
Works on localhost, fails cross-machine	Kerberos/SPN configuration or base address binding	Configure SPN or use DNS hostname, set UseDefaultWebProxy
HTTP 404.3 Not Found	HTTP Activation not enabled in IIS/WAS	Enable WCF HTTP Activation via Server Manager or DISM
Error on every call but service is running	Server-side unhandled exception (red herring)	Enable includeExceptionDetailInFaults and check server logs
Works first few times, then fails	MaxConcurrentSessions exhausted	Close client proxies properly, increase throttle limits
Suddenly stops working after deployment	Endpoint address changed or service moved	Update service reference, verify endpoint address in app.config

Keep this table handy. I reference these patterns throughout the rest of the guide with detailed explanations and code examples for each scenario.

Understanding the EndpointNotFoundException

To diagnose this error effectively, you need to understand where it sits in the .NET exception hierarchy and when WCF chooses to throw it over other communication exceptions. This context helps you read stack traces correctly and avoid chasing the wrong problem.

The Exception Hierarchy

The EndpointNotFoundException lives within the System.ServiceModel namespace and inherits from a chain of communication-related exceptions. Here is the inheritance chain from the base class down:

System.Exception
  → System.SystemException
    → System.ServiceModel.CommunicationException
      → System.ServiceModel.EndpointNotFoundException

This hierarchy matters because WCF wraps most communication errors in CommunicationException. If you are writing a catch block, catching CommunicationException will also catch EndpointNotFoundException. But catching EndpointNotFoundException specifically lets you handle connection-level failures differently from protocol-level faults.

What the Error Actually Means

When WCF throws EndpointNotFoundException, it is telling you one fundamental thing: the client attempted to send a message to a service endpoint, and the underlying transport could not deliver it. The word “not found” is misleading because it implies the endpoint address is wrong. In reality, the transport layer simply could not complete the connection for any number of reasons.

Think of it like calling a phone number. If nobody picks up, you get a “number not reachable” message. But the phone number itself could be perfectly valid. The person might be asleep, the phone might be off, the network might be down, or the number might have changed. WCF gives you the same generic message for all these scenarios.

When WCF Throws EndpointNotFoundException vs Other Exceptions

WCF has several communication-related exceptions, and knowing which one you got helps narrow down the problem:

EndpointNotFoundException: The client could not reach the service at all. The endpoint address resolution failed, the service was not listening, or the connection was refused.

TimeoutException: The client connected to the service but the operation took too long. However, under certain conditions, WCF throws EndpointNotFoundException instead of TimeoutException when the open timeout expires, which causes confusion.

CommunicationException: A general communication failure occurred. This is the base class and catches everything the more specific exceptions do not.

ProtocolException: The client connected to the service but the message protocol did not match. This often indicates a binding mismatch where both sides use different message encodings or security settings.

FaultException: The service received the message and processed it, but the service code threw an exception. If you see this, your connection is fine.

Always check the InnerException property. The inner exception often contains the real diagnostic information. A SocketException inner exception with error code 10060 means a connection timeout at the TCP level. A WebException with a 404 status means the HTTP server responded but did not find the resource.

Common Causes of WCF EndpointNotFoundException

Now let us go through the most common causes one by one. I have ordered these roughly by frequency based on what I see in Stack Overflow threads, Microsoft Q&A posts, and my own debugging sessions.

Cause 1: Incorrect Endpoint Address

This is the most common cause and also the easiest to fix. The endpoint address in your client configuration does not match the actual address where the service is listening. A single typo, a wrong port number, or an outdated hostname will trigger EndpointNotFoundException immediately.

Check your client’s app.config or web.config. The address attribute in the <endpoint> element must exactly match the service’s configured address. Here is a correct configuration:

<!-- Client app.config -->
<client>
  <endpoint address="http://localhost:8080/MyService/myservice"
            binding="basicHttpBinding"
            bindingConfiguration="BasicHttpBinding_IMyService"
            contract="MyServiceReference.IMyService"
            name="BasicHttpBinding_IMyService" />
</client>

Common address mistakes include using localhost instead of the actual machine name for cross-machine calls, forgetting the service file extension (.svc), using HTTP instead of HTTPS when the service requires transport security, and specifying a port that the service is not actually listening on.

Cause 2: Service Not Running or Not Listening

The service might simply not be running. This sounds obvious, but it is surprisingly easy to miss. A self-hosted WCF service in a console application needs to be actively running. An IIS-hosted service needs the application pool to be started. A Windows service host needs the service to be in a running state.

For self-hosted services, verify that the ServiceHost is actually open:

// Self-hosted service startup
ServiceHost host = new ServiceHost(typeof(MyService));
host.Open();
Console.WriteLine("Service running at: " + host.BaseAddresses[0]);

For IIS-hosted services, open IIS Manager and verify the application pool is running. Check that the site is started. Browse to the .svc file directly in IIS Manager to confirm the service responds.

You can also use netstat to verify the service is listening on the expected port:

netstat -an | findstr "8080"

If this command returns nothing, the service is not listening on that port. This is a definitive confirmation that the problem is on the server side.

Cause 3: Binding Mismatch Between Client and Server

The client and server must use compatible bindings. If the server uses basicHttpBinding and the client uses wsHttpBinding, the connection will fail. But the failure does not always show up as a ProtocolException. Under certain conditions, WCF reports this as EndpointNotFoundException, which is confusing.

Compare the binding and bindingConfiguration attributes on both sides. They must reference the same binding type with compatible settings. Pay attention to message encoding (text vs MTOM), security mode (None vs Transport vs Message), and transaction flow settings.

Here is an example of a binding mismatch that causes problems:

<!-- Server web.config (uses basicHttpBinding) -->
<services>
  <service name="MyNamespace.MyService">
    <endpoint address="" binding="basicHttpBinding"
              contract="MyNamespace.IMyService" />
  </service>
</services>

<!-- Client app.config (incorrectly uses wsHttpBinding) -->
<client>
  <endpoint address="http://server/MyService.svc"
            binding="wsHttpBinding"
            contract="MyServiceReference.IMyService" />
</client>

The fix is simple: change the client binding to basicHttpBinding to match the server. But finding this mismatch requires careful comparison of both config files, which is why so many developers struggle with it.

Cause 4: Firewall or Network Blocking

Windows Firewall, corporate firewalls, and network security appliances can all block the connection between client and service. This is especially common when moving from localhost development to cross-machine or production deployment.

If the inner exception is a SocketException with error code 10060 (connection attempt failed), you are almost certainly dealing with a firewall or network issue. The client tried to connect, but the connection attempt timed out because something blocked it.

To diagnose firewall issues on Windows, check the inbound rules:

netsh advfirewall firewall show rule name=all dir=in | findstr "8080"

If no rule exists for your service port, add one:

netsh advfirewall firewall add rule name="WCF Service" dir=in action=allow protocol=TCP localport=8080

For corporate networks, check whether a proxy server or reverse proxy is intercepting requests. Set useDefaultWebProxy="true" in your binding configuration if the client needs to go through a corporate proxy.

Cause 5: IIS and WAS Hosting Issues

If your WCF service is hosted in IIS, several IIS-specific issues can cause EndpointNotFoundException. The most common is that WCF HTTP Activation is not enabled on the server. Without this Windows feature, IIS does not know how to handle .svc files.

To enable WCF HTTP Activation, use Server Manager or run this DISM command:

dism /online /enable-feature /featurename:WCF-HTTP-Activation

For non-HTTP bindings like netTcpBinding, you also need TCP Activation and the Net.TCP Listener Adapter service running:

dism /online /enable-feature /featurename:WCF-TCP-Activation
dism /online /enable-feature /featurename:WCF-NonHTTP-Activation

Also verify the application pool is running and has the correct .NET CLR version. A stopped application pool or a .NET Framework version mismatch will prevent the service from responding.

Cause 6: Security Configuration Mismatches

Security settings must match between client and server. If the server requires transport security (HTTPS) but the client connects with plain HTTP, the connection fails. Similarly, if the server expects message-level security with a specific algorithm suite, the client must be configured to match.

Common security mismatches include:

The server binding specifies security mode="Transport" but the client uses security mode="None". The server expects a client certificate for mutual authentication but the client does not provide one. The server uses Windows authentication with Kerberos but the SPN is not registered correctly for cross-machine scenarios.

For cross-machine communication with Windows authentication, ensure the service is accessible via its fully qualified domain name or that an SPN is registered. Mismatched machine names and SPNs are a notorious source of security-related connection failures.

Cause 7: Timeouts Masquerading as EndpointNotFoundException

One of the most confusing behaviors in WCF is that it sometimes throws EndpointNotFoundException when the real problem is a timeout. This happens when the openTimeout expires before the connection is established. Instead of throwing TimeoutException, WCF wraps it in an EndpointNotFoundException with a SocketException inner exception.

If your error message contains something like “A connection attempt failed because the connected party did not properly respond after a period of time,” you are dealing with this exact scenario. The fix is not to increase the timeout (though that can help as a temporary measure) but to find out why the connection is taking so long or failing silently.

Increase the timeouts temporarily to see if the error changes:

<bindings>
  <basicHttpBinding>
    <binding name="LongTimeout"
             openTimeout="00:05:00"
             sendTimeout="00:05:00"
             receiveTimeout="00:10:00" />
  </basicHttpBinding>
</bindings>

If the error disappears with longer timeouts, you have a slow connection or a service that takes too long to start. If it persists, you have a hard network block.

Cause 8: Service Throttling and Quota Exhaustion

WCF has built-in throttling that limits concurrent connections, sessions, and calls. When these limits are exceeded, new connections fail. By default, MaxConcurrentSessions is set to 100 in newer versions of .NET Framework, but in older versions it was 10.

If your service works for the first several calls and then starts throwing EndpointNotFoundException, you may be hitting throttle limits. The most common cause is not properly closing client proxies. Each unclosed proxy holds a session, and eventually the session limit is reached.

Always close client proxies properly:

// Correct pattern for closing WCF client proxies
try
{
    client.MyOperation();
    client.Close();
}
catch (CommunicationException)
{
    client.Abort();
}
catch (TimeoutException)
{
    client.Abort();
}

Increase throttle limits if your application legitimately needs more concurrent sessions:

<behaviors>
  <serviceBehaviors>
    <behavior name="MyServiceBehavior">
      <serviceThrottling
        maxConcurrentCalls="100"
        maxConcurrentSessions="200"
        maxConcurrentInstances="200" />
    </behavior>
  </serviceBehaviors>
</behaviors>

The “Red Herring” Problem: When the Error Lies

This is the section I wish I had read years ago. The EndpointNotFoundException is notorious for masking server-side exceptions. The error message tells you the endpoint was not found, but the actual problem is an unhandled exception in your service code. I have seen developers spend entire days updating service references, checking firewall rules, and reconfiguring bindings because they trusted the error message.

How Server-Side Exceptions Mask Themselves

Here is what happens behind the scenes. The client sends a message to the service. The service receives it and begins processing. During processing, an exception is thrown in the service implementation. If includeExceptionDetailInFaults is not enabled (which is the default in production), WCF cannot send the actual exception details back to the client. Instead, the channel faults, and the client receives a generic communication failure that gets reported as EndpointNotFoundException.

This behavior is documented in a famous Stack Overflow thread with over 70,000 views. The asker had a RESTful WCF service that worked perfectly in the browser but threw EndpointNotFoundException from client code. After days of troubleshooting bindings, addresses, and network configuration, the accepted answer revealed the real cause: an unhandled InvalidOperationException in the service method implementation.

Real-World Case Study

Here is a simplified version of the scenario from that Stack Overflow thread. The service was configured correctly, the endpoint address was right, and the binding matched. The service ran fine when tested via the WCF Test Client or a browser. But every call from the application client threw EndpointNotFoundException.

The problem turned out to be an envelope version mismatch combined with a server-side serialization error. The client was sending a SOAP 1.2 message, but the server expected SOAP 1.1. When the server tried to deserialize the message, it threw an exception. Because includeExceptionDetailInFaults was false, the exception was swallowed, and the channel faulted. The client saw this as a connection failure and reported it as EndpointNotFoundException.

How to Tell the Difference

So how do you know if your EndpointNotFoundException is real or a red herring? Here are the telltale signs:

It is a red herring if: The service works when you test it directly (browser, WCF Test Client, or a simple console test client) but fails from your application client. The error appears intermittently rather than consistently. The inner exception is null or contains a vague communication error rather than a specific SocketException.

It is a real connection failure if: The error happens consistently from all clients. netstat shows the service is not listening on the expected port. ping or telnet to the service host fails. The inner exception is a SocketException with a specific error code.

The single most effective diagnostic step is to enable includeExceptionDetailInFaults on the service:

<behaviors>
  <serviceBehaviors>
    <behavior name="DebugBehavior">
      <serviceDebug includeExceptionDetailInFaults="true" />
    </behavior>
  </serviceBehaviors>
</behaviors>

With this enabled, the actual server-side exception details will be returned in the fault. You will see the real error instead of the misleading EndpointNotFoundException. Never leave this enabled in production, but during debugging, it is invaluable.

Binding-Specific Troubleshooting

Different WCF bindings have different failure modes. An error that applies to basicHttpBinding might not apply to netTcpBinding. Let me break down the most common bindings and their specific gotchas.

basicHttpBinding Troubleshooting

basicHttpBinding is the simplest WCF binding and the most commonly used for SOAP web services. It communicates over HTTP or HTTPS using SOAP 1.1. Most EndpointNotFoundException errors with this binding come from address issues or missing HTTP Activation.

If you get a 404 status in the inner exception, the service host is running but the URL path is wrong. Check for missing or extra path segments. If you get a connection refused error, the service or IIS is not listening on that port.

One common gotcha: the base address and endpoint address are combined. If your service has a base address of http://localhost/MyService.svc and the endpoint address is set to basic, the full address becomes http://localhost/MyService.svc/basic. Make sure the client uses the combined address.

netTcpBinding Troubleshooting

netTcpBinding uses TCP transport and is designed for WCF-to-WCF communication. It is faster than HTTP bindings but has more infrastructure requirements. The most common cause of EndpointNotFoundException with this binding is port sharing configuration.

By default, netTcpBinding uses port 808. If you have multiple services using netTcpBinding, they need the Net.TCP Port Sharing Service enabled. If this Windows service is not running, only the first service will start, and subsequent services will throw EndpointNotFoundException on the client side.

Start the Net.TCP Port Sharing Service and set it to automatic:

sc config NetTcpPortSharing start= auto
sc start NetTcpPortSharing

Also enable portSharingEnabled="true" in your binding configuration:

<netTcpBinding>
  <binding name="tcpBinding" portSharingEnabled="true">
    <security mode="None" />
  </binding>
</netTcpBinding>

Firewall rules are also critical for netTcpBinding. TCP port 808 (or whichever port you use) must be open on both the server firewall and any network firewalls between client and server.

webHttpBinding Troubleshooting

webHttpBinding is used for RESTful WCF services. It sends plain XML or JSON over HTTP without SOAP envelopes. Troubleshooting this binding has some unique aspects compared to SOAP bindings.

The most common issue is the webHttp endpoint behavior. Without this behavior, the endpoint expects SOAP messages. If your client sends a REST request to an endpoint without the webHttp behavior, the server cannot process it and throws an exception that may surface as EndpointNotFoundException.

Make sure the endpoint behavior is configured:

<endpointBehaviors>
  <behavior name="webBehavior">
    <webHttp />
  </behavior>
</endpointBehaviors>

And apply it to your endpoint:

<endpoint address="" binding="webHttpBinding"
          behaviorConfiguration="webBehavior"
          contract="MyNamespace.IMyRestService" />

Another common issue with webHttpBinding is URI template mismatches. If the WebGet or WebInvoke attribute has a UriTemplate that does not match the client request, the server returns a 404, which the client may interpret as EndpointNotFoundException.

wsHttpBinding Troubleshooting

wsHttpBinding uses SOAP 1.2 with WS-* standards including WS-Security and WS-ReliableMessaging. It is more complex than basicHttpBinding and has more ways to fail.

The most common issue is security negotiation failure. By default, wsHttpBinding uses message security with Windows authentication. If the client and server are not in the same domain or do not have proper Kerberos configuration, the security negotiation fails and the connection is refused.

For development or non-domain environments, disable security:

<wsHttpBinding>
  <binding name="noSecurity">
    <security mode="None" />
  </binding>
</wsHttpBinding>

For production with security enabled, ensure proper Kerberos SPN configuration. Register the SPN for the service account:

setspn -S HTTP/server.domain.com DOMAIN\ServiceAccount

Binding Compatibility Quick Reference

Here is a quick reference for binding compatibility and common issues:

Binding	Transport	Common Failure Cause	Key Check
basicHttpBinding	HTTP/HTTPS	Wrong address or HTTP Activation not enabled	Verify .svc URL, check IIS features
netTcpBinding	TCP	Port sharing service not running	Check NetTcpPortSharing service status
webHttpBinding	HTTP/HTTPS	Missing webHttp behavior	Verify endpoint behavior configuration
wsHttpBinding	HTTP/HTTPS	Security negotiation failure	Check Kerberos SPN or disable security for testing
netNamedPipeBinding	Named pipe	Only works on same machine	Cannot use across machines
netMsmqBinding	MSMQ	Message queue not installed or configured	Verify MSMQ is installed, queue exists

Step-by-Step Troubleshooting Checklist

When you hit EndpointNotFoundException, follow this systematic checklist. I have ordered these steps from simplest and most common to most complex. Work through them in order and you will find the problem.

Step 1: Verify the Service Is Running

Before touching any configuration files, confirm the service is actually running. For a self-hosted service, check that the console window or Windows service is active. For an IIS-hosted service, open IIS Manager and verify the application pool is running and the site is started.

Browse to the service URL in a web browser. You should see the WCF service help page. If you see a 404 or connection error, the service is not running or the address is wrong.

Step 2: Check the Endpoint Address in Configuration

Open the client’s app.config or web.config. Find the <endpoint> element and compare the address character by character with the server configuration. Look for typos, wrong ports, missing path segments, and protocol mismatches (HTTP vs HTTPS).

Pay special attention to the machine name. If the service is on another machine, localhost will not work. Use the actual hostname or IP address.

Step 3: Test From a Browser

Open the service URL in a browser. For SOAP services, you should see the WCF service page with a link to the WSDL. For RESTful services, try a GET request to one of your operation endpoints.

If the service responds in the browser but not from your client code, you are dealing with a binding mismatch, a red herring server-side exception, or a client configuration error. This is the most important diagnostic distinction to make.

Step 4: Verify Network Connectivity

Use these command-line tools to verify the client can reach the server:

Ping the server:

ping serverhostname

Test if the port is reachable using PowerShell:

Test-NetConnection -ComputerName serverhostname -Port 8080

Check if the service is listening using netstat:

netstat -an | findstr "8080"

If ping fails, you have a network routing or DNS issue. If ping works but the port test fails, you have a firewall or service-not-listening issue.

Step 5: Compare Client and Server Bindings

Print out both the server web.config and client app.config binding sections. Compare them line by line. Check the binding type, security mode, message encoding, and any custom binding elements.

A shortcut: generate a fresh client proxy using svcutil and compare the generated configuration with your current client config. Any differences are potential problem sources:

svcutil http://server/MyService.svc?wsdl /config:app.config

Step 6: Check Firewall Rules

On the server, verify that the service port is open in Windows Firewall:

netsh advfirewall firewall show rule name=all dir=in | findstr "8080"

If no rule exists, add one. Also check any third-party firewall software on the server. For corporate networks, work with your network team to verify that network firewalls or security appliances are not blocking the connection.

Step 7: Enable WCF Tracing

If steps 1 through 6 do not reveal the problem, enable WCF tracing on both client and server. This is the most powerful diagnostic tool available for WCF. The trace files will show you exactly what happens at every stage of the communication pipeline.

Add this to your server web.config:

<system.diagnostics>
  <sources>
    <source name="System.ServiceModel"
            switchValue="Information, ActivityTracing"
            propagateActivity="true">
      <listeners>
        <add name="traceListener"
             type="System.Diagnostics.XmlWriterTraceListener"
             initializeData="c:\logs\ServerTrace.svclog" />
      </listeners>
    </source>
  </sources>
</system.diagnostics>

Add a similar configuration to the client app.config with a different output file name. Reproduce the error and then open both trace files in SvcTraceViewer to see exactly where the communication breaks down.

Step 8: Check IIS and WAS Configuration

For IIS-hosted services, verify that all required Windows features are enabled. The minimum set for HTTP-based WCF services includes:

.NET Framework 4.x or later, WCF HTTP Activation, IIS ASP.NET feature registration. For TCP bindings, also enable WCF TCP Activation and the Net.TCP Listener Adapter.

Run this command to register ASP.NET with IIS:

aspnet_regiis -i

And check that the application pool is configured with the correct .NET CLR version and that the managed pipeline mode matches your application requirements.

Configuration Deep Dive: Web.config and App.config

Configuration is where most WCF problems live. The XML-based configuration system is powerful but unforgiving. A single misplaced attribute or incorrect namespace can cause hours of debugging. Let me walk you through the most important configuration elements and common mistakes.

Server-Side Configuration

The server’s web.config defines the service, its endpoints, bindings, and behaviors. Here is a complete example of a correctly configured service:

<configuration>
  <system.serviceModel>
    <services>
      <service name="MyNamespace.MyService"
               behaviorConfiguration="MyServiceBehavior">
        <endpoint address=""
                  binding="basicHttpBinding"
                  bindingConfiguration="MyBindingConfig"
                  contract="MyNamespace.IMyService" />
        <endpoint address="mex"
                  binding="mexHttpBinding"
                  contract="IMetadataExchange" />
      </service>
    </services>

    <bindings>
      <basicHttpBinding>
        <binding name="MyBindingConfig"
                 maxReceivedMessageSize="10485760"
                 receiveTimeout="00:10:00"
                 sendTimeout="00:10:00">
          <security mode="None" />
        </binding>
      </basicHttpBinding>
    </bindings>

    <behaviors>
      <serviceBehaviors>
        <behavior name="MyServiceBehavior">
          <serviceMetadata httpGetEnabled="true" />
          <serviceDebug includeExceptionDetailInFaults="true" />
          <serviceThrottling
            maxConcurrentCalls="100"
            maxConcurrentSessions="200"
            maxConcurrentInstances="200" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>

Notice the MEX endpoint. This allows clients to discover the service metadata and generate proxies using svcutil or the Add Service Reference dialog. Without it, clients cannot generate configuration automatically.

Client-Side Configuration

The client’s app.config must mirror the server configuration for binding and security settings. Here is a correct client configuration:

<configuration>
  <system.serviceModel>
    <bindings>
      <basicHttpBinding>
        <binding name="MyBindingConfig"
                 maxReceivedMessageSize="10485760"
                 receiveTimeout="00:10:00"
                 sendTimeout="00:10:00">
          <security mode="None" />
        </binding>
      </basicHttpBinding>
    </bindings>

    <client>
      <endpoint address="http://server.domain.com/MyService.svc"
                binding="basicHttpBinding"
                bindingConfiguration="MyBindingConfig"
                contract="MyServiceReference.IMyService"
                name="BasicHttpBinding_IMyService" />
    </client>
  </system.serviceModel>
</configuration>

The bindingConfiguration name on the client must match a named binding in the client’s <bindings> section. If it does not match, the client uses the default binding settings, which may not be compatible with the server.

Common Configuration Mistakes

Here are the mistakes I see most frequently:

Namespace mismatch: The service name in the config must include the full namespace. MyService is not the same as MyNamespace.MyService. If the namespace is wrong, the service will not start and the endpoint will not be found.

Missing bindingConfiguration: If the bindingConfiguration attribute references a name that does not exist in the bindings section, WCF silently uses defaults. The defaults are often incompatible with custom server settings.

Security mode mismatch: If the server requires transport security but the client has security mode set to None, the connection fails silently. Always verify security settings match on both sides.

Wrong contract name: The contract attribute must match the fully qualified interface name including namespace. A typo here means the endpoint is configured but does not match any known contract.

Forgetting to update service references: After changing the server contract or binding, regenerate the client proxy. Stale proxies are a common source of mysterious errors.

Advanced Diagnostics: WCF Tracing and Message Logging

When basic troubleshooting fails, WCF tracing is your best friend. It records every message, every connection attempt, and every exception that occurs in the WCF pipeline. Let me walk you through setting it up step by step.

Setting Up WCF Tracing

Add the <system.diagnostics> section to your configuration file. For comprehensive diagnostics, use two trace sources: one for the service model layer and one for the message logging layer.

<system.diagnostics>
  <sources>
    <source name="System.ServiceModel"
            switchValue="Information, ActivityTracing"
            propagateActivity="true">
      <listeners>
        <add name="xml"
             type="System.Diagnostics.XmlWriterTraceListener"
             initializeData="c:\logs\ServiceModelTrace.svclog" />
      </listeners>
    </source>
    <source name="System.ServiceModel.MessageLogging"
            switchValue="Information">
      <listeners>
        <add name="xml"
             type="System.Diagnostics.XmlWriterTraceListener"
             initializeData="c:\logs\MessageLog.svclog" />
      </listeners>
    </source>
  </sources>

  <messageLogging logEntireMessage="true"
                  logMalformedMessages="true"
                  logMessagesAtServiceLevel="true"
                  logMessagesAtTransportLevel="true"
                  maxMessagesToLog="1000" />
</system.diagnostics>

Make sure the output directory exists and the application has write permissions. If the directory does not exist, tracing silently fails.

Using SvcTraceViewer

SvcTraceViewer is the tool for reading .svclog files. It is included with the Windows SDK. Launch it from the SDK bin directory or find it at a path like C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\SvcTraceViewer.exe.

Open your trace file and look for red entries. These are exceptions. Click on any exception to see the full stack trace and message. The activity view shows you the complete flow of a single operation from start to finish.

For diagnosing EndpointNotFoundException, look for the transfer events. They show where the client hands off to the transport layer and where things break down. If the trace shows the client sending the message but no corresponding server-side receive, the problem is network-level. If the server receives the message and then throws, you are dealing with the red herring problem.

Message Logging

Message logging captures the actual SOAP messages sent and received. This is invaluable for diagnosing binding mismatches and security issues. Enable it at both the service level and transport level for complete coverage.

Look at the logged messages to verify the SOAP action header matches what the server expects. Check the message encoding and envelope version. If the client sends a SOAP 1.2 envelope and the server expects SOAP 1.1, the messages will look different and the server will fail to process them.

Using Fiddler for HTTP Inspection

For HTTP-based WCF services, Fiddler is an excellent debugging tool. It acts as a proxy and captures all HTTP traffic between client and server. This lets you see exactly what the client sends and what the server responds with.

To capture WCF traffic in Fiddler, you need to configure WCF to use Fiddler as its proxy. Add this to your client configuration:

<system.net>
  <defaultProxy>
    <proxy proxyaddress="http://127.0.0.1:8888" />
  </defaultProxy>
</system.net>

Compare the browser request with the client request. Differences in headers, URL, body, or content type can reveal the source of the problem.

When to Move Beyond WCF: Modern Alternatives

If you find yourself spending more time debugging WCF configuration than writing business logic, you are not alone. Many developers on Reddit and GitHub report that WCF is “slowly dying” in favor of simpler, more modern frameworks. Here is a brief overview of the alternatives.

CoreWCF

CoreWCF is a community-driven project that brings WCF to .NET Core and .NET 5+. It supports the most common bindings including basicHttpBinding and netHttpBinding. If you want to modernize your .NET runtime without rewriting your service contracts, CoreWCF is the path of least resistance.

Migration involves updating your project file to reference CoreWCF packages and changing the hosting model from IIS/ServiceHost to ASP.NET Core hosting. The service contracts and data contracts remain largely the same.

gRPC

gRPC is Google’s RPC framework and the recommended replacement for netTcpBinding-style WCF services. It uses Protocol Buffers for serialization and HTTP/2 for transport. It is significantly faster than WCF and has excellent cross-platform support.

However, migration to gRPC requires rewriting your service definitions in Protocol Buffer format and regenerating client code. The programming model is different from WCF, so expect a learning curve.

ASP.NET Web API

For RESTful services, ASP.NET Web API (now part of ASP.NET Core) is the natural successor to webHttpBinding-based WCF services. It is simpler to configure, has no XML configuration files, and integrates naturally with modern ASP.NET Core applications.

If your WCF service is primarily returning JSON over HTTP, the migration to Web API is straightforward. You can keep your business logic and just change the service layer.

When to Migrate

You should consider migrating away from WCF if you are building new services on .NET Core or later, if you need cross-platform compatibility, or if your team is spending excessive time on WCF configuration issues. For existing .NET Framework applications that work, there is no urgent need to migrate, but plan for the eventual end of .NET Framework support.

FAQ’s

Conclusion: Fixing EndpointNotFoundException for Good

The WCF EndpointNotFoundException is a misleading error that can stem from dozens of root causes. The key to solving it is systematic diagnosis: verify the service is running, check the endpoint address, test from a browser, verify network connectivity, compare bindings, check firewalls, enable tracing, and always check for the red herring problem where server-side exceptions mask themselves as connection failures.

My top recommendation is to always enable includeExceptionDetailInFaults during development and set up WCF tracing from day one. These two steps alone will save you hours of debugging time. And if you find yourself fighting WCF configuration on a regular basis, seriously consider migrating to a modern alternative like ASP.NET Core Web API or gRPC.

Keep the troubleshooting checklist bookmarked. The next time you see EndpointNotFoundException, work through the eight steps in order. In my experience, over 90 percent of cases are resolved within the first three steps. The remaining cases almost always require WCF tracing to diagnose, and the trace files will tell you exactly what is going wrong.