.net - Using C# COM in unmanaged C++ project -> First-chance exception at 0x7697C41F (KernelBase.dll)

Question

I'm trying to call methods from a C# COM project in an unmanaged Visual C++ solution, but I keep getting the next error

First-chance exception at 0x7697C41F (KernelBase.dll) in Program.exe: 0x04242420 (parameters: 0x31415927, 0x6F310000, 0x00BBDAE8).

at the next piece of code

SalesForceNew::IMyObjectClassPtr p;
p.CreateInstance(__uuidof(SalesForceNew::TestObject)); // error
SalesForceNew::MyObject mo = p->getObject(1, "a");

However the value of mo is as expected (5, "aa").

I import the tlb-file with this line of code:

#import "C:UsersBobDesktopComTestSalesForceNewinx86DebugSalesForceNew.tlb" named_guids

The C# project is as follows:

The interface:

using System.Runtime.InteropServices;

namespace SalesForceNew
{
    [ComVisible(true)]
    [Guid("22901ACD-CA30-4D3E-B84B-73B707026AE5")]
    public interface IMyObjectClass
    {
        MyObject getObject(int i, string s);
    }

    [ComVisible(true)]
    [StructLayout(LayoutKind.Sequential)]
    public struct MyObject
    {
        public int Getal;
        public string Text;
    }
}

the class implementing the interface:

using System.Runtime.InteropServices;

namespace SalesForceNew
{
    [ClassInterface(ClassInterfaceType.None)]
    [Guid("234A2A35-F270-458D-A67B-C834EB794B27")]
    [ComVisible(true)]
    public class TestObject : IMyObjectClass
    {
        public MyObject getObject(int i, string s)
        {
            return new MyObject() { Getal = i * 5, Text = s + s };
        }
    }


}

I checked the options Register for COM interop and Make assembly COM-Visible in the properties of the C# COM project.

---

UPDATE: the error won't come up if we change the frameworkversion of the C# COM project to 2.0, 3.0 or 3.5. It only shows up when the frameworkversion is 4.0 or 4.5.

Answer 1

Exceptions whose exception code is less than 0x80000000 are non-fatal exceptions. They tend to be used to pass information. The shoe fits here, exception code 0x04242420 has been reverse-engineered to CLRDBG_NOTIFICATION_EXCEPTION_CODE, type the number in a google query to see the hits. This answer from a Microsoft employee is probably the most reliable one:

Out of curiosity I did a little digging and found that this is actually an undocumented exception (CLRDBG_NOTIFICATION_EXCEPTION_CODE) that is apparently an addition to the IPC protocol used by the managed debugger in the 4.0 CLR. It should be entirely safe to ignore.