Geek Answers Handbook

Capturing data from .Net web service that is not executing with HTTP Error Code 500

I have a .net web service hosted in IIS 6.0 which periodically fails with http 500 because the client connects to it with data that does not match wsdl.

Things like the presence of an element specified in the method as an int type and an incoming xml element contain a decimal number.

WSDL element definition:

<s: element minOccurs = "1" maxOccurs = "1" form = "unqualified" name = "ItemCount" type = "s: int" />

provided item:

<ItemCount> 1.0 </ItemCount>

This leaves a 500 error in iis logs, but soap return information is not returned or the input that caused the error.

I have currently diagnosed several problems with data obtained by capturing everything using wirehark, but I would like to know about other options that are perhaps less intrusive.

Is there a way to capture sent data that cause 500 errors (hopefully ONLY data capture when 500 happens)? Maybe:

  • IIS setup
  • Web service setup
  • Web service code change

EDIT after testing the response provided by tbreffni

The answer that best corresponded to what I was after tbreffni - there were a few other good answers, but the answer allows you to capture the payload by causing deserialization errors without launching something like a violinist or wirehark.

The information on actually getting the SOAP extension to run is a little light, so I included the steps below that I found necessary:

  • Create SOAP extension as .dll according to MSDN article
  • Add .dll to bin directory for trace service
  • In the tracking service web.config, add the following to the webServices section, replacing SOAPTraceExtension.TraceExtension and SOAPTraceExtension according to your extension.

<WebServices>
<soapExtensionTypes>
<add type = "SOAPTraceExtension.TraceExtension, SOAPTraceExtension" priority = "1" group = "0" />

</soapExtensionTypes>
</WebServices>

+4
source share
6 answers

You can implement a global exception handler in your web service, which logs the details of any exceptions that occur. This is useful for your current problem, plus it is very useful in a production environment, as it gives you an idea of ​​how many exceptions are thrown and what code.

To implement an exception handler for the .Net web service, you need to create a SOAP extension. The following is an example MSDN article . I used this approach in several production web services, and it was invaluable in determining what problems arise and where.

+2
source

I would try fiddler or here , Not specifically for web services and, as a rule, for the client side, it can be used as a reverse proxy .

This is very script -able and request / response, so I think you can probably make it capture only 500 errors.

+3
source

I never used this myself, but I just found it on MSDN: Enabling tracing in ASP.NET Web Services

+1
source

Have you looked at IIS request tracking ?: http://technet.microsoft.com/en-us/library/cc786920.aspx

+1
source

After I thought about my own, the current best solution I see is to roll up a lightweight phase facade web service that accepts xml blob as input.

Then I can make my facade service call the real service with the input provided by the client, and then:

  • handle any errors, register the original data and the returned soap error.
  • Give the customer answers from good data

This will only be a temporary measure (I am categorically against web services that are clearly not related to the XML that they accept), but it will probably give me more leverage to overcome the hump of diagnosing errors like this in production where a client connecting to the web -service, does not perform wsdl check or is able to read returned soap errors.

Fortunately, in this case there is only one party publication for the web service - batch sniffer methods (script or wires) are possible, but the lack of registration for 500 errors made me think: "What are more pleasant options?"

0
source

If you want to use the tool, use WireShark.

Otherwise, the easiest way is to capture "everything" (provided that you use ASMX) - enable tracing on system.net

http://blogs.msdn.com/dgorti/archive/2005/09/18/471003.aspx

If you use WCF, it has excellent trace support, and you can use svctraceviewer to view trace logs. It doesn't look like you are using WCF.

0
source

More articles:


All Articles