Sql-server – Strange 400 error with IIS 7.5 and a webservice

400iissql serverweb services

Ok, this is a longshot. I have been pondering this for hours. I have no clue how to solve this. But maybe someone here can recognize the problem and point me to right direction.

I have an IIS 7.5 server and a MSSQL database on a different server. On the IIS server there is a webservice that communicates with the MSSQL server.

The problem is that when there is data that the MSSQL server needs to send back to the webservice and the webservice delivers that back to the webbrowser (JSON) i get a 400 error. Looking through the logs for the IIS there is just a 400….nothing more. When i put in a call to the service in my browsers URL field i get this:
"The server encountered an error processing the request. Please see the service help page for constructing valid requests to the service."

There is NOTHING wrong with how i call the webservice. It has worked before on a different server (a dev server).

Do someone have a clue on what this can be about? 400 means malformed URL…it isnĀ“t. And why is that when there are no data to return to the user…everything works. But when there is data fetched from the MSSQL DB…the 400 error shows up.

Hope someone have some tips how to solve it. Thanx in advance.

Best Answer

Try making captures at every step of the puzzle:

Start off in wireshark at your client, and verify that the request you are making is not malformed. Perhaps the server name is longer, or there is an invalid character that causes it to crash with the production server.

Then hit IIS and make sure request logging is enabled. Make a request, and look at the IIS log. If there is an error being generated by the IIS stack, you may get a more descriptive error code.

From there, check your application event log to make sure you don't have any application level exceptions being logged. Check that your application pool is running correctly. Check that you don't have any URL Rewrites enabled. Check that the proper application handlers are configured - or at least not overwritten.

At that point, if the request is making it to your application, you should probably talk to the developer. However, you could run a SQL Server Profiler trace to make sure that it is hitting the database successfully.

I am sure I missed some fault case, but I hope this at least points you in the right direction.