locked
VSPackage, debugger2.ExecuteStatement: What's the difference between making a call by debugger2.ExecuteStatement() and adding the call directly in the source code in Visual Studio 2013? RRS feed

  • Question

  • We have an Excel add-in application which includes C# managed components and C++ and VB6 COM components. VS2013 is being used for the development of the project. We've also developed a Visual studio 2013 package which is to help the development and debugging  issues of the Excel add-in application.

    When I debug a C# managed component, SupportNetCSharp.dll, in VS2013, at a breakpoint, I can click an icon from my Visual studio package, which would call debugger2.ExecuteStatement() and eventually make the Excel Add-in in a Run State, This way, another debugging tool,which is an executable, can access the Excel add-in through COM interface from another process.

    Here are what happens after I clicks the icon from my visual studio package:

    1. the package calls debugger2.ExecuteStatement() to load EnterWaitLoopCSharp.10.0.dll(C#, managed code)

    2. the package calls debugger2.ExecuteStatement("EnterWaitLoopCSharp.10.0.dll!EnterWaitLoopCSharp.Operations.WizardHalt"), and thaw threads in the Excel Add-in if they are freeze.

    3. WizardHalt() method will call a method in an interface in VB6 COM dll, EnterWaitLoopVB6.dll,

    4. The method in the VB6 dll will call MyCommonCPlusPlus.dll!CMPDebugService::Wizard_EnterWaitSession() , which is a C++ COM method in MyCommonCPlusPlus.dll.

    5. Wizard_EnterWaitSession() will eventually call  AtlWaitWithMessageLoop() in MyCommonCPlusPlus.dll.

    The above five steps would make visual studio IDE in a Run State. The I could run an debug tool executable outside IDE to access a COM interface in the Excel Add-in.

    I got the following error when the debugging tool executable tried to access a MarshalByRefObject object in the Excel Add-in application:

    "An exception of type 'System.Runtime.InteropServices.COMException' occurred in mscorlib.dll but was not handled in user code.
    Additional information: An internal error occurred. (Exception from HRESULT: 0x8001FFFF (RPC_E_UNEXPECTED))"

    However, if I don't use the visual studio package to call debugger2.ExecuteStatement("EnterWaitLoopCSharp.10.0.dll!EnterWaitLoopCSharp.Operations.WizardHalt"). And if I insert a call similar to "EnterWaitLoopCSharp.10.0.dll!EnterWaitLoopCSharp.Operations.WizardHalt" in my C# code in Visual studio, which eventually calls AtlWaitWithMessageLoop() in MyCommonCPlusPlus.dll and make the excel Add-in in a Run State,  I don't see any errors.

    What's the difference for a call made from debugger2.ExecuteStatement() and the similar call directly called from the C# project in the visual studio? Any idea how I can fix this issue?

    A side note here is that when we use the VS2005, we don't see any errors. It seems that we started to see this error after we switched to VS2013.

    I've attached the call stack when I use the debugger2.ExecuteStatement(). Hopefully it can help understand the sequence.

    Any help would be greatly appreciated.


    NR1234


    • Edited by NR1234 Thursday, August 11, 2016 12:23 AM
    Thursday, August 11, 2016 12:19 AM

Answers

  • You could try breaking when the exception is thrown. Go to Debug > Exceptions...and use the Find...option to locate System.Runtime.InteropServices.COMException. Tick the option to break when it's thrown and then debug your application.
    Hopefully it will break somewhere meaningful and you'll be able to trace back and find the source of the error.
    Thursday, August 18, 2016 8:59 AM