C#, Interfaces and Interop

[Rhys666]

OK, I've had enough and need to ask. I'm looking at some Interop work carried out in .Net 2.

Essentially we have a VB6 application and associated classes, some of which provide Interfaces. As part of a recent project a .Net 2.0 'plug-in' has been developed, which implements a particular Interface from the aforementioned VB6 project. This 'plug-in' is then exposed to com and made accessible back to the aforementioned VB6 Application via Interop, (I know - it's horrible).

The items from the .Net 2.0 plug-in which implement the interfaces are themselves in turn implemented by a menu item in the VB6 application. They're early bound and a specific method is called at start up and at shut down. Event logging in the .Net 2.0 application suggests all of the elements of the call at start up and shut down are run to completion. When the VB6 application is started with the menu item implementing the plug-in attached, a 'Memory could not be "read"' application error is against the VB6 app is caught by the OS, (Windows XP), after application shut down whether you do or do not click the menu item. When the VB6 application is run in debug, the error is thrown when Visual Studio is exited.

Does anyone have any idea what could be causing this?

Cheers,

NB: If the above is confusing or unclear, I can try to clarify

Rhys
The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense Edsgar Dijkstra

Church of the Flying Spaghetti Monster

 

[B00gyeMan]

The simplest way I can think of (it's morning here and I've just woke up...) is using WinDbg and the SOS extension. Start the debugger, load the SOS extension and then start you VB application. The debugger will break upon exception. Inspect the call stack (when the debugger breaks it automatically selects the thread in which the exception was thrown). You should be able to see what happens. Then, if you cannot find the problem, post the call stack (and any additional details) here.


SOS.dll is usually located in C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\

WinDbg can be downloaded from here:

http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx

 

[Rhys666]

Cheers for that, I shall give it a go. As neither application was developed by me, this is really starting to be very frustrating so another avenue of attack is massively appreciated.

Rhys
The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense Edsgar Dijkstra

Church of the Flying Spaghetti Monster