Unable to debug interop

[Xavier Pacheco]

unable to debug/interop

Scenario

1. We have a VB6 application that performs late-binding on a .NET
interoperable component. Our component is invoked as in-proc process.
The VB6 code looks like this:

Private Sub Command4_Click()
Dim cc

Set cc = CreateObject("MyAssm.MyComponent")
Set xds2 = cc.CallFoo()

End Sub

2. the above creates the object and the function is invoked we are able
to verify this by writing to the event log from within CallFoo().
However, setting a breakpoint anywhere within CallFoo() is not
effective (Using VS.NET).

3. Here some more information if this helps

- the assembly containing the component references other assemblies.
This main assembly and all referenced assemblies (including those that
are CCW'ed) exist in a common directory. All have been
regasm'ed with the codebase directive. NOTE: We only need to debug
into the main assembly (for now).

- all assemblies are placed in the GAC

- symbol files also exist in the same directory

- versions on all the asemblies are specified as 1.0.0.0 to avoid any
version ambiguity.

- On the main assembly, we've tried the following entries in the

Project | Properties | Configuration Properties | Debugging section:

Debug Mode: Program
Start Application: points to the VB6 (unmanaged app) that
creates/invokes our component
Working directory: directory in which the VB6 app AND interop DLLs
reside

- We've tried with and without the command line arguments:
/ProcessID:{AppID}. However, I'm not sure this makes sense in the
context of an in-proc process.

Any clues as to why the break point would not be hit within VS.NET?

- xavier

[Oleg Starodumov]

Check these things:

* Modules are loaded from expected locations (use Modules window)
* Symbols are loaded for the modules (use Modules window)
* Try to attach the debugger to the target process in mixed mode and see
if the breakpoints will start working (e.g. open a new solution for
the executable and select "Mixed" in Debugger Type setting,
or attach to an already running process and select both Native
and CLR debug engines)

Also try this breakpoint helper:
http://www.controlav.com/bphelper

Regards,
Oleg
[VC++ MVP]

[Xavier Pacheco]

Oleg,
Thanks for your reply. The Modules window reveals:

CCFRPNortelImport.dll 11000000-1102E000
C:\WINNT\assembly\GAC\CCFRPNortelImport\1.0.0.0__38cdbebcc474f929\CCFRPN
ortelImport.dll 68 1.00.0.0 [1824] Project1.exe: Native 5/2/2005 12:18
PM No symbols loaded.

the GAC entry does in fact refer to the correct file location. The
Symbol file exists in the same location as the dll of the same name.

I've changed the VB6 code to the following:

Set cc = CreateObject("CCFRPNortelImport.CImportHandler")
MsgBox "Hello"
Set xds2 = cc.ProcessMsg(ob, xds)

So that I could try to force load the symbol information (after the
MsgBox). But the module window does not reveal that the symbol
information is getting loaded when I do this although it gives no error.

I will try your other suggestion for mixed mode as well.

Thanks for the reply!

- xavier

[Xavier Pacheco]

>> * Try to attach the debugger to the target process in mixed mode and
<<

Attaching doesn't work either. I think you're right about the debug
symbols not getting loaded as indicated by the module windows. But I
cannot find how to force those to load. Any ideas?
-xavier

[Oleg Starodumov]

> I've changed the VB6 code to the following:
>
> Set cc = CreateObject("CCFRPNortelImport.CImportHandler")
> MsgBox "Hello"
> Set xds2 = cc.ProcessMsg(ob, xds)
>
> So that I could try to force load the symbol information (after the
> MsgBox). But the module window does not reveal that the symbol
> information is getting loaded when I do this although it gives no error.
>

You mean, you tried R-Click + Reload Symbols and it did not work?

Then compare the time stamps of the DLL and of the corresponding PDB file.
Are they the same? You can also use this tool to check if the DLL and
the PDB file match:
http://www.debuginfo.com/tools/chkmatch.html

If the PDB file does not match the DLL, there is something wrong with
the build process.

Oleg

[Xavier Pacheco]

Oleg,

> You mean, you tried R-Click + Reload Symbols and it did not work? <

Yes, that's what I meant. Interestingly, the file that shows up refers
to the following:

C:\WINNT\assembly\GAC\CCFRPNortelImport\1.0.0.0__38cdbebcc474f929\CCFRPN

ortelImport.pdb

Therefore I have to browse to the actual directory in which the file
exists. I don't know if this is a useful data point.

>> Then compare the time stamps <<

Identical.

>> also use this tool to check <<

Used and the files match.

Another person told me that I have to set the symbols for VS.NET and
refered me to:

http://support.microsoft.com/?id=319037

Does that sound right to you?

Finally, I'm using enterprise services here - I don't know if that's
important to know.

Thanks for your help Oleg!

- xavier

[Xavier Pacheco]

Oleg,
You sent me in the right direction. I removed the GAC entry and it
worked. As the GAC relocates the DLL, the pdb file would not be found
unless its in that same directory or unless I use _NT_SYMBOL_PATH.
Thanks for your help.
- xavier

[Xavier Pacheco]

Oleg,

Well, we were almost there.

While we were able to debug our system using a very generic VB6
application. We've run into an issue using the real application that
initiates our object. There is one big difference between the two
applications. Our class is being invoked by a COM+ transaction started
by VB6 code. When doing this outside of the debugging environment,
everything works fine. However, when doing it within the debugging
environment, the VB app hangs. Basically the process is:

VB App -> COM+ Transaction -> Our Interopable component

When the following is used in the debugging environment it works:

VB App -> Our interoperable component.

I do not know if this is important but the last thing to be loaded when
going through COM+ is:

System.EnterpriseServices.Thunk.dll 79620000-79636000
C:\WINNT\assembly\GAC\System.EnterpriseServices\1.0.5000.0__b03f5f7f11d5
0a3a\System.EnterpriseServices.Thunk.dll 174 1.01.4322.2032 [1400]
CCFAutoTester.exe: Native 7/15/2004 12:43 AM No symbols loaded.

That's where the app hangs.

Any ideas?

- xavier

[Oleg Starodumov]

I don't know much about COM+ transactions, so probably cannot really help,
but what if you break into debugger (when the app has hung)
and get the complete call stacks with SOS?
It might give an idea what the application is doing.

Oleg

[Xavier Pacheco]

Oleg,
I found this but it assumes that the COM+ component is a server

http://msdn2.microsoft.com/library/ya4xb00s(en-us,vs.80).aspx

Still digging.