Windows: clipboard changes stop being detected until CrossPaste is restarted (v2.1.4)

[roukmoute]

Description

On CrossPaste v2.1.4 on Windows, CrossPaste sometimes stops detecting new clipboard changes.

When this happens, CrossPaste no longer seems to take new copied content into account. In particular, the CrossPaste search/history window does not show or use the latest content that was just copied.

I am not fully sure what triggers it. It may happen after the computer wakes from hibernation/sleep, but I have not confirmed that this is the exact cause.

Quitting CrossPaste and starting it again immediately fixes the issue, and newly copied content is detected again.

Can you reproduce the bug?

Sometimes

Reproduction Steps

No response

Version

v2.1.4

OS

Windows 11

[guiyanakuang]

Thanks for the report.

I may have reproduced something similar locally: when the search window opens, it doesn't always scroll to the newest entry, so the latest copied content is recorded but isn't shown at the top — which can look like nothing was captured.

Could you confirm one thing next time it happens? Open the search window and type the text you just copied into the search box:

• If it shows up → the clipboard was recorded, and this is the scroll/display issue I'm looking into.
• If it doesn't → it's a real detection problem and I'll investigate that path instead.

Thanks for helping narrow it down.

[guiyanakuang]

Hi @roukmoute, thanks again for the detailed report — an update on this.

We've merged #4606, which migrates CrossPaste's Windows clipboard monitoring from the legacy SetClipboardViewer API to the modern AddClipboardFormatListener API that Microsoft recommends for Vista and later.

The legacy API relies on an application-maintained clipboard viewer chain: every clipboard app in the chain must forward notifications to the next link, so a single misbehaving or crashed clipboard application silently breaks the chain, and CrossPaste stops receiving clipboard change notifications until it is restarted — which matches the symptoms you described. Events like waking from sleep/hibernation can also disturb apps in the chain, which would explain why it seemed related.

With AddClipboardFormatListener, Windows itself maintains the listener list and each subscriber is independent, so this entire failure class is removed.

The fix will be included in the next release. I'll leave this issue open until then — once you've updated, please let us know if the problem still occurs.