27
votes

Ok, can I vent?? I am so sick and tired of this. I'm working away most of the day and the WCF services are working great. Next time I run my app and make a WCF call, bam! the tcp socket is no longer available. I have searched high and low to solve this and there is no real solution. The only solution I can find is to reboot the machine which is a huge time-waste and burden. Restarting WPA service, net.tcp service, IIS, etc. does not do a thing. Logging off and back on does not fix it. Only a reboot fixes this issue. I do nothing except run my app again making a WCF call, and this crap happens. There are no configuration issues with anything. I have been dealing with this for months and cannot find any specific reason or solution as to why this happens. It happens with my firewall on or off, does not matter.

Any insight from anyone? I think there is truly a bug in the WCF / net.tcp layer that is causing this. I even get it on a production 2008 R2 server when sometimes making a Web.config change, so I have learned to stop the IIS, WPA, net.tcp, etc. services prior to the change then restart them. What a pain.

I'm using .NET4 all around, VS2010, all service packs, etc. applied. Everything is the most current.

Excuse me while I reboot.....

Can anyone help with this?

6
Are you hosting in IIS, or running it as a Service or self-hosted app? Have you tried doing a netstat or a tool like TCP View: technet.microsoft.com/en-us/sysinternals/bb897437 to see if the port is being closed, or if something else is taking over the port?CodingWithSpike
I have had the same experience with WCF services while debugging such a service. It can happen, at random, that you stop your debugging session at a point in time that your system is not able to cope with it. The port sort of hangs in limbo, and a system reboot is required to solve the issue. Voted up this one, because I am curious what the origin and possible solution for this one is ...kroonwijk
Is it a question? It looks more like sad story about some unknown problem = in such case it is better to contact MS support either through ticket (MS Partner) or through MS Connect.Ladislav Mrnka
@Ladislav yeah you are right. it is sad. and many people seem to experience it. maybe i will open an MS ticket and report a bug.user514005
A quick question: if you're using Net.TCP are you closing/disposing your service client object after using it? TCP.Net is connection-oriented, unlike HTTP, so you need to shut down your connection manually.Faster Solutions

6 Answers

24
votes
  1. Open a command prompt
  2. Navigate to c:\windows\microsoft.net\framework64\v4.0.30319
  3. Register the service model using the command "ServiceModelReg.exe -r"

Credits go there http://kumaranbose.blogspot.be/2010/08/cryptic-wcf-nettcp-errors.html

6
votes

This issue hunts me for almost 3 years now but only happens sporadically. TCPView helped. I have killed SMSSvcHost.exe process and then restarted Net.Tcp Listener Adapter service. That cleared the issue. Not really a solution but at least, I don't have to resort to rebooting the server anymore.

3
votes

I had this issue. It would happen after each IIS reset (which happens as part of our deployment). The issue was resolved after restarting NetTcpPortSharing service (which also restarts Net.Tcp Listener Adapter service)

1
votes

I am not sure I have an answer but, you could identify the process that has the port open and that can help narrow the scope of the problem. I have used Sysinternals suite which has a TCPView. This proggy was helpful to me.

TCPView - http://technet.microsoft.com/en-us/sysinternals/bb897437

0
votes

Sounds Net.Tcp Listener Adapter service is being killed by some process or exception being throw by the web service putting the channel in a faulted state.

Have you tried setting the startup type of the service to automatic and recovery to restart service on first and second failure?

I doubt it very much that there is a bug in wcf net.tcp channel layer. If the listener is running and tcp socket no longer available i would suggest you look into the code especially around the exception handling strategy and have a peek into the iis request logs.

-1
votes

Check in the AD the account used for running the Application Pool in IIS.

The Appplication pool may be running but will stop on 1st connection attempt if the account is disabled/locked/in need for a password change.