Debugging .Net4 COM registered assembly from Win32 caller in Visual Studio 2010

Question

This is a very simple setup, I can't believe but I didn't find anybody with the same problem so far...

Create a .Net4 class library in VS2010. Create a simplest possible COM object:

[ComVisible(true)]
[Guid("CD157EBC-C89D-40b6-B531-E85FF4B3AE9A")]
[InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
public interface IAcorn
{
    bool Foo(string moo);
}


[ComVisible(true)]
[ClassInterface(ClassInterfaceType.None)]
[Guid("854B7690-C1C4-40c4-8059-B4F3450B30D0")]
public class Acorn : IAcorn
{
    public Acorn()
    {
    }

    public bool Foo(string moo)
    {
        return true;
    }
}

Set "Register for COM interop" option for the assembly. Set "platform target" to x86.

Create a Win32 client using Delphi, import the object, instantiate it using normal instantiation (translates to CoCreateInstance(ClassID, nil, CLSCTX_INPROC_SERVER or CLSCTX_LOCAL_SERVER, IUnknown, Result))

Run the Win32 application, everything works fine.

Try to debug the COM object from VS2010. Set the class library Debug option to start an external program, point to the executable you just created. When you launch the Win32 app from VS210, the program crashes (with StackOverflow) at the attempt to instantiate the COM.

Change the Target framework to .Net 3.5 Launch the debugging from VS2010, everything works including debugging.

Note - This is also a problem when using either CLR Hosting or unmanaged export COM instantiation. Both methods work with .Net4 but debugging is not possible.

The question is standard - why does this happen and is there a workaround?

Have you tried storing and restoring the FPU control word: stackoverflow.com/questions/191368/…? — Jens Mühlenhoff
@jens-muhlenhoff This fixed the problem for a test application. But the bigger application still does not stop in the debugger (also it was running without error even before). I'm afraid I need to understand the nature of the problem to find the correct fix. — Sergey Aldoukhov
The bigger application was fixed by removing the <supportedruntime> section from .config - it was pointing to .Net2 runtime. At the same time, setting the FPU wasn't necessary. I'm still uncertain why the test app fails (it doesn't have any manifest or config) - but you can claim the bounty. — Sergey Aldoukhov

Jens Mühlenhoff Jens Mühlenhoff · Accepted Answer · 2011-05-31T09:01:03

The .NET framework and Delphi may set or expect different values in the FPU control word.

That problem can be avoided by setting the register explicitly, before calling .NET code and resetting it after the .NET code is done:

How can I set and restore FPU CTRL registers?

Debugging .Net4 COM registered assembly from Win32 caller in Visual Studio 2010

1 Answers