从.Net应用程序打开VB6表单时，内存无法“读取”错误

Question

I have an application written in C#.Net (Framework 2.0 if it matters). It calls a VB6 exe that exposes a COM class with one method - that shows a form.

When the VB form is closed, I get a system error (Windows message): The memory location could not be read. Then, Windows asks me whether to close the application or debug it. It doesn't really matter what I choose since there are not debuggers installed on the test machine and when I select debug it gives me a message that it will have to close.

The error only happens under two conditions (both must apply):

• When this is run under Windows 2000.
• Also, this only happens if I click the "Display Report" button first, which calls another COM DLL - Crystal reports - to generate a report.

Basically, the flow is like this:

C#.Net application
     |-- MDI Form
          |   When clicking a button on the form, the VB6 method is called
          +-- showing the form. setParent(VBForm.Handle, DotNetForm.Handle) is called
          |   and the form is shown. The called method returns (there is no return value)
          |    |
          |    +-- When clicking "Display report", crystal reports is used to generate a report and show it to the user
          |    |
          |    \-- When Exit button is clicked, form is closed - 
          |
          \-- .Net form keeps on living long after that inner form is closed

Does anyone know what could cause such an error? The VB has an On Error Goto line surrounding the entire Main method, which should catch any error in VB - but it doesn't. The error does, however, come from the VB-generated EXE file.

Answer 1

You could confirm which module within the VB exe is crashing by attaching an unmanaged debugger and seeing what the stack trace is.

Crystal Reports sounds like a likely culprit, but it is possible that something else is triggering the problem. Assuming you have access to the VB code I would check that all the Crystal Report COM objects are being released correctly. If something is being left around then it could be interacting badly with application shutdown.

If you want a really hackish solution you could consider calling the Win32 TerminateProcess function within the OnClose event. This will terminate the process without informing any attached DLLs ... not pretty and may lead to dangling connections to databases, etc that will need to clean themselves up (likely on timeout).