clipboard integration not working for headless guest

[Evan Burkitt]

I'm using v4.1.8, but I've noticed the problem with earlier versions, at least since 4.1.4.

I have a 64-bit Windows 7 host and both Windows XP and Linux VMs. The VMs are configured for bidirectional clipboards and those work as expected when the VMs are run from the VirtualBox GUI interface: I can copy text in a guest and paste it in the host and vice versa. When I run the same VMs using "VBoxManage startvm <vm name> --headless" and connect to them via the Windows RDP client, text copied in the guest not only is not available in the host's clipboard, it's not even available in the guest's.

The attached VBox.log shows clipboard-related errors from a headless Windows XP guest. The content copied during the logged session was text from a text editor (Notepad++) on the guest.

[eblood66]

I'm seeing the same problem. My system is a Window 7 host running VirtualBox 4.2.4 r81684 with an Ubuntu 12.04 guest running Guest Additions from the same version of VirtualBox. I'm running headless with the Oracle VDRP extension installed and using Microsoft Remote Desktop to connect to the guest.

I'm attaching my log with shared_clipboard.e.l.f enabled. The very end of the log shows the messages exchanged when a copy operation (in GEdit) is performed in the guest. When the copy is made the selection in the Guest is immediately removed (which does not happen when running normally-not headless) and there is nothing on the clipboard in either the host or the guest.

The important lines in the log are these:

00:04:44.319681 svcCall: u32ClientID = 22, fn = 2, cParms = 1, pparms = 115192816
00:04:44.319717 svcCall: VBOX_SHARED_CLIPBOARD_FN_FORMATS
00:04:44.319724 svcCall: rc = VINF_SUCCESS
00:04:44.331360 vboxSvcClipboardReportMsg: Formats 01
00:04:44.331388 vboxSvcClipboardReturnMsg: Formats 01
00:04:44.331391 vboxSvcClipboardReportMsg: CallComplete
00:04:44.331644 svcCall: u32ClientID = 22, fn = 1, cParms = 2, pparms = 115526912
00:04:44.331655 svcCall: VBOX_SHARED_CLIPBOARD_FN_GET_HOST_MSG
00:04:44.331658 vboxSvcClipboardReturnMsg: no message
00:04:44.331660 svcCall: async.
00:04:44.331662 svcCall: rc = VINF_SUCCESS
00:04:44.370784 svcCall: u32ClientID = 22, fn = 3, cParms = 3, pparms = 217098880
00:04:44.370819 svcCall: VBOX_SHARED_CLIPBOARD_FN_READ_DATA
00:04:44.370825 VRDP: Guest requested clipboard format 0x00000001 that is not announced by VRDP clients. Ignoring the request!!!
00:04:44.370830 DATA: g_fDelayedAnnouncement = 0, g_u32DelayedFormats = 0x0
00:04:44.370833 svcCall: rc = VINF_SUCCESS

Based on the source code this is how I interpret is log:

1. When the copy operation is initiated in the guest the guest sends the VBOX_SHARED_CLIPBOARD_FN_FORMATS message to the host to announce that data is available on the guest clipboard. This call returns successfully.
2. vboxSvcClipboardReportMsg is immediately called on the host with the VBOX_SHARED_CLIPBOARD_HOST_MSG_FORMATS message. In the source code there only 3 places this function is called with this message for a Windows host:
   • In svcCall in service.cpp when processing VBOX_SHARED_CLIPBOARD_FN_READ_DATA when there is a delayed announcement from an extension. In this case the call should be preceded by a DATA log entry so this can't be the call.
   • In extCallback in service.cpp when processing the VBOX_CLIPBOARD_EXT_FN_FORMAT_ANNOUNCE message from an extension. In this case the call should be preceded by an ANNOUNCE log entry so this can't be the call.
   • In vboxClipboardChanged in VBoxClipboard-win.cpp which is called in response to the WM_DRAWCLIPBOARD Windows message. In this case there is no release log entry before the call so this must be the call.
3. vboxSvcClipboardReportMsg is called again.
4. The guest sends the VBOX_SHARED_CLIPBOARD_FN_READ_DATA in response to the format announcement from the VBOX_SHARED_CLIPBOARD_HOST_MSG_FORMATS message.
5. The VRDP extension complains because it never advertised this format.

I also ran Spy++ during this process and the VBoxSharedClipboardClass window in VBoxClipboard-win.cpp does receive 2 WM_DRAWCLIPBOARD messages.

I conclude from this sequence that when the guest advertises the available data, the VRDP extension passes this information back to the RDP client on the Windows host. The RDP client announces the availability of the data. The VBoxSharedClipboardClass window gets the WM_DRAWCLIPBOARD message in response to this announcement and sends a message to the guest. The guest requests the data from this announcement which is not available because it's never actually been requested from the guest which initiated the entire sequence. So the guest gets empty data which it uses to immediately replace what's on it's clipboard which in turn loses the selection that was made originally.

To further verify this (and provide a workaround for myself), I wrote a small program which simply blocks the WM_DRAWCLIPBOARD messages from getting to any Windows clipboard viewers. As soon as this program was running, the copy operation from the guest worked fine.

It seems the problem is that VBoxClipboard-win.cpp should not be monitoring the clipboard when running headless. One solution would be to save the headless status passed to the vboxClipboardConnect function and use that to prevent calls to vboxClipboardChanged when running headless.

[eblood66]

Host log with shared_clipboard logging enabled.

[vtab]

Host Win 7 64bit, guest XP SP3 32bit

I can confirm this is still an issue in VB 4.3.12 r93733. The change log for VB 4.3.14 does not list this issue as being addressed.

I use VB for software development and want to use headless mode to keep the resource requirements low on the host OS. Working with source code text and not being able to copy-and-paste within the same guest OS session makes headless mode worthless.

[Suncatcher]

Issue still exists in more recent versions.