Windows 10 VM on Mac 10.15.7 Catalina crashes when clipboard enabled

[nfjanette]

Something broke starting about one year ago - having the clipboard enabled leads to crashes within 24 hours of starting the VMs. Disabling the clipboard makes the VM completely stable. Upgrading to latest OS and VB releases did not change the behavior.

Process: VirtualBoxVM [1449] Path: /Applications/VirtualBox.app/Contents/Resources/VirtualBoxVM.app/Contents/MacOS/VirtualBoxVM Identifier: VirtualBoxVM Version: 6.1.36 (6.1.36) Code Type: X86-64 (Native) Parent Process: VBoxSVC [1443] Responsible: VirtualBox [1439] User ID: 502

Date/Time: 2022-08-22 22:57:21.383 -0400 OS Version: Mac OS X 10.15.7 (19H2026) Report Version: 12 Bridge OS Version: 6.6 (19P6064) Anonymous UUID: A811DB67-BC10-7168-DD2A-D1DFFC1A784E

Time Awake Since Boot: 46000 seconds

System Integrity Protection: enabled

Crashed Thread: 10 SHCLIP

Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY

[nfjanette]

Crash log

[fth0]

To me, the crash log information sounds like the issue could have to do with the clipboard contents. Did you copy something to the clipboard (on the host or in the guest) shortly before the crash that is different from what you copied before?

[nfjanette]

No activity on the clipboard when the VM crashed - it happened when I was away from the system. I did not use the clipboard to transfer from the VM to the host system at all since startup.

[nfjanette]

Only clipboard use was within the VM Windows session and it was simple, short text.

[fth0]

Ok, then my idea is probably a dead end.

Note however, that I only talked about copying, not about pasting. For example, an accidental Ctrl-C key press on the host or in the guest would qualify as "copying something to the clipboard".

If you still have the corresponding VBox.log file, we could be lucky to find an indication of something unusual in there.

[nfjanette]

Added requested log.

[nfjanette]

Based on another ticket, I've run this command to se if it improves the stability: VBoxManage setextradata "Win 10 Pro" GUI/HidLedsSync 0

[fth0]

Several hours before the crash, there is an unexpected log message during the keyboard/mouse focus out events:

03:52:48.385159 GUI: Machine-window #0 deactivated
03:52:48.385197 GUI: Releasing mouse on focus out
03:52:48.385260 DarwinDisableGlobalHotKeys: Unexpected enmMode=3  <--
03:52:48.385277 GUI: Releasing keyboard on focus out
03:52:48.385313 DarwinDisableGlobalHotKeys: Unexpected enmMode=3  <--
03:52:48.385380 GUI: Machine-view #0 unfocused, reason=3

Visiting the VirtualBox source code and a quick Google search didn't reveal what the value "3" could mean.

Besides disabling the HID led synchronization, you could provide 2 vCPUs to the VM. This usually doesn't hurt, and modern OSes aren't optimized for single core CPUs.

[nfjanette]

Disabling the HID led synchronization seems to have helped - no VM crashes, including with clipboard enabled and used.