Within the first minute of installing this build, I already got the application to crash when trying to test this. I just tried a few times to copy one of two different lines of plain text (each one with either a leading space or no leading space) to test whether duplicates are created. Although I didn't see duplicates of the text being created in the History, after about the 5th time I hit Ctrl+C, the application just crashed. I see that it did create a crashdump, but right now I don't have the time or the spare usage credits for SuperGrok to do yet another AI analysis of the cause. I still have my original Triggers enabled, because the new options are unsuitable for me.

EDIT: I got another similar crash a little later, when copying text again. Perhaps foolishly, I've just used most of my remaining Grok usage limit for this week to analyse both crashdumps. Frustratingly, I see that at least one of the issues identified in the earlier crash reports I sent earlier hasn't been addressed. Maybe I'm wasting my time running these crash analyses. Anyway, below is the latest analysis about these 2 crashdumps from Beta 9:

What the process was doing

Both UI threads are in the preview-popup hotkey:

ProcessHotKeyShowPreviewPopup → ShowClipboardContentsPopup → BeginInvokeCustomVoid → clipboard probe → ClipboardContainsAny → GetClipboardDataObjectRawTHROWS

That last method calls OleGetClipboard, and if it gets a COM object back it wraps it and calls GetFormats(). The catch blocks around this path never run. FailFast is not a catchable managed exception.

The two dumps die on the two different native calls inside that method:

• 35000 is still inside the OleGetClipboard P/Invoke (cRk.YRS+eW5K.kW5u). The clipboard owner’s IDataObject faulted while OLE was retrieving it.
• 38736 got an IDataObject back and faulted in System.Private.Windows.Ole.Composition<…>.NativeToManagedAdapter.GetFormats. The native stack under that call is the CLR COM marshaler: GetComIPFromObjectRef → IUnkEntry::GetIUnknownForCurrContext → SafeAddRef, plus ComObject::SupportsInterface / MethodTable::GetGuid. That is an AddRef or interface query on a bad or disconnected clipboard object.

dataexchange.dll, ole32.dll, and combase.dll are loaded in both. This is the Windows clipboard data-exchange path, not a ClipboardFusion-internal null dereference.

Why it kills the process

The faulting instruction is not in JIT code, so ShouldHandleManagedFault (excep.cpp:6310 in the .NET 10.0.12 runtime) does not turn it into a NullReferenceException. The access violation then reaches the managed personality routine ProcessCLRException. At exceptionhandling.cpp:621 the runtime does this:

if (IsProcessCorruptedStateException(pExceptionRecord->ExceptionCode, NULL))
EEPOLICY_HANDLE_FATAL_ERROR(pExceptionRecord->ExceptionCode);

STATUS_ACCESS_VIOLATION is a corrupted-state exception unless DOTNET_legacyCorruptedStateExceptionsPolicy is set. The runtime calls RaiseFailFastException (KERNELBASE+0x10A1A. The ExecutionEngineException on the thread is only the FailFast placeholder. The original fault address and the read/write target were not kept: the recorded exception has NumberParameters = 0, and the captured instruction pointer is RaiseFailFastException, not the instruction that faulted.

Runtime is .NET 10.0.12 (coreclr.dll 10.0.1226.4230. OS is Windows 11 build 26200, 24 processors.

What is not the crash

Three or four threads in each dump carry a BadImageFormatException ("Bad method token", 0x8007000B) with an empty stack trace. Those threads are parked in WaitHandle.WaitMultiple inside the IPC handler (Jrz.srx.StartIpcHandlerWorkerAsyncTHREAD). That object is the thread’s last exception, left over from a failed method-token lookup. It is not being thrown.

A second UI thread (0xA72C in the first dump, 0x5C90 in the second) is blocked in Lock.TryEnterSlow inside ClipboardContains, called from ShowPopupUITHREADONLY → ShowPopupFormUITHREADONLY. The preview thread holds the clipboard lock while the popup thread waits for it. That is contention, not the access violation.

Conclusion

The uiAccess process dies when the preview hotkey reads a clipboard whose OLE data object is invalid. One run faults in OleGetClipboard itself; the next faults while enumerating formats on the object it returned. .NET 10 treats that native access violation as fatal, so ClipboardFusion’s own try/catch around ClipboardContainsAny cannot save the process. The clipboard owner at the moment of the hotkey is the interesting variable: the same hotkey against an ordinary text or bitmap clipboard does not take this path into a bad IDataObject.