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?

The person responsible for writing this code is a criminal that has to be judged :-) — Darin Dimitrov, Sep 23 '10 at 18:33
I know, and I also feel bad for having authorized such code back in the time it has been coded. — Pierre-Alain Vigeant, Sep 23 '10 at 18:37

score 2 · Answer 1 · answered Nov 20 '15 at 18:30

Just because I discovered this today (and I really like resurrecting old questions with not-too-helpful answers!), since .NET4, there is a new event on AppDomain, which fires before any exception handling.

At some point in the setup code for your app (e.g. Program.Main, Application_OnStart, etc), you can add a handler:

class Program
{
    static void Main(string[] args)
    {
        AppDomain.CurrentDomain.FirstChanceException 
            += FirstChanceException

        // ...rest of your app startup
    }

    private static bool LogFirstChanceExceptions
    {
        get  
        {
            return ConfigurationManager.AppSettings["logFirstChanceExceptions"] 
                                       .Equals(bool.TrueString)
        }
    }

    private static void FirstChanceException(object sender,
                                             FirstChanceExceptionEventArgs e)
    {
        if (e != null && 
            e.Exception != null &&
            LogFirstChanceExceptions)
        {
            Console.Error.WriteLine("First-chance {0}: {1}",
                                    e.Exception.GetType(), 
                                    e.Exception.Message);
        }
    }
}

(Untested, no warranty, etc. Not pictured: any re-entrancy handling, in case the FirstChanceException handler itself throws an exception)

Doesn't help the OP, but it might help people who can recompile, to include something that allows them to toggle this kind of tracing in the future.

score 1 · Accepted Answer · answered Sep 23 '10 at 18:35

1

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.

answered Sep 23 '10 at 18:35

Oded

489,969
99
883
1,009

+1 for rewriting the code. Today it's this function, tomorrow another. Fix the bad code, that's the only solution. – Darin Dimitrov Sep 23 '10 at 18:39
1

@Aliostad - you obviously never used profilers before. Chances are that the application will have to be stopped before/after each profiling session and it could very well be that it is not an option on a production environment anyway (installing the profiler and running it may have an adverse impact on the system). – Oded Sep 23 '10 at 18:57

Aliostad · Answer 3 · 2010-09-23T18:46:10.367

1

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."

edited Sep 23 '10 at 18:46

answered Sep 23 '10 at 18:36

Aliostad

80,612
21
160
208

Its not crashing; its doing nothing. – Pierre-Alain Vigeant Sep 23 '10 at 18:38
what crashes are you talking about? It's swallowing which is worse than a crash:-) – Darin Dimitrov Sep 23 '10 at 18:38
1

yes using the profiler API is definitely one way of doing it but I think that the time you would waste into it would be better used to rewrite this crap of a code. Also using the CLR API requires some administrative privileges and will probably crash the application after finished using it which is not a very good idea to do in production. – Darin Dimitrov Sep 23 '10 at 18:52

score 1 · Answer 4 · answered Sep 24 '10 at 02:56

1

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

answered Sep 24 '10 at 02:56

Lex Li

60,503
9
116
147

score 0 · Answer 5 · answered Sep 23 '10 at 18:42

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)

He wants a solution that does not require recompiles. – Oded Sep 23 '10 at 18:51 — Oded, Sep 23 '10 at 18:51

score 0 · Answer 6 · answered Sep 23 '10 at 22:25

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

score -2 · Answer 7 · edited May 23 '17 at 10:31

-2

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>

edited May 23 '17 at 10:31

Community

1
1

answered Sep 23 '10 at 18:35

Woot4Moo

23,987
16
94
151

err still messing up my syntax somehow – Woot4Moo Sep 23 '10 at 18:37
this shows how to use tracing but I don't see how this could be helpful in this situation. – Darin Dimitrov Sep 23 '10 at 18:37
2

Without recompiling... sweet mother of jeebus – Woot4Moo Sep 23 '10 at 18:41

Trace all handled exception

7 Answers7