Clipboard.SetDataObject randomly fails with CLIPBRD_E_CANT_OPEN

[RussKie]

Problem description:

The tests that exercise Clipboard randomly fail on my computer with CLIPBRD_E_CANT_OPEN (0x800401D0) in either of these two points:

winforms/src/System.Windows.Forms/src/System/Windows/Forms/Clipboard.cs

Lines 124 to 168 in 8aeaa41

	HRESULT hr;
	int retry = retryTimes;
	do
	{
	if (data is IComDataObject ido)
	{
	hr = Ole32.OleSetClipboard(ido);
	}
	else
	{
	hr = Ole32.OleSetClipboard(dataObject);
	}
	if (hr != HRESULT.S_OK)
	{
	if (retry == 0)
	{
	throw new ExternalException(SR.ClipboardOperationFailed, (int)hr);
	}
	retry--;
	Thread.Sleep(millisecondsTimeout: retryDelay);
	}
	}
	while (hr != 0);
	if (copy)
	{
	retry = retryTimes;
	do
	{
	hr = Ole32.OleFlushClipboard();
	if (hr != HRESULT.S_OK)
	{
	if (retry == 0)
	{
	throw new ExternalException(SR.ClipboardOperationFailed, (int)hr);
	}
	retry--;
	Thread.Sleep(millisecondsTimeout: retryDelay);
	}
	}
	while (hr != 0);
	}

I struggle to make any logical conclusions about a cause. There seemed to be other reports from people suffering from similar issues (e.g. ColinDabritz/PoeItemAnalyzer#1, https://stackoverflow.com/q/68666/2338036)

Expected behavior:

The code is resilient.

[RussKie]

I've written a test harness (borrowed from https://stackoverflow.com/a/21311270/2338036), but I was unable to catch anything with it:

        public void Clipboard_SetDataObject_InvokeObjectBoolIntIntNotIComDataObject_GetReturnsExpected(object data, bool copy, int retryTimes, int retryDelay)
        {
            try
            {
                Clipboard.SetDataObject(data, copy, retryTimes, retryDelay);

                Assert.Equal(data, Clipboard.GetDataObject().GetData(data.GetType()));
                Assert.True(Clipboard.ContainsData(data.GetType().FullName));
            }
            catch (System.Runtime.InteropServices.ExternalException ex)
            {
                Process p = ProcessHoldingClipboard();
                if (p != null)
                {
                    throw new Exception($"Clipboard blocked with '{ex.ErrorCode}' reason, process pid:{p.Id} {p.ProcessName}");
                }
                else
                {
                    throw;
                }
            }
        }

        [DllImport("User32.dll", ExactSpelling = true, SetLastError = true)]
        private static extern IntPtr GetOpenClipboardWindow();

        private Process ProcessHoldingClipboard()
        {
            Process theProc = null;

            IntPtr hwnd = GetOpenClipboardWindow();

            if (hwnd != IntPtr.Zero)
            {
                uint processId;
                uint threadId = Interop.User32.GetWindowThreadProcessId(hwnd, out processId);

                Process[] procs = Process.GetProcesses();
                foreach (Process proc in procs)
                {
                    IntPtr handle = proc.MainWindowHandle;

                    if (handle == hwnd)
                    {
                        theProc = proc;
                    }
                    else if (processId == proc.Id)
                    {
                        theProc = proc;
                    }
                }
            }

            return theProc;
        }

[RussKie]

@JeremyKuhne @weltkante any thoughts?

[weltkante]

The linked stackoverflow article makes sense. Personally I never have seen this behavior, I suspect it depends on 3rd party software running on your machine, perhaps its badly behaving by keeping the clipboard open for too long instead of immediately performing its operation and closing it.

The tests that exercise Clipboard randomly fail on my computer

What is the rate of failure? If its regular enough you could close 3rd party software and try to figure out whos fault it might be.

Its probably gonna be hard to figure out via debugging since this is cross process, it probably would need a kernel debugger to capture the whole OLE/clipboard state in a dump to examine, something beyond my level of expertise.

I don't have any other idea than trying to identify which application is handling the clipboard badly. Except maybe you could fine tune the loop to make it even more resilient, but if another application is behaving badly and keeping the clipboard open over several seconds this won't help.

[RussKie]

What is the rate of failure? If its regular enough you could close 3rd party software and try to figure out whos fault it might be.

It is failing quite consistently. The challenge is to figure out what that software is :) I don't run any clipboard managers... Other than 1Password I run a pretty vanilla dev build - VS, Office, Teams

[danmoseley]

Would it help to leave Spy++ running? Is been a long time since I used it.
https://docs.microsoft.com/en-us/visualstudio/debugger/spy-increment-help?view=vs-2019

@JeremyKuhne

[JeremyKuhne]

I'd add the check directly to the code under an assert to try and track it down. Note that you shouldn't have to walk for the matching process, Process has Process.GetProcessById().

[JeremyKuhne]

@Tanya-Solyanik suggests that there is a timeout between repeated calls, which would be worth investigating.

[RussKie]

I'm no longer observing the issue. I think this was addressed in #3276.