WinBox 4.1 clipboard listener causes Excel "clipboard in use by another application" errors on Windows 11 — anyone else?
Spent a few hours diagnosing this today and want to see if others are hitting it.
**Symptom:** Excel 365 on Windows 11 throws the "We couldn't copy the content to the clipboard because it's in use by another application" popup constantly during normal copy/paste work. Happens many times an hour during heavy Excel use.
**Setup:**
- Windows 11 Enterprise 23H2
- Excel 365 (current channel)
- WinBox 4.1 on Windows (the Qt-based cross-platform build)
- typically 4-8 WinBox windows open simultaneously for management work
**Diagnostic approach:** Wrote a PowerShell polling script using `GetOpenClipboardWindow()` that logs which process holds the clipboard every 50ms. Ran it during normal work for a few hours.
**What I found:** WinBox 4.1 dominates the clipboard-hold log. Each open WinBox window appears to install its own clipboard listener (Qt's `QClipboard` behavior) that briefly opens the clipboard whenever anything system-wide changes. With multiple WinBox sessions open, the listeners race each other and race Excel.
Example collision pattern from my log (timestamps in HH:MM:SS.ms):
```
09:24:35.249 EXCEL.EXE grabs clipboard
09:24:35.427 WinBox grabs it 178ms later
```
```
09:26:46.023 EXCEL.EXE
09:26:46.123 WinBox 100ms later
09:26:46.391 explorer
09:26:46.544 WinBox (different PID)
```
Excel writes multiple clipboard formats sequentially (text, RTF, HTML, biff, OLE). When WinBox's Qt listener interrupts mid-write, Excel can't complete the write atomically and throws the popup.
**Confirmation:** Closing all WinBox windows eliminates the errors immediately. Reopening multiple WinBox sessions brings them back.
**Things I ruled out first** (so people don't suggest them):
- Not malware (Bitdefender + Malwarebytes scans clean)
- Not Logi Options+ (disabled, errors persist with WinBox running)
- Not StreamFab clipboard monitor (disabled)
- Not Excel Live Preview (disabled)
- Not Adobe Acrobat COM add-in (disabled)
- Not the known Windows 11/Office 365 Microsoft bug alone — that contributes baseline residue, but WinBox is the proximate trigger for my specific high-rate failures
**Workaround:** Close WinBox windows when doing heavy Excel work. Not great when you're managing a fleet.
**Questions for the community:**
Anyone else on a seeing this with WinBox 4.1?
Workarounds beyond "close WinBox"?
Will post the PowerShell diagnostic script in a comment if anyone wants to verify on their setup.
*Edit: also reporting this on forum.mikrotik.com for visibility with MT staff.*