Trace all handled exception

Question

I am trying to understand why a deployed application is not working properly. I have pinned down the problem to a particular update routine. Sadly, the routine is embedded into a do nothing try-catch.

bool requireUpdate = false;
try
{
    requireUpdate = !client.IsUpToDate();
}
catch{ }

I need a way to get the exception without having to recompile and do a deploy.

Is there is a way to modify the app.config file so it can trace all handled exceptions to a log file, regardless of how they have been handled?

Answer 1

This solution may be what you are looking for.
Basically the instruction is to use this block of code:

System.Diagnostics.EventLog.WriteEntry("MyEventSource", exception.StackTrace,
System.Diagnostics.EventLogEntryType.Warning);

Additionally the app.config from that same link seems to be like so: <system.diagnostics> <switches>

    <add name="MySwitch" value="Verbose" />
</switches>
<trace autoflush="true">
    <listeners>
        <add name="EventLogger"
             type="System.Diagnostics.EventLogTraceListener"
             initializeData="NameOfYourApplication" />
    </listeners>
</trace>

Answer 2

Unfortunately there is nothing that can be done about handled exceptions, as they are handled (even if very badly, as in your case).

The best way to get them will be to rewrite/recompile/deploy.

Answer 3

UPDATED

CLR profiling can help ya!

Have a look at this link: http://msdn.microsoft.com/en-us/magazine/cc301839.aspx

You can basically track your exceptions:

"he profiling API offers an extensive set of callbacks that depict in detail the search, unwind, and finally phases of the exception handling cycle. An interesting profiling scenario would monitor managed exceptions and provide additional information such as the Win32 thread that threw the exception, the function that was on the top of the stack, the arguments of that function, and the locals that were in scope at the point where the exception occurred."

Answer 4

Tricks I've used for this in Java:

Go through all of the catch blocks in the application, looking for empty ones. Add a debug or trace message to the block saying something like, "Catching expected exception", and the exception. You should have this anyway, and set a policy that silently swallowing exceptions is absolutely not acceptable.

If that fails to flush out the exception, recompile the base Exception, add a block to the no-arg constructor to log a stack trace if the application is in debug (or trace) mode. Obviously this is easier to do if your application/library has its own Exception heirarchy, but there are ways to inject this behavior (here the way to do this in C# would be distinct from how I'd accomplish this)

Answer 5

There's another option, but it may or may not be pretty: Moles.

Technically used for unit testing, Moles allows you to replace any .NET method with a delegate. You might be able to use it to replace that method with your delegate that does what you want instead.

You might be able to replace the original method with a delegate that calls client.IsUpToDate() so you can snag the exception instead?

Moles is part of Pex: http://research.microsoft.com/en-us/projects/pex/default.aspx

Answer 6

Use low level debuggers, such as WinDbg you will be able to know first chance exceptions.