I've got a self-hosted WCF service listening on port 80. When I attempt to connect to it, I get a 503 Service Unavailable.
My WCF process is running, IIS is running. My URL ACLs are correct. Control never reaches my WCF process.
WCF tracing shows nothing more than:
Listen at 'http://localhost/Foo/Bar/'.
Nothing is shown in Failed Request Tracing, which is turned on correctly -- other tracing appears. The 503 Service Unavailable message is resolutely plain, implying that it's coming from kernel mode, rather than user mode.
I've turned on HTTP.SYS tracing, which shows that the namespace is reserved correctly:
Attempted to add URL (http://localhost:80/Foo/Bar/) to URL
group (0xFD0000014000002E). Status: 0x0.
But later, in the same trace, I see:
Request (request ID 0xF600000580000006) rejected
due to reason: UrlGroupLookupFailed.
I've tried iisreset a couple of times, but it doesn't help. I've also rebooted the PC; same problem.
What is going wrong? What else can I do to further debug this problem?
Updates
If I rename the URL (changing "Foo" to "Fizz", for example), then it works. Looks like corrupted configuration somewhere.
I have other services hosted in the same process that are bound to https://localhost/Foo/Bar/, and they appear to be working correctly.
It's not just WCF
I've had the same problem with a self-hosted Nancy service, and one of the commenters, below, reports the same thing with a self-hosted ServiceStack service.
Had the problem again. Poked around with URL ACLs. There were a couple of URL ACLs that could be considered to be ambiguous.
I had http://+:80/Foo/, http://+:80/Foo/Bar/ and http://localhost:80/Foo/Bar/. I deleted all except the 'localhost' one, and it started working.
Whether it was because of the ambiguity, or because deleting the extras caused something to be reset, I don't know...
Related
I have wcf service hosted in iis 7.0.
It was working well for the past year, but now suddenly it's crashing and restarting every few minutes.
I looked at the trace file, and I see the error but I don't know what it means. I tried googling it but no luck. I checked the settings in IIS. It looks ok.
This is how my trace looks like. If someone can help me understand this trace, it will be good.
This are pure assumptions, but as far I guess by looking at your traces and what you wrote:
You are using a net.pipe WCF host
The endpoint address of your host is net.pipe://tstwebashitv... something, so you are not using a the net.pipe://localhost/... format (assuming tstwebashitv is not a server name, and your net.pipe is not remote)
The service used to work for a long time
So I assume there is a possibility that another named pipe WCF host is running on the same machine, and might cause conflict.
That's why I suggest to check those points:
Have net.pipe endpoints adresses under this format: net.pipe://localhost/something instead of net.pipe://something.
Check HostNameComparisonMode setting in the NetNamePipeBinding section : it is better to set it to Exact to ensure running hosts receives messages addressed to them.
Basically, if the HostNameComparisonMode is not set, then the StrongWildcard default mode is used and the host name in the net.pipe address is discarded.
If you have a net pipe address set as 'net.pipe://something', then "something" is considered as a server name and is discarded. So several host running that way could conflict together.
I have a WCF service hosted in the IIS (IIS 8). The service is in a Per Call Mode and the concurrency mode is set to Multiple. I have around 600 clients connecting to it. It has a HTTPS end point. It also has a net.tcp endpoint but that is not used. Not all but some of my clients face a very weird problem. The client stops working after using for a while. I have error logging and at the client side I see the error which says
There was no end point listening at ...
There are no errors on the server, or the service. The service seems to be working fine. I can browse to the service page from a browser and other clients are still able to use the service. Running a trace is also not helping. I have spent enough time trying to figure it out but with no luck. Further more, on the same computer just restarting the client seems to work and connect to the same service. The client is a WinForms Application.
I performed a DNS flush on my machine and even that does not help.
What could be the possible issue? The things that hit my mind are that maybe the client is unable to resolve the name, but that is contradictory to it connecting in the first place.
The service maybe down, but my other clients are still using the same and they do not face problems.
It might be a problem with the client machine as it Uses Win XP but I am not sure if that would cause a problem.
Or it might be a problem because of intermittent internet connection.
Has anyone ever faced such a problem before? Some insight would be really helpful
IIS can only serve a limited number of clients at a time. It will then place additional requests onto a queue. That queue is also limited. When that queue fills up then IIS returns a 500 error, which is interpreted as "There was no end point listening at ..."
You should try this piece of code.
public void Main()
{
while(thereIsStillThisProblem)
{
var pc = new Pc();
pc.OS = new Windows2012();
pc.Start();
pc.Software.Add(new ServiceHost());
}
}
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/iis/64e30660-d2f0-4e90-98cc-1652214a2b93.mspx
Edit: Just remembered that there is one more thing you can do, if you are using .net 4.5. I will let Jon Skeet explain.
I just implemented a simple WCF server using net.tcp.
First, I use 127.0.0.1 as server address and client able to connect the WCF service.
Everything is Ok. But when I try to use the internal IP 192.x.x.x I get an error:
No connection could be made because the target machine actively refused it
Any idea what may cause this?
Best Wishes
PS: I disabled auth on WCF. Even turn off firewall all...Not worked...
Well, I got this error message when I forgot to install necessary components. see link Configuring WCF Service with netTcpBinding
(summary of steps)...
Go to "Programs and Features" (usually in control panel)
Go to "Turn Windows features on or off"
(assuming VS2012) Go to ".NET Framework 4.5 Advanced Services"->"WCF Services"
Enable "TCP Activation"
Do you use 192.x.x.x on both client and server? I remember seeing an issue a while back in which for TCP the client and server names needed to match (something related to one of the message properties), so if you define the service with "localhost" and the client with <machine name> there would be a problem.
The physical client and service addresses can differ if the logical address is the same and the server endpoint has been configured with a "listenUri" and the client behaviour is configured to use a <clientVia> address. In our case, this is required in for our proxy/firewall configuration. In effect, the client calls the firewall and the server listens locally for a forwarded request.
For an IIS-hosted service, check the following:
The Application pool is started and looks correct (.NET 4 etc/security)
For NET.TCP, ensure the "Allowed Protocols" in the Web Site/Application (via advanced settings) are configured correctly: e.g. http,net.tcp
For a non-IIS hosted service, you may need to configure a Namespace Reservation (URLACL). http://msdn.microsoft.com/en-us/library/ms733768.aspx
Also ensure the appropriate Windows Services are running, e.g. Net.Tcp listener.
If you're running from within visual studio in debug mode, ensure your solution port numbers match. I have seen several instances where I had Properties>Web>Auto-Assign Port - selected and the endpoint from, in this case my silverlight app, didn't match the port auto generated. I usually change the port to 1318 in my .web.
Today I found out that this error will also show up if you have a circular reference in your WCF Service Class. I had a method that was calling itself infinitely and causing this error message, which led me here.
So if none of the other suggestions work, check your code to see if you're doing any recursive functionality and make sure you're not caught in an infinite loop.
I resolved this issue by either commenting this setting in the application configuration:
<defaultProxy>
<proxy bypassonlocal="False" usesystemdefault="True" proxyaddress="http://127.0.0.1:8888" />
</defaultProxy>
or, running Fiddler which would take the WCF call at 127.0.0.1 and then forward it.
The complete scenario is, I encountered the same issue with WCF calls made to one of the service. The calls would fail with top level error message "There was no endpoint listening at http://LinuxIP:Port/...", and service trace viewer log showing inner exception to be "No connection could be made because the target machine actively refused it 127.0.0.1:8888
".
The reason was that I had put this configuration in my application to capture the outgoing traffic in Fiddler. If this configuration is in place then the Fiddler needs to be running for the WCF calls to make it to the intended destination. If Fiddler is not running this error will be there. Comment this setting in such scenarios, and the WCF call will go to the destination.
I am getting the below errror when calliong WCF method from windows mobile.
There was no endpoint listening at
http://169.254.2.2:8000/calculator/Calculator that could accept the message. This is
often caused by an incorrect address
or SOAP action. See InnerException, if
present, for more details.
I am able to ping to mobile
Port # 8000 is enabled in my PC Firewall.
I used the basichttpbinding both PC and Mobile side.
Still i am not able to call method from WCF service.
I also got the error "There was no endpoint listening at 'x'" after working on with my client/server setup all morning. My firewall was off, so I tried a few things but nothing seemed to eliminate this problem. Finally I decided to restart my PC and that must have liberated the port. I believe that the port got hung up by me not closing the service connection properly before exiting the application. Anyway, restarting allowed me to connect to the same endpoint again with no further problems.
I am consuming a web service in .NET application with WCF client.
The Endpoint's address of the service is over port 4338, and it is over HTTPS, secured with WS-Security standard.
So the address is something like :
https://[servername]:4338/[servicename]/
I was not able to communicate to the service with just running the application.
it gave me the following error :
Could not connect to [servername]:4338
TCP error code 10060: A connection
attempt failed because the connected
party did not properly respond after a
period of time, or established
connection failed because connected
host has failed to respond
[servername]:4338
But when I run Fiddler to investigate the http communication, the application start to work, and I will be able to communicate to the service.
As well, I want to add that I have a different service on the same web server that hosts the first service, and that second service's address is hosted on port 8080, and I am able to communicate with it with WCF client (without running Fiddler).
So, I googled and I found that it might be related to the proxy settings. Do you know what the problem is, and how can I solve it?
Thanks
Fiddler acts as an Internet proxy server. In general, any symptom of the form: "it works when I use Fiddler" means "it works when there's a (different) proxy server".
Check your proxy server settings. In particular, as empi suggested, try it in a browser. If it works there, it could be due to the fact that the browser has the proxy settings configured, and that you do not have them configured for WCF.
If you have proxy set in Internet Explorer, it may cause the problem. What happens when you open https://[servername]:4338/[servicename]/ in Internet Explorer?
Thanks empi for the reply.
I found the answer.
Actually in our company we have a proxy settings through "Automatic configuration script"
and depends on the web sites we are targeting internally, the script will point us to the proper proxy.
So, from the script I got the proper proxy address.
and in my .NET application I added this code
WebRequest.DefaultWebProxy = new WebProxy("http://xx.xx.xx.xx:8080");
and that fixed the problem
So WCF client was not detecting the setting of the automatic script.
and this is the reason it worked when I run Fiddler, because Fiddler listen to the http communication, and send it again through the settings.