After upgrading from windows 8.1 to windows 10,
None of the projects that have a WCF service available through net.tcp connections are able to connect.
The exception i get is:
The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '19:59:59.9769910'
the inner exception code is: 10054
But the exception happens right away. So it's not a time-out.
I checked IIS and everything is still configured right. (still have the right binding on the site, enabled protocols http,net.tcp)
I checked my services if net.tcp listener adapter was running and it was.
I checked windows features and saw that windows communication foundation non-http activation was turned off. so i turned it on and restarted my PC and still get that same exception.
I've waisted a total of 4 hours so far trying to get the net.tcp connection to work but i'm kind of losing hope here.
here are the windows features i've turned on:
and here are the windows services i have running:
Did anyone else run into this issue when upgrading to windows 10?
I finally got it working after hours of trial and error. I am not 100% sure if this is what actually solved my problem in the end, but give it a try:
Open "Turn Windows features on or off"
Uncheck "WCF Services" and all underlying boxes
Reboot computer
Recheck "TCP Activation", "TCP Port Sharing" under "WCF Services" (and any other activation methods you need)
Reboot computer
We've managed to resolve this issue.
We were using a certificate in IIS with an old encryption method that was no longer being supported. (it was using MD5-RSA)
Now this was stil working in windows 8/8.1 but the certificate was no longer valid in windows 10, causing this behavior.
The solution was to get new certificates with better and supported encryption algorithms and set them up in IIS on my machine.
I'd also like to apologize for answering so late!
Our services don't use IIS . We have self hosted WCF services. After checking
Named Pipe
Tcp Activation
they finally worked.
Related
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 can only get this SDK sample of PeerChannel SecureChat to work in the following scenarios in a basic home network:
Locally among instances running on the same machine, or
Among Windows 7 machines
I cannot get this to work between my Windows Server 2008 R2 and any other machine (no exceptions are thrown, but the nodes never find each other and thus don't go "online"). I CAN ping the IPv6 addresses among all machines. The executable has a firewall exception rule, but I have also tried disabling the Windows 2008 firewall completely. The PRNP Service is running.
Is it possible to get it working? How?
Does it work on YOUR 2008 machine?
My best guess: I notice that in the Windows 7 machines, the "Peer Networking Grouping" and "Peer Networking Identity Manager" services are present. The "Peer Networking Grouping" service's description there and online talks specifically about enabling multi-party conversations, but related to Home Groups. This service is missing in the Windows Server machine.
So, I suspect the missing service as the reason that the SecureChat sample won't work on the Windows Server machine, but I don't understand why Microsoft would lock out Peer Channel from working on the Server product. Could this be the reason?
Thanks!
Try enabling these services on the server:
Peer Name Resolution Server (Install through Server Management)
Peer Discovery Server (Install through Server Management)
Simple Service Discovery Protocol Service (SSDP Service)
Then simply ensure that the Firewall Rules are modified; by default they block IPv4 / IPv6 Teredo Tunneling driver. IPv6 needs to be supported as it is required by PNRP.
Also you should be able to configure your service in two ways; through Internet Information Systems (IIS) or as a Windows Service. Your best bet will be to use IIS, you can find an article here on how to configure it: Hosting and Consuming WCF Service
Those are the few tips I can think of to get it running. Hope that helps.
This MSDN page mentions this subtle detail of Windows implementation of PNRP:
Any two clients running the same version of PNRP can locate each other
using this protocol...
I am new to wcf programming and I have been working on a small project and am having problems with net.tcp port sharing. I am using .net framework 4 and iis 7.
I have two wcf services (serviceA and serviceB) being hosted on our server in separate websites on IIS. Each website has its own .svc file, web.config and bin. If I have each of these services on different net.tcp ports then there is no problem and I can add the service reference to each of them from visual studio on my pc. The services run fine.
However we will soon be starting a project with many more services and we wish to avoid having to open a tcp port for each one so I have been trying to get serviceA and serviceB to port share. If I set them up on the same port then I can access the first service I add but when when I try to access the second service added to the same port i get the following error:
Metadata contains a reference that cannot be resolved:
'net.tcp://myserver/serviceB.svc'. The socket connection was aborted. This
could be caused by an error processing your message or a receive
timeout being exceeded by the remote host, or an underlying network
resource issue. Local socket timeout was **. An
existing connection was forcibly closed by the remote host If the
service is defined in the current solution, try building the solution
and adding the service reference again.
I can not work out what is going wrong. I have done a lot of searching on the subject and I have made sure that the following services are running:
Windows Process Activation Service
Net.Tcp Port Sharing Service
Net.Tcp Listener Adaptor
In addition net.tcp is an enabled protocol in the website's advanced settings. My current best guess is that it might have something to do with how I have defined the net.tcp bindings in IIS manager. Both of my websites running their independant services have the following: 808:*(net.tcp) is this correct?
As i said earlier the tcp services run fine if set up on two separate ports so the issue must be related to the port sharing. Very grateful for any advice
OK I found the problem I was having. In IIS I had set up each service as its own website and was trying to get those different websites to port share. This would not work.
However I found that if I set up just one website and then added my services as seaprate applications under the website then the port sharing will work. This approach lets me have multiple services as applications under one website.
Check this.
This can be helpful to you.
http://himanshudesai.wordpress.com/2011/06/03/multiple-wcf-services-on-a-single-port/
Hope this helps.
I've got a working WCF service and a working Delphi client. On a normal PC, they work nicely. On a VM that's "Bridged" they work nicely if I log onto the domain (but not if I logon locally to the VM as administrator). If the VM is NATed, the connection attempt times out.
I would love to hear people's thoughts on what could be making such a difference to whether the client can successfully connect to the WCF service. Bear in mind I'm connecting with basicHttpBinding with no security.
The service is setup to use System Account (interact with desktop is NOT checked), and it starts automatically. The service URI doesn't change, the port is open, and can be telnet'd to in all scenarios.
Any ideas or pointers?
Within the VM, open Internet Explorer and verify that you can view the WSDL of the WCF service. If you can't, then your issue is connectivity and has nothing to do with your Delphi code.
Group Policies and Enterprise Security solutions that swap certificates or require certificates to be registered (we're using a UTM called CyberRoam) make a difference.
Also when Virtual Machines join a domain, their ComputerNames are added to a list maintained by the Domain Controller. When the same Virtual Machine is "moved" or "copied", its ComputerName should be changed to avoid DNS resolution issues.
I'm not claiming this as the definitive answer, however it does explain the issues I noticed in this instance.
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.