Troubleshooting SOAP exceptions from ASP.NET service


I’ll provide some details about an integration issue I had to resolve, to allow a separate team consuming one of the web services my team created, and be able to consistently handle known custom exceptions.


Here is a brief description of the scenario:

  • Team A created an ASP.NET web service to enable interaction with the corporate Yammer network.
  • Team B leverages the service to provide social capabilities to some LOB applications
  • In several scenarios, the service raises custom exceptions. ie: user not found, user is inactive, user cannot be null, etc.
  • Team B handles those scenarios by catching the custom exceptions raised by the service and implementing fallback logic.

  • Team B reported that under the same conditions (same code base and same arguments) they were able to successfully capture the custom exceptions in the Integration Environment, but they were unable to do so in Test and Staging environments.
  • The service logic implements something like this:
public string SomeMethod(string arg1)

   Throw New Exception("Something bad happened");
  • If the service is consumed from the Integration Environment the result look like this:
   <faultstring>System.Web.Services.Protocols.SoapException: Server was 
unable to process request. ---&gt; System.Exception: Something bad 
happened at AYS17Sept2002.Service1.CallFault() in 
c:\inetpub\wwwroot\AYS17Sept2002\Service1.asmx.vb:line 49
   --- End of inner exception stack trace ---</faultstring>
   <detail />
  • If the service is consumed from the TST or STG environments, the result look like this:
    <faultstring>Server was unable to process request. --&gt; Something 
bad happened</faultstring>
    <detail />
  • Team B was unable to catch the expected custom exception in TST and STG environments, hence the code failed to implement the fallback logic.


By looking at the results, and more specifically at the error message, it is clear that the same custom exception is being raised from the service, but it is not being delivered consistently to the client. After some research I found the MSDN article that explains this behavior, and it has to do with the way ASP.NET framework handles the SOAP exceptions.

Whenever the code within a web service raises an exception, ASP.NET catches that exception and transforms it into a SOAP Fault. Depending on the /configuration/system.web/customErrors/@mode setting in the web.config, the SOAP exception will contain more or less information:

  • On setting tells ASP.NET not to add the stack trace information to any Faults.
  • RemoteOnly causes the extra information to show up for clients on the same server and hides the information for remote users.
  • Off setting tells ASP.NET to add extra information for all calls to the Web service.

This is the same behavior for ASP.NET web pages.


So after verifying this setting in all environments, I confirmed that <CustomErrors> was set to “Off” in Integration Environment, and “On” in all other environments, which makes sense from the deployment perspective.

With this in mind, the next step was to coordinate between the two teams on how to handle the custom exceptions consistently.

We assessed several options, each one with pros and cons:

  1. Modify the web service logic, adding additional details to the SOAP exception
  2. Instead of raising a custom exception from the web service, return a response code that could be interpreted and handled appropriately by the other application
  3. Create a separate web.config file only for the service, and set the <customErrors> mode to “Off”, and deploy to all environments


Using SOAP Faults

How to get the bytes from a file and convert them to Base64String in PowerShell


In this post I’ll share a PowerShell script, that simply reads the bytes from a given file, converts those bytes to a Base64String, and then saves it to a text file.

A little background about why I needed this

I needed to troubleshoot a web service method and I wanted to use SOAP UI as the testing framework. The service method took a byte[] as a parameter and uploaded the corresponding file to a Yammer network.

I’ve been using SOAP UI for testing web services, but most of the times the requests were taking simple types, such as integers and strings. I learned that the way to pass a byte[] to an ASP.NET web service method is to use the Base64String representation, so my next task was to get the Base64String representation of any given file, so I could grab it as simple text and pass it to the XML test request. Rather than creating a console application, I thought that a PowerShell script would get it done faster.

Here is the script

#Get the bytes of a given file
$fileBytes = Get-Content <fileNameAndPath> -Encoding byte

#Convert byte array to base64 string
$fileBytesBase64 = [Convert]::ToBase64String($filebytes)

#Save Base64String to a text file
Add-Content outputFileBytesBase64.txt $fileBytesBase64


I was able to gather useful tips from these posts:

PowerShell Encoding and Decoding (Base64) – by Sean Metcalf

Efficient Base64 conversion in PowerShell – by mnaoumov

ASPX file opens as empty NotePad from Visual Studio

Visual Studio opens an empty NotePad when accessing a file within the solution. Hopefully you have a backup at hand.


I recently came across an issue in Visual Studio that had my brain spinning for a couple a days:

  • I was accessing a custom page through the browser and the result was a blank.
  • I imagined it was some kind of authentication issue or missing resources, and I used Fiddler to check the traffic, but nothing was found there that could give me a clue.
  • Things got a little weird when I tried to open the custom page in Visual Studio, and a blank NOTEPAD popped up. I went outside of Visual Studio and tried to open the ASPX file directly in NOTEPAD, but I got an empty file.


So after doing some online research, I found out that this issue was related to a missing file pointer at the OS level. This could’ve been caused by a sudden shut-down, which makes sense because I usually close the VM immediately rather than properly shutting down the system (lesson learned).


Seems like there is no resolution for this issue, and the only alternative is to recreate the file.

Luckily I was using source control, so I just deleted the file locally and got latest version.