Click here to Skip to main content
15,885,033 members
Please Sign up or sign in to vote.
5.00/5 (1 vote)
See more: , +
We have a .net application (developed by an external partner), that is producing issues we need to investigate. We don't have the source, thus we have reflected the code, and noticed, that the exception handling is quite lazy, in most cases exceptions are handled generally, actual details are suppressed and not logged. Thus even if we know where the problem is, we can not figure out what exactly it is.
My question is: is there any client side tool that can be used to track exceptions raising from the native sql client driver or the .net driver, before reaching the application level. Something like the profiled does on server side.
Thank you.
Posted
Updated 15-Aug-13 21:46pm
v2
Comments
Maciej Los 16-Aug-13 3:24am    
Is it a windows executable or ASP.NET application?
Zoltán Zörgő 16-Aug-13 3:45am    
It is a windows application.
Maciej Los 16-Aug-13 4:07am    
Have you tried to use MS VS tools, like: Spy++, etc.
I hope the Debug Diagnostic Tool[^] will help you...
Zoltán Zörgő 16-Aug-13 7:03am    
Looks interesting , but after solving the problem of installing it on a non-english Windows, I am facing the problem how to configure it to detect handled exceptions. It is detecting the unhandled ones, but mines are handled.
Maciej Los 16-Aug-13 7:28am    
Very interesting issue... How to find a reason(s) of handled exceptions in .NET executable without source code? ;)
A 5!

Please, see this:
Windows Performance Toolkit (WPT)[^]
ATL/MFC Trace Tool (AtlTraceTool8.exe)[^]
Unhandled Exceptions and Tracing in the .NET Framework 2.0[^]

Exceptionless[^] may help you.
 
Share this answer
 
Comments
Zoltán Zörgő 16-Aug-13 14:25pm    
Thank you, I will try it if nothing "less commercial" helps. Worth a 5!
Most welcome... :) Thanks for the 5+.
Thank you all for your helpful suggestions. But I found my own answer that looks good.
Dotnet 4 has ExceptionServices[^] and the AppDomain that allows one to add FirstChanceException[^] handler to an AppDomain. So we simply add this handler. And we can make a wrapper around the third party clr executable by loading it into the appdomain. So we can trace exceptions already caught. And this is enough we don't want to handle them only to intercept. And it is working also with "client" applications that need earlier .net.

I have only a proof of concept, but it seems to work!
The application with the exception:
C#
using System;

namespace _throw
{
    class Program
    {
        public static void Main(string[] args)
        {
            try
            {
                throw new NotImplementedException("catch this");
            }
            catch
            {
            }
        }
    }
}

And the handler:
C#
using System;
using System.Runtime.ExceptionServices;

namespace catchh
{
    class Program
    {
        public static void Main()
        {
            AppDomain.CurrentDomain.FirstChanceException += FirstChance;
            AppDomain.CurrentDomain.ExecuteAssembly("throw.exe");
            Console.ReadKey();
        }

        static void FirstChance(object sender, FirstChanceExceptionEventArgs e)
        {
            Console.WriteLine("Exception: {0}\nMessage: {1}\nStack trace:\n{2}", e.Exception.GetType().FullName, e.Exception.Message, e.Exception.StackTrace);
        }
    }
}

The article with more details can be found here: http://firstchanceexception.com/tag/appdomain/[^].
 
Share this answer
 
v2
Comments
Maciej Los 18-Aug-13 12:05pm    
+5!
Zoltán Zörgő 18-Aug-13 14:45pm    
Thank you! I really appreciate this!

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900