Application crash when using .ocx with events that have ref objects, works in Framework - System.Windows.Forms.AxHost

[NikolaosWakem]

• .NET Core Version:
  3.0 & 3.1

• Have you experienced this same bug with .NET Framework?:
  No

Problem description:

Using ActiveX .ocx user control that has specifically not null, ref objects passed on events crashes entire application due to corrupt memory - Same code works in Framework

Expected behavior:

ref object is not corrupt on return to OCX after calling event inside core application

Minimal repro:

using System;
using System.Windows.Forms;

namespace ConsoleApp1
{
    class Program
    {
        [STAThread]
        static void Main(string[] args)
        {
            var c = new WindowsFormsControlLibrary1.UserControl1();
            c.CreateControl();
            c.TestEventByRef += C_TestEventByRef;
            c.WithObjectByRefTestEvent();
            c.Dispose();

            var c2 = new AxAxolotl.AxTestControl();
            c2.CreateControl();
            c2.TestEventByRef += axTestControl1_TestEventByRef;
            c2.WithObjectByRefTestEvent();
            c2.Dispose();
        }

        private static void C_TestEventByRef(object sender, WindowsFormsControlLibrary1.TestEventByRefEventArgs e)
        {
            e.TestObject = new WindowsFormsControlLibrary1.TestObject { Text = "Framework Out" };
        }

        private static void axTestControl1_TestEventByRef(object sender, AxAxolotl.__TestControl_TestEventByRefEvent e)
        {
            MessageBox.Show(e.column.Text);

            e.column = new Axolotl.CTestObject { Text = "OCX Out" };
        }
    }
}

example winforms control that works in framework and core

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Drawing;
using System.Data;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;

namespace WindowsFormsControlLibrary1
{
    public class TestEventByRefEventArgs : EventArgs
    {
        public TestObject TestObject { get; set; }
    }

    public partial class UserControl1 : UserControl
    {
        public event EventHandler<TestEventByRefEventArgs> TestEventByRef;

        public UserControl1()
        {
            InitializeComponent();
        }

        public void WithObjectByRefTestEvent()
        {
            var testObject = new TestObject { Text = "In" };

            var testEventByRefEventArgs = new TestEventByRefEventArgs { TestObject = testObject };

            TestEventByRef?.Invoke(this, testEventByRefEventArgs);

            MessageBox.Show(testEventByRefEventArgs.TestObject.Text);
        }
    }
}

example OCX (in VB6) control that works in framework by crashes in core

Option Explicit

Event TestEventByRef(ByRef Column As CTestObject)

Public Sub WithObjectByRefTestEvent()
    Dim a As CTestObject
    Set a = New CTestObject
    a.Text = "OCX In"
    RaiseEvent TestEventByRef(a)
    MsgBox a.Text
End Sub

// CTestObject.cls

Option Explicit

Public Text As String

Here is a repro in a zip

https://axolotl.blob.core.windows.net/issue2863/Issue2863.zip

you have to first register the .ocx "regsvr32 Issue2863\VB6OCX\Axolotl.TestControl.ocx"

then run ConsoleApp1 (core) in debug with exceptions turned on.. (ConsoleApp2 is framework and works)

Issue2863\VB6OCX\Axolotl.TestControl.ctl

MsgBox a.Text <== a is corrupt

Exception thrown at 0x11001F16 (Axolotl.TestControl.ocx) in ConsoleApp1.exe: 0xC0000005: Access violation reading location 0x00000000. occurred

[NikolaosWakem]

This is pretty nasty bug.. hope winforms developers aren’t using any ActiveX controls...

[weltkante]

They'll have to work around this (or not use .NET Core) until its fixed eventually, like they have to work around the other bugs in the Desktop version. I have seen a few crashing/corruption bugs with Desktop Framework AxHost which never were fixed. OLE/ActiveX is a dying technology which few still understand, lots of documentation already disappeared, and there is almost no test coverage in the WinForms repo, so its not surprising things start to break. The best bet if you want to keep AxHost technology working is if C++/MFC control authors step up (because that technology seems to be still officially supported) and bring testable scenarios so WinForms can actually support them in a reliable way.

That aside, VB6 has been unsupported for ages and (as far as I'm aware) is subject for failing at any time. In particular it relies on the same interop as the Office API (IMsoComponentManager) and even for Office its currently unclear on whether .NET Core will support interop integration. If they don't reimplement IMsoComponentManager support you'll have to get ready for a rough trip ahead if you still use VB6 components because all the hidden magic WinForms Desktop Framework did behind the scenes to coordinate modal forms and things like DoEvents will suddenly behave differently in subtile ways. (Note that this is currently the case in .NET Core 3.x) If you still have VB6 components in your products you might want to start thinking about options for an exit strategy, things look very fragile and way too undocumented to be relied upon in .NET Core. Its status of being unsupported probably means things will finally start falling apart.

I'm not trying to talk bad, just trying to be realistic on the perspective given what I currently know about the ecosystem. We have an application ourselves which originated in VB6 and still isn't 100% ported over to C#, but as it looks currently I'd never dare to move that application to .NET Core.

Also, just as a fair warning, if you expose .NET to VB6 you better not try to register any .NET Core component in the registry without knowing exactly what you are doing. The COM story for WinForms has not been thought through at all and the ComVisible and Guid attributes have mostly just been copyied from Desktop Framework. If you get something wrong when registering .NET Core components in the registry you risk corrupting your Desktop Framework .NET installation. At least you can't do it accidently because .NET Core doesn't provide tools to register something in the registry.

[NikolaosWakem]

Just put this up because the code works in framework and it has broken in core with no work around I could find in core.. I don’t need it fixed for myself, just noticed it so thought I’d report it as it’s bound to be an easy fix as it is 100% reproducible..

[weltkante]

I didn't intend to imply you should close the issue, note that I'm not a team member and just trying to be helpful, in this case explaining the larger picture of why things are in a bad state and giving a warning that VB6 will cause trouble on .NET Core regardless of AxHost bugs getting fixed.

Feel free to reopen if you care about this bug getting looked at or want an official response about how they deal with VB6 repros in WinForms, as far as I remember there has not been a precedent on github (Microsoft sometimes did reject repros based on VB6 in our own support tickets in the past, so we often had to make sure bugs also affect C++/MFC).

/cc @RussKie in case you want this to be looked at even though the issue is closed

[NikolaosWakem]

3.1 LTS broken but fixed in 5.0 so all Good :-D

[elachlan]

@NikolaosWakem if this is fixed, can the issue be closed?

[ghost]

This submission has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 14 days.

It will be closed if no further activity occurs within 7 days of this comment.