unhandled exception not caught by SA

JDHnz · January 16, 2012 8:47PM

Today is my first day at trying out using Smart Assembly, so I could potentially be doing something really silly, but if I am then I can't see it.

I have spent the past 30 months migrating our big VB6 application to VB.NET. We had produced our own tool for augmenting the code in the VB6 project with error handling and reporting, so rather than trying to get that working in .NET too, we thought it would be easier and faster to investigate third-party tools to do the job and SA was first on the list.

After some initial false starts I've managed to process the WinForms application assembly and get a new assembly that runs ok and lets me get into testing the results. I have been able to generate an unhandled exception from our app that looks to be the result of a late-bound call which now fails because of obfuscated method names not being what it is expecting.

System.MissingMemberException: Public member 'RemoveField' on type '#vH' not found.
   at Microsoft.VisualBasic.CompilerServices.Symbols.Container.GetMembers&#40;String& MemberName, Boolean ReportErrors&#41;
   at Microsoft.VisualBasic.CompilerServices.NewLateBinding.CallMethod&#40;Container BaseReference, String MethodName, Object&#91;&#93; Arguments, String&#91;&#93; ArgumentNames, Type&#91;&#93; TypeArguments, Boolean&#91;&#93; CopyBack, BindingFlags InvocationFlags, Boolean ReportErrors, ResolutionFailure& Failure&#41;
   at Microsoft.VisualBasic.CompilerServices.NewLateBinding.LateCall&#40;Object Instance, Type Type, String MemberName, Object&#91;&#93; Arguments, String&#91;&#93; ArgumentNames, Type&#91;&#93; TypeArguments, Boolean&#91;&#93; CopyBack, Boolean IgnoreReturn&#41;
   at #Fq.#Qqb.#Tob&#40;&#41;
   at #Fq.#Qqb.#I3&#40;Object eventSender, FormClosedEventArgs eventArgs&#41;
   at System.Windows.Forms.FormClosedEventHandler.Invoke&#40;Object sender, FormClosedEventArgs e&#41;
   at System.Windows.Forms.Form.OnFormClosed&#40;FormClosedEventArgs e&#41;
   at System.Windows.Forms.Form.WmClose&#40;Message& m&#41;
   at System.Windows.Forms.Form.WndProc&#40;Message& m&#41;
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage&#40;Message& m&#41;
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc&#40;Message& m&#41;
   at System.Windows.Forms.NativeWindow.Callback&#40;IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam&#41;

The problem is that I was expecting this to be handled by the standard template provided by SmartAssembly, but instead I get the regular WinForms unhandled exception dialogue box. I have my SA project set with the "I want errors reported in my application" option selected.

Obviously I am going to have to change the code so that the call is no longer late-bound, but before I worry about that I want to be sure that the error reporting is sending reports back to me of any problems encountered.

What am I missing?

james.davies · January 18, 2012 10:48AM

Hi,

Here are some ideas:

It could be a clash between your error handling code and the error handling code inserted by SmartAssembly. Is your code still implementing an unhandled exception handler ?

Or it could be related to multiple app domains. Are you using multiple app domains?

Can you throw some simple exceptions elsewhere in your code ? Are any of these reported correctly ?

Is it possible you are using a build script which uses an older saproj that does not have error reporting turned on.

JDHnz · January 18, 2012 4:15PM

james.davies wrote:

Hi,

Here are some ideas:

It could be a clash between your error handling code and the error handling code inserted by SmartAssembly. Is your code still implementing an unhandled exception handler ?

We did have a very basic one in the earlier stages of the migration, as a placeholder for when we were still considering doing our own error reporting system, but this has all been removed from the project now.

Or it could be related to multiple app domains. Are you using multiple app domains?

Not intentionally. Is there anything in the .NET framework classes used to support code migrated from VB6 that could be doing so behind the scenes?

Can you throw some simple exceptions elsewhere in your code ? Are any of these reported correctly ?

I just added one right at the beginning of the Main() method and it was handled correctly. I will try adding more around the area where it is not reporting them correctly to see if that provides any more clues as to what is going awry.

Is it possible you are using a build script which uses an older saproj that does not have error reporting turned on.

No, we're not using a build script yet. I'm still using the tools interactively at this stage.

JDHnz · January 18, 2012 8:28PM

james.davies wrote:

Or it could be related to multiple app domains. Are you using multiple app domains?

While I'm fairly certain that we're not using multiple app domains, we might be doing something a little different with the message loop from the standard Winforms app, by having multiple calls to System.Windows.Forms.Application.Run() for when we have different forms as the main window of the app at different stages.

Our app runs something like this:

Sub Main
    fSplash = New frmSplash
    fSplash.Show&#40;&#41;

    ' program initialisation code goes here &#40;open DB connection, etc.&#41;

    System.Windows.Forms.Application.Run&#40;fSplash&#41;

    Do While fSplash.IsLoggedIn
        fSplash = Nothing

        fMDI = New frmMDI
        System.Windows.Forms.Application.Run&#40;fMDI&#41;

        If fMDI.IsExitingApp Then Exit Do
        fMDI = Nothing

        fSplash = New frmSplash
        fSplash.Show&#40;&#41;
        System.Windows.Forms.Application.Run&#40;fSplash&#41;
    Loop
End Sub

My experiments showed that any exceptions thrown before the call to System.Windows.Forms.Application.Run(fMDI) would be caught by the SA UnhandledException handler, but after that they would be dealt with by the default Winforms handler.

JDHnz · January 23, 2012 6:18PM

I have created a minimal project that reproduces the problem I have encountered. It can be downloaded from here.

You will notice that a click on the Throw Exception button on the "Splash" form, the first time it is opened, results in the standard SmartAssembly error window popping up, but a click on the Throw Exception menu item in the MDI or a click on the Throw Exception button on the Splash window after logging in and back out again, results in the default Windows Forms exception window.

james.davies · January 25, 2012 11:44AM

Error reporting uses the standard application message loop.

It seems that extra calls to Application.Run() cause a problem with this.

It could be that calls to Application.Run() start a new message loop and SA is hooked into the old one causing the exceptions to not be reported.

Thanks for the reproduction of the problem. I will add this to our bug tracking system and see what the developers say.

JDHnz · February 7, 2012 3:27PM

Has any progress been made on getting SA to cope with this scenario?

JDHnz · February 20, 2012 5:09AM

[bump] Anything?

james.davies · February 21, 2012 9:58AM

There are no comments yet from the developers on this bug. I will try to get them to take a look.

james.davies · February 24, 2012 6:22AM

(Have heard from developer regarding this:)

This problem is because the current thread context (which is where the unhandled exception handler gets attached) is completely removed at the end of the Application.Run method.

Please use Form.Show instead of Application.Run - http://social.msdn.microsoft.com/Forums/en-us/winforms/thread/aead5e9a-2e06-4adf-aecc-f45a2a633768

unhandled exception not caught by SA

Comments

Product Learning

Community Forums

Events & Friends

Simple Talk