12

I am facing a problem in my c# webservice application. Exceptions are not handled at a certain point anymore. The application simply stops without any further messages/faults exceptions. This is what happens:

Problem:

  • in a catch section of a method, I throw a new Exception containing additional information on the exception;
  • the underlying exception comes from another part of my application; the 'stack' of exceptions is about 20, but this does not seem to be an issue here;
  • when using the VS2012 development server (which is 32 bit I assume), or IIS in 32 bit mode, the thrown exception is picked up by the calling method as expected (finally resulting in a FaultException of my webservice)

Steps I have taken so far or other information that might be useful:

  • I can easily reproduce the exception; it simply stops working at exactly the same point everytime I run my code. Unfortunately my project is too large/complicated to present it here though.
  • At first I assumed differences between the VS2012 development server on the one side and IIS on the other cause my problem. However, when I configure my application pool as 32 bit in IIS, everything works fine. Moving to 64 bit causes this behavior.
  • memory usage does not seem to be an issue; in my application I use (large) xml input files. Changes to (the size of) these files have no impact on my problem.
  • I tried using the diagnostic tools provided for webservices. These do not really help me, since I can see what happens (or should I say does not happen) while debugging my application in VS2012;

And here it comes! My original code looks like this:

try
{
  //some code here throws an exception
}
catch (Exception ex)
{
  throw new Exception("some message", ex); //after this line no activity anymore
}

When I change this to:

Exception myex = null;
try
{
  //some code here throws an exception
}
catch (Exception ex)
{
  myex = new Exception("some message", ex);
  return null;
}
finally
{
  if (myex!=null) throw myex;
}

my problem is solved!? Does anyone have an explanation for this behavior? I hope to rely on normal exception handling mechanisms.

Another remark: when I put a 'throw new Exception()' before the try{} section, my code runs fine as well (but of course, I do not want that).

Anyone any clue? Thanks in advance!

Dirk
  • 121
  • 3
  • 5
    Can you reproduce this with a short but complete console app? You say you can reproduce it in your app - it would be very helpful to reproduce it *not* in the context of your app, and *not* in a webservice. – Jon Skeet Jun 19 '13 at 12:00
  • @JonSkeet - looks like the WebService part might be crucial. Still wort trying to reproduce though. – H H Jun 19 '13 at 12:06
  • 1
    @dirk - can eleborate on the _The application simply stops without any further messages/faults exceptions_ a little? What can you see in the debugger at that point? – H H Jun 19 '13 at 12:08
  • @JonSkeet - thanks. We are building a unit test that bypasses all webservice code. I also had the idea of isolating tis issue from the webservice context. I'll let you know the result of this. – Dirk Jun 19 '13 at 12:13
  • @JonSkeet - Unfortunately, stripping our application (in steps) seems like a mission impossible. I have tried building this problem from scratch, without any luck so far. Hoped to find an answer or suggestion before this. – Dirk Jun 19 '13 at 12:15
  • 1
    @Henk Holterman - nothing. I can only push the 'stop'-button in VS. That's all. Nothing in EventViewer either. And (obviously), the webservice stops responding (I am using SoapUI to test it). – Dirk Jun 19 '13 at 12:17
  • 3
    Unless accessing your environment it is impossible to tell the cause. Should be a 64 bit module on IIS eating the exception I guess. If you are familiar with WinDbg + SOS you can live debug it. To get some assistance from experts, you might open a support case via http://support.microsoft.com to consult Microsoft. – Lex Li Jun 19 '13 at 12:29
  • @Lex Li - thank you. I am not familiar with the tools you mention ,but have access to resources that probably are. In any case, a stripped example is useful. I'll work on that one. – Dirk Jun 19 '13 at 12:33
  • Would these answers be of some help to you ? http://stackoverflow.com/questions/4933958/vs2010-does-not-show-unhandled-exception-message-in-a-winforms-application-on-a http://stackoverflow.com/questions/1583351/silent-failures-in-c-seemingly-unhandled-exceptions-that-does-not-crash-the-pr – aybe Jun 19 '13 at 12:56
  • Have you tried system.diagnostics tracing? – matt-dot-net Jun 21 '13 at 14:51
  • To add to matt-dot-net: just add a bunch of listeners in your config and see what is handled. – Stu Jun 21 '13 at 16:12
  • 2
    I'm interested in seeing the IL generated by the suspect code. –  Jun 21 '13 at 17:52
  • What mode is is your project containing the erroneous code set to? Release or Debug? – developer747 Jun 21 '13 at 20:55
  • 1
    Could you post the actual code that runs inside each of the two catch blocks? – Iucounu Jun 23 '13 at 12:00
  • Is your application pool being reset in IIS (crashing) and restarting? – tsells Jun 25 '13 at 02:46
  • "some code here throws an exception". What exception is it? It could matter. – doug65536 Jul 24 '13 at 15:14

4 Answers4

1

Are you running this from a background worker? I think you could be running into an issue with thread locking up in your first section of code, but then the return null allows the thread to finish in your second section of code.

I have seen some errors along these same lines where using a MessageBox.Show() command will allow the code to work correctly.

Ermac Pd
  • 3
  • 2
0

This issue may be related to platform itself. You may report it to Microsoft Connect and hopefully you'll get answer quickly.

gmail user
  • 2,753
  • 4
  • 33
  • 42
0

Are any of the reference assemblies in your project 32-bit by chance and referenced in that method's scope? If so that would be a good case as to why running in 64 would cause undefined behavior. I have been bitten by this before on another project and had mysterious app crashes.

Stewart Henderson
  • 1
0

When using a 64 bit machine, I have seen similar behavior in VS2012 which has been corrected (i.e., the bad behavior vanished) by setting the platform explicitly to x64 (rather than 'Any CPU') and also by disabling (unchecking) any 'Enabled Debuggers'. I have no explanation as to why these hacks have worked.

You can create a new "Active solution platform" in Menu:Build->Configuration Manager ....

The debug settings can be found in Menu:Project->proj properties.

I'd be interested in finding out why this works or if others have found similar fixes to unexplained behavior issues around exceptions.

CarlH
  • 568
  • 5
  • 16