An existing connection was forcibly closed by the remote host - WCF_问答_开发者

I have a WCF web service that is working fine. However there is one particular call that is failing - but only failing for certain users. The call is pretty simple - it is a call to get a lis开发者_运维问答t of Person objects.

For User A it works fine. The service queries the database, creates the list of Person objects and returns it back to the calling application.

For User B it fails. The weird thing is that when I do debugging the service seems to work fine. It is able to query the database and it creates the List object and returns it. The service itself never fails. But the client application receives the "An existing connection was forcibly closed by the remote host" error.

To me it seems like something is happening when the service layer is trying to package up the data in XML format to send back to the calling application. I am thinking that it has to be a data related problem because the call works fine for other users. I have visually looked at the data and I don't really see anything odd. One guess is that the data for User B has some funky hidden characters or something and therefore is causing the service to close unexpectedly. Something like that.

Any ideas?

The best thing I've found for diagnosing things like this is the service trace viewer. It's pretty simple to set up (assuming you can edit the configs):

http://msdn.microsoft.com/en-us/library/ms732023.aspx

Hope this helps.

I had this issue because my website did not have a certificate bound to the SSL port. I thought I'd mention it because I didn't find this answer anywhere in the googleweb and it took me hours to figure it out. Nothing showed up in the event viewer, which was totally awesome for diagnosing it. Hope this saves someone else the pain.

I have seen this once. Are the users requesting different amounts of data? I found that even if you can configure a binding for data payloads (i.e. maxReceivedMessageSize), the httpRuntime maxRequestLength trumps the WCF setting, so if IIS is trying to serve a request that exceeds that, it exhibits this behavior.

Think of it like this:

If maxReceivedMessageSize is 12MB in your WCF behavior, and maxRequestLength is 4MB (default), IIS wins.

I found that you can get this error if the returned object has getter only auto properties that are initialized in the constructor (with C# 6.0 syntax).

I believe this is due to WCF deserializing objects on the client side using a parameter-less constructor then setting the properties on the object. It needs to have a set available (it can be private) to fill the object, otherwise it'll fail.

I just had this error now in server only and the solution was to set a maxItemsInObjectGraph attribute in wcf web.config under <behavior> tag:

<dataContractSerializer maxItemsInObjectGraph="2147483646"/>

I' ve got the same problem. My solution is this :

If you using LinQ2SQL in your project, Open your dbml file in Visual Studio and change Serialization Mode to "Unidirectional" on

I have catched the same exception and found a InnerException: SocketException. in the svclog trace.

After looking in the windows event log I saw an error coming from the System.ServiceModel.Activation.TcpWorkerProcess class.

Are you hosting your wcf service in IIS with netTcpBinding and port sharing?

It seems there is a bug in IIS port sharing feature, check the fix:

My solution is to host your WCF service in a Windows Service.

After pulling my hair out for like 6 hours of this completely useless error, my problem ended up being that my data transfer objects were too complex. Start with uber simple properties like public long Id { get; set;} that's it... nothing fancy.

In my case it was also with serialization. I need to add [KnownType(typeof(...)] for all the classes that could appear in the serialization.

The issue I had was also with serialization. The cause was some of my DTO/business classes and properties were renamed or deleted without updating the service reference. I'm surprised I didn't get a contract filter mismatch error instead. But updating the service ref fixed the error for me (same error as OP).

I had this issue start happening when debugging from one web project to a web service in the same solution. The web service was returning responses that the web project couldnt understand. It would kind of work again at some points, then stop again.

It was because there was not an explicit reference between these projects, so the web service was not getting built when hitting F5 to start debugging. Once I added that, the errors went away.