Regression in .NET 10: CFG violation (Indirect call guard check) when accessing Clipboard

[rampaa]

Description

After upgrading to .NET 10, an application intermittently crashes with an unhandled exception:

Indirect call guard check detected invalid control transfer

The crash occurs inside Clipboard.ContainsText() when it is called in response to WM_CLIPBOARDUPDATE. The same code path worked reliably in previous .NET versions.

Reproduction Steps

1. Create a WPF application targeting .NET 10.
2. Register for clipboard notifications using AddClipboardFormatListener.
3. Handle WM_CLIPBOARDUPDATE in a custom WndProc.
4. Call Clipboard.ContainsText() asynchronously from the message handler.

Minimal repro code:

private static nint WndProc(nint hwnd, int msg, nint wParam, nint lParam, ref bool handled)
{
    if (msg == WM_CLIPBOARDUPDATE)
    {
                _ = Application.Current.Dispatcher.BeginInvoke(DispatcherPriority.Send, () =>
                {
                           _ = CopyFromClipboard();
                });

        handled = true;
    }

    return 0;
}

private async Task<bool> CopyFromClipboard()
{
    while (Clipboard.ContainsText())
    {
        try
        {
            string text = Clipboard.GetText();
            return true;
        }
        catch (ExternalException)
        {
            await Task.Delay(5).ConfigureAwait(true);
        }
    }

    return false;
}

Run the app and frequently change clipboard contents (e.g., copy text rapidly from different applications).

Eventually, the process crashes with the CFG error.

Expected behavior

Clipboard.ContainsText() should either:

1. Return a boolean result, or
2. Throw a managed exception (e.g., ExternalException) if the clipboard is temporarily unavailable.

It should never cause a native crash or trigger a Control Flow Guard violation.

Actual behavior

The application crashes with an unhandled native exception:

Unhandled exception at 0x00007FFE23CC728F in JL.exe: 
Indirect call guard check detected invalid control transfer.

A crash dump shows the fault occurring inside Clipboard.ContainsText().

The exception cannot be caught in managed code.

Here's the full dump: https://mega.nz/file/z0FwBTCB#sssXKDAROlucZkEEVLPR5LKwxTfNex30nPqbgUl99mM

Regression?

Yes. This code path worked reliably in previous .NET versions. I never had a problem with .NET 5, .NET 6, .NET 7, .NET 8, .NET 9.

Known Workarounds

No response

Impact

No response

Configuration

No response

Other information

No response

[rampaa]

Possibly caused by dotnet/wpf#10544

[lindexi]

Possibly caused by #10544

Yes, I agree with you.

[lindexi]

@rampaa Could you try the code in WinForms?

public partial class Form1 : Form
{
    public Form1()
    {
        InitializeComponent();

        Load += Form1_Load;
    }

    private void Form1_Load(object? sender, EventArgs e)
    {
        _ = CopyFromClipboard();
    }

    private async Task<bool> CopyFromClipboard()
    {
        while (Clipboard.ContainsText())
        {
            try
            {
                string text = Clipboard.GetText();
                
            }
            catch (ExternalException)
            {
                await Task.Delay(5).ConfigureAwait(true);
            }
        }

        return false;
    }
}

I expected the same behavior as WPF, and then we can bring this issues to WinForms repo.

You can find my code in: https://github.com/lindexi/lindexi_gd/tree/4174cf49c4dd46acfa7d06080675d9499b4bdb85/Workbench/KunalljayfewereNefefoke

[rampaa]

@lindexi
The regression (and the dump file itself) was reported to me by a long-time user of one of my apps. Unfortunately, I can’t trigger the exception in WPF or WinForms at will.

Fortunately, we do have a full dump file. The exception appears to occur in the TryGetHGLOBALData method inside the System.Private.Windows.Ole.Composition class, which I believe started being used in WPF after dotnet/wpf#10544. Given this, it seems reasonable to assume that it would also affect WinForms.

Tagging @JeremyKuhne, since he is the owner of that PR and would likely have the most context on this change (and probably on dotnet/wpf#11402 as well).

[JeremyKuhne]

@rampaa We don't have access to the site where you have the dump. Can you include the call stack(s)?

[rampaa]

@JeremyKuhne Sure, here it is:

 	System.Private.Windows.Core.dll!System.Private.Windows.Ole.Composition<System.Windows.Ole.WpfOleServices, System.Windows.Nrbf.WpfNrbfSerializer, System.Windows.DataFormat>.NativeToManagedAdapter.TryGetIStreamData<string>(Windows.Win32.System.Com.IDataObject* dataObject, System.Private.Windows.Ole.DataRequest request, out string data) Line 448
 	System.Private.Windows.Core.dll!System.Private.Windows.Ole.Composition<System.Windows.Ole.WpfOleServices, System.Windows.Nrbf.WpfNrbfSerializer, System.Windows.DataFormat>.NativeToManagedAdapter.TryGetObjectFromDataObject<string>(Windows.Win32.System.Com.IDataObject* dataObject, System.Private.Windows.Ole.DataRequest request, out bool doNotContinue, out string data) Line 320
 	System.Private.Windows.Core.dll!System.Private.Windows.Ole.Composition<System.Windows.Ole.WpfOleServices, System.Windows.Nrbf.WpfNrbfSerializer, System.Windows.DataFormat>.NativeToManagedAdapter.TryGetDataInternal<string>(System.Private.Windows.Ole.DataRequest request, out string data) Line 492
 	System.Private.Windows.Core.dll!System.Private.Windows.Ole.Composition<System.Windows.Ole.WpfOleServices, System.Windows.Nrbf.WpfNrbfSerializer, System.Windows.DataFormat>.NativeToManagedAdapter.TryGetData<string>(string format, bool autoConvert, out string data) Line 667
 	PresentationCore.dll!System.Windows.Clipboard.GetTypedDataIfAvailable<string>(string format) Line 109
	PresentationCore.dll!System.Windows.Clipboard.GetText(System.Windows.TextDataFormat format) Line 164

The crash happens at the PInvokeCore.ReleaseStgMedium(ref medium); line.

Do you have any site that you are able to access where I can upload the full dump file in case you need it for further details?

[JeremyKuhne]

@rampaa The only thing I'm aware of is attaching to a VS Feedback ticket, which is where we point people when they don't want the general public to see things. I'm taking a look now, I'll let you know.

[JeremyKuhne]

It appears we're double releasing here. Erp. We're freeing the STGMEDIUM after releasing the HGLOBAL.

Fyi: I'm no longer on the WinForms team, but I'm actively working with them to get the fix made.

[rampaa]

Thank you very much for the quick reply. I’m glad to hear this is being actively worked on.

Is there anyone familiar with the WinForms side of the clipboard code who could shed some light on the other clipboard regression that my users are experiencing after migrating to .NET 10? Although the issue was discovered in a WPF app, which is why I opened it in this repo, the clipboard code is now shared. This makes me think the problem may affect both WPF and WinForms. It would be great if someone with relevant context could take a look and help clarify why the behavior changed, or perhaps offer a workaround.

[JeremyKuhne]

@rampaa looking at that one too.

[JeremyKuhne]

I've put up a PR in WinForms main that @Shyam-Gupta is going to take further to vet that it fixes your issue and get it through our servicing process.