tags:

views:

140

answers:

3

I am using this - otherwise excellent - vb tab control in one of my c# apps. When the app using it is installed on another machine, Windows tells the user in its usual friendly and descriptive manner that "The application encountered a problem and needs to close". I guess the control has some hidden vb-related dependency, but what can that be?

Any ideas guys?

A: 

Is the dll containing the control distributed with your app? Perhaps you have a dependancy in the GAC thay you are missing?

Ady
Thanks for your answer. I know this is a lame question, but how can I check for a dependency in the GAC?
Botond Balázs
In the project references, the dependant dlls will be listed, and this will also tell you if it is stored in the GAC or not.
Ady
+1  A: 

Click the 'What data does this error report contain?' button and there will be more descriptive info. (i.e. type of the thrown exception, module etc.).

For additional info see Dr. Watson vs. CLR.

arul
+1  A: 

Since the tab control appears to be managed code as well, your 'crash' is most likely an unhandled .NET exception.

Looking at the error details (by expanding the error dialog using the button provided for that purpose...) should give you the exception message, which should give you an idea of what's going on. If it's a missing dependency DLL, the name should be included in the message.

To get the full exception, including the stack trace, one of the following should work:

  • Least effort: in the first line of your own managed code, add an unhandled exception handler which shows the full exception in a message box or logs it to a file prior to rethrowing it

  • Medium effort: attach a debugger to the process on the client machine. If it's on your local network, setting up remote debugging should be trivial, and should also allow you to debug exceptions that occur prior to your first line of code executing (which may very well be the case if the error is binding-related...)

  • Most effort: obtain the crash dump file from the client machine, and look at the managed exception using Windbg and the SOS debugging extensions. Getting productive with the tools involved will take some time, but on the plus side will teach you valuable debug ninja skills that will allow you to tackle pretty much any 'mysterious crash'...

BTW, all standard 'VB dependencies' are part of the default .NET Framework install, so that's not your problem -- only the exact exception (and possibly stack trace) will tell you what's going on.

mdb