The Web Services stack refuses to work until the system is rebooted.

Question

I have the following scenario. My client application connects to a server side software via web services. I have no control over the server side software.

Every time the server side folks deploy a new version, my client app can't connect to it (via the web services... ping works fine) until the client system is rebooted (just restarting the app does not do the trick). Then everything works great like nothing happened.

I should mention that the server-side code is based on WCF, while the client app connects to it via the ASMX endpoint (as expressed by the Wsdl http://mycompany/services/v1%5F0/Default.svc?wsdl). The authentication from client to server is via Windows Authentication (NTLM).

What could be going on? Why do I have to reboot the system?

---

Response to @EugeneOs

Basically there are 3 communication sets in Fiddler:

IE:  Get /Default.svc HTTP 1.1
Response: 401.  Negotiate with NTLM

IE:  Get /Default.svc HTTP 1.1 - with NTLM token 
Response: 401.  Negotiate with NTLM specific token (token provided in the response)

IE:  Get /Default.svc HTTP 1.1 - with the token provided above 
Response: No Response whatsoever.

My next step is to hit it with the Microsoft Network Monitor just to make sure that the last packet got through (though I suspect, it'll be a waste of time).

Answer 1

What happens if you just browse to http://mycompany/services/v1%5F0/Default.svc or http://mycompany/services/v1%5F0/Default.svc?wsdl before the system is rebooted?

Is there anything added to the event log when you try to access the above URLs from the browser?

What errors do you get when you say it "can't connect"? Can you look at the response using Fiddler?

Answer 2

The web services stack is not doing this. Sorry. There's hardly any stack at all in an ASMX client. It's not doing anything fancier than HttpWebRequest! This has nothing to do with the server being WCF, since ASMX doesn't know anything about WCF. It's just a plain SOAP web service as far as your ASMX client is concerned.

I'd check into proxy server issues, and I'd look at the network traffic both during the failure and during a success, to see what the difference is.

I might also try to create a dead-simple test client with nothing fancy in it in order to reproduce the problem in a simpler environment. That will rule out anything special that the real client program might be doing in terms of customizing the client proxy.