Search code examples
.netweb-servicesiismonitoringtrace

Capturing data from a .Net web-service that fails with an HTTP 500 error code

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

Things like having an element specified in a method as being of type int and the inbound xml element contains a decimal number.

WSDL element definition:

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

provided element:

<ItemCount>1.0</ItemCount>

This leaves a 500 error in the iis logs but no information of the soap fault returned or the input data that caused the error.

Currently I have diagnosed several problems with data provided by capturing everything using wireshark but I'd like to know of other options that a perhaps less intrusive.

Is there any way of capturing the data being sent that is causing the 500 errors (hopefully ONLY capturing the data when the 500 occurs)? Possibly by:

  • Configuring IIS
  • Configuring the web-service
  • Changing the code of the web-service

EDIT after testing answer provided by tbreffni

The answer that best fitted what I was after tbreffni's - there were several other good responses but the answer allows capture of the payload causing deserialization errors without running something like fiddler or wireshark.

Info on actually getting a SOAP extension to run is a little light so I've included below the steps I found necessary:

  • Build the SOAP extension as a .dll as per the MSDN article
  • Add the .dll to the bin directory for the service to trace

  • In the web.config of the service to trace add the following to the webServices section, replacing the SOAPTraceExtension.TraceExtension and SOAPTraceExtension to match your extension.

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

Solution

  • You could implement a global exception handler in your web service that logs the details of any exceptions that occur. This is useful for your current problem, plus it's very useful in a production environment as it gives you an insight into how many exceptions are being thrown and by what code.

    To implement an exception handler for a .Net web service, you need to create a SOAP extension. See the following MSDN Article for an example. I've used this approach in several production web services, and it's been invaluable in determining what issues are occurring and where.