 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Visual Studio.NET / Debugging / May 2005Unable to debug interop
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 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] 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 > Check these things: > [quoted text clipped - 12 lines] > Oleg > [VC++ MVP] > I've changed the VB6 code to the following: > [quoted text clipped - 5 lines] > 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 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 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 >> * 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, 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 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 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. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.