views:

579

answers:

5

Hello,

I'm having a problem using a WCF call from a Windows service to my WCF service running on my web server. This call has been working for a number of weeks, but then stopped working all of a sudden, and has not worked since.

The exception I'm getting is:

"General Error Occurred System.ServiceModel.CommunicationException: An error occurred while making the HTTP request"

and then it says "This could be due to the fact that the server certificate is not configured properly with HTTP.SYS in the HTTPS case. This could also be caused by a mismatch of the security binding between the client and the server."

The security I'm using on both ends is wsHttpBinding, without any kind of encryption. It also is just using HTTP - not HTTPS, so I'm not sure why it's complaining about HTTPS.

The rest of the inner exception stack is:

"SystemNet.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Unable to write data to the transport connection: An invalid argument was supplied. ---> System.Net.Sockets.SocketException: An invalid argument was supplied at System.Net.Sockets.Socket.MultipleSend(BufferOffsetSize[] buffers, SocketFlags socketFlags) at System.Net.Sockets.NetworkStream.MultipleWrite(BufferOffsetSize[] buffers)"

I should also note that the point in my program where this occurs is on the "Execute" line of the call to the web service - that is, right as soon as I call the web service and pass it the wrapped up DataContract object, it blows up.

All this service is doing is getting passed a large amount of XML (passed as a .NET object to the call on the client side), which it then does some work with. Probably about 100-200k of XML is being transmitted. I've raised the limits for the data sizes on both ends to over 6 megs, but that didn't seem to help.

Any ideas?


Some more information on this issue:

When we duplicate the client environment locally, we find that we cannot upload large amounts of XML unless we make the following changes: 1. On the server, set the "maxRequestLength" to 100 MB (way higher than we are sending) 2. On the client, we set the value of maxItemsInObjectGraph under the dataContractSerializer tag to "2147483646".

With these changes, our local installation uploads successfully. However, the client's install on their server still fails. What interesting to note is that once we made the maxRequestLength value change on the server, our test installation started throwing an error specifically relating to the maxItemsInObjectGraph setting. Whereas on our client's server, still the original "HTTP.sys" error is happening.

As I noted before, we are not using SSL at all, and there are 2 other web services calls that execute and upload XML in the same way. However, since the non-working service call transmits more data, this appears to be a size issue.

However, if the issue the client is having were the same one our test install had, I don't get why the client error message wouldn't be related to the ObjectGraph error.

Is it possible that we're just getting the generic "invalid parameter" "HTTP.sys" error for every possible error on the client (ie. it's really getting the objectGraph error too, but just isn't showing it?)

Thanks!

+1  A: 

I've seen these particular exceptions related to Complex DataType issues, see the following post if you're passing around collections or enums:

Complex Data Types

Tanner
We looked into the data type issue - we're just sending plain old .NET objects that are defined in our dataContract - no enumerables or stuff like that. We installed some of the debug tracing tools mentioned in this article though, and could see our 2 working calls coming through, but nothing appeared at all for the 3rd "non-working" call. This indicates to me that it's not even getting off the client machine at all.
Sam Schutte
+1  A: 

If you are using transfer mode = streamed, try changing it to buffered.

If this is not the problem could you post your configuration.

Shiraz Bhaiji
+2  A: 

Hi there, Had this issue with a true HTTPS binding and the same exception with "This could be due to the fact that the server certificate is not configured properly with HTTP.SYS in the HTTPS case...". After double checking everything in code and config, it seems like the error message is not so misleading as the inner exceptions, so after a quick check we've found out that the port 443 was hooked by skype (on the dev server). I recommend you take a look at what holding up the request (Fiddler could help here) and make sure you can reach the service front (view the .svc in your browser) and its metadata.

Good luck.

nsides
+1  A: 

Have you enabled tracing and then used the ServiceTraceViewer to analyze the logs? You get much, much better information about these horrible general errors that way.

Dave Markle
+1  A: 

Since everything was working fine for weeks then stopped, I doubt this has anything to do with your code. Perhaps the error is occurring when the service is activated within IIS/ASP.NET, not when your code is called. The runtime could just be checking the configuration of the web site and throwing a generic error message which has nothing to do with the service.

My suspicion is that a certificate has expired or that the bindings are set up incorrectly. If the web site is mis-configured for HTTPS, whether your code uses them or not, you may be getting this error.

Jacob