Shared Clipboard crashes on Ecomstation => Fixed in SVN

[FelixG]

With Ecomstation v2.1, copying and pasting text appears an error that turns off the virtual machine.

[Frank Batschulat (Oracle)]

unlikely we are going to work on this as we do not have access to this OS afaik:

​https://www.ecomstation.com/index.php/[[BR]] ​https://shop.ecomstation.com/[[BR]] ​https://shop.ecomstation.com/software-subscription-services.html

[FelixG]

I forgot to mention that with VirtualBox v5.2.26 it works perfectly. It is some modification introduced in v6.

[Frank Batschulat (Oracle)]

whether or not v5.2.26 works is anectdotal as that is a 1 year old version of the 5.2.X branch, the current version is 5.2.34

https://www.alldomusa.eu.org/wiki/Download_Old_Builds_5_2

so the interesting question would be whether or not 5.2.34 works as opposed to 6.1 or 6.0.14.

[pentagonik]

Thanks for the report -- as this is a host crash running on Windows 10, could you please try supplying a Windows Minidump as described here?

[FelixG]

Thank you for your efforts.

With v5.2.34 and the clipboard set as bi-directional:

• Host to Guest works fine.
• Guest a Host does not work, but the failure does not occur.

With v6.1 and the clipboard set as Host to Guest:

• It works well and the failure does not occur.

With v6.1 and the clipboard set as bi-directional or Guest a Host:

• It does not work, it takes a long time, and frequently the fault appears.

I attach the Process Explorer dump. WER does not generate any dump.

[pentagonik]

Great, thanks for providing the additional information. I'll have a look at this the next upcoming days.

[pentagonik]

Please have a try testing the latest test build 135515 (Development snapshots) whether this fixes the issue for you, which you can get here: Testbuilds

[FelixG]

Sorry for waiting.

In version r135515 the error no longer appears, but it still malfunctions.

As "Bi-directional" or "Guest a Host", when you paste in the guest, nothing is pasted, and in Windows 10 the copy/paste functions stop working, both with text and with files.

Changing to "Host to Guest", Windows 10 works correctly again.

[FelixG]

With virtualbox 6.1.6, windows 10 host, and OS/2 guest, the problem continues.

I have investigated, and I think the problem is that the ShClSvcHostReportFormats function is called incorrectly.

Using 'VBoxManage debugvm "virtual machine" log --release + all.e.l.f', and filtering for "clipboard":

1 copy of text in HOST->GUEST mode. (Correct result)
00:00:02.401491 Shared Clipboard: Service loaded
00:00:02.401500 Shared Clipboard: Mode: Host to Guest
00:00:02.401812 Shared Clipboard: Service running in normal mode
00:00:20.949297 Shared Clipboard: New Clipboard API enabled
00:00:22.050387 Shared Clipboard: New Clipboard API enabled
00:00:30.185343 Shared Clipboard: Reporting formats 0x1 to guest
00:00:30.186352 Shared Clipboard: Reporting formats 0x1 to guest
00:00:32.497136 shClSvcClientReadData: Shared Clipboard: DATA/Host: cbData=4096->8 rc=VINF_SUCCESS

1 copy of text in GUEST->HOST or Bidirectional mode. (Windows clipboard is locked)
00:00:02.382023 Shared Clipboard: Service loaded
00:00:02.382032 Shared Clipboard: Mode: Guest to Host (or Mode: Bidirectional)
00:00:02.382158 Shared Clipboard: Service running in normal mode
00:00:19.098377 Shared Clipboard: New Clipboard API enabled
00:00:19.102823 Shared Clipboard: Reporting formats 0x1 to guest
00:00:20.237973 Shared Clipboard: New Clipboard API enabled
00:00:20.242295 Shared Clipboard: Reporting formats 0x1 to guest
00:00:20.247324 Shared Clipboard: Reporting formats 0x1 to guest
00:00:20.249351 Shared Clipboard: Reporting formats 0x1 to guest
00:00:20.250010 Shared Clipboard: Reporting formats 0x1 to guest
00:00:20.250610 Shared Clipboard: Reporting formats 0x1 to guest
00:00:20.251270 Shared Clipboard: Reporting formats 0x1 to guest
... repeatedly and indefinitely

In GUEST->HOST mode and Bidirectional mode -without host copy-, ShClSvcHostReportFormats should not be used.

ShClSvcHostReportFormats is called by:

• shClSvcClientReadData

if (g_ExtState.pfnExtension)

if (g_ExtState.fDelayedAnnouncement)

• extCallback

if (itClient != g_mapClients.end())

case VBOX_CLIPBOARD_EXT_FN_FORMAT_ANNOUNCE:

if (!g_ExtState.fReadingData)

• vboxClipboardSvcWinSyncInternal

if (pCtx->pClient)

if (RT_SUCCESS(SharedClipboardWinGetFormats(&pCtx->Win, &Formats))

&& Formats.Formats != VBOX_SHCL_FMT_NONE)

vboxClipboardSvcWinSyncInternal is called by:

• vboxClipboardSvcWinWndProcMain

case WM_CLIPBOARDUPDATE: case WM_DRAWCLIPBOARD:

if (pWinCtx->hWndClipboardOwnerUs != hWndClipboardOwner)

• ShClSvcImplSync

ShClSvcImplSync is called by:

• svcLoadState

• svcConnect

if (RT_SUCCESS(shClSvcClientInit(pClient, u32ClientID)))

if (RT_SUCCESS(ShClSvcImplConnect(pClient, ShClSvcGetHeadless())))

extCallback is used by:

• svcRegisterExtension

if (pfnExtension)

parms.u.pfnCallback = extCallback;

svcRegisterExtension is used by:

• VBoxHGCMSvcLoad

pTable->pfnRegisterExtension = svcRegisterExtension;

shClSvcClientReadData is called by:

• svcCall

case VBOX_SHCL_GUEST_FN_DATA_READ:

I don't know how it works, but OS/2 should use a simple version of the clipboard.
I hope this data helps you find the problem.

[FelixG]

In version 6.1.12 I still have the same problem. When the guest copies text, the host sends the guest a notice of new (obviously false) data. The "ShClSvcHostReportFormats" function is called incorrectly during data transfer from Guest to Host.

Could it be necessary to use "RTCritSectEnter" inside the "SharedClipboardWinAnnounceFormats" function to avoid a "WM_CLIPBOARDUPDATE" message?

Or put "pWinCtx->hWndClipboardOwnerUs = GetClipboardOwner()" before using "SetClipboardData"?

[FelixG]

I think I have found a problem in the code:

D:\VirtualBox-6.1.18\src\VBox\HostServices\SharedClipboard\VBoxSharedClipboardSvc-win.cpp

The routine "vboxClipboardSvcWinWndProcMain" should terminate:

default:

{

LogFunc(("WM_ %p\n", uMsg));

lresultRc = DefWindowProc(hWnd, uMsg, wParam, lParam);

break;

}

}

LogFlowFunc(("LEAVE hWnd=%p, WM_ %u\n", hWnd, uMsg));

return lresultRc;

}

As it stands now, messages like "WM_CLIPBOARDUPDATE" are forwarded in a loop.

[bird]

We've taken the advice about not calling DefWindowProc for messages we handle, that will be included in the next 6.1.x release. Not quite sure why it would make a difference, but the change makes sense.

The theory proposed in comment:11 about hWndClipboardOwnerUs is not correct for two reasons:

1. hWndClipboardOwnerUs is NULL until the first SharedClipboardWinAnnounceFormats call, after that it always has the same value.
2. We're executing SharedClipboardWinAnnounceFormats from under the dispatcher loop and thus the window procedure cannot receive any posted messages till we return. If SetClipboardData caused any message to be sent, we could maybe be handling that, but AFAIK it shouldn't send anything. (We also have the clipboard open here, so nobody should be able to race us updating it.)

That said, we should probably update hWndClipboardOwnerUs when we empty the clipboard or during init, as it's unnecessary to set it every time SharedClipboardWinAnnounceFormats is called.

[FelixG]

The problem was still there, but I just found out that it was calling vboxservice 2 times. The second call caused 2 clipboard services to load at the same time, for the same virtual machine, causing the malfunction.

It is already solved, I am very sorry for the inconvenience.

[galitsyn]

Hi FelixG,

Could you please try VirtualBox 6.1.28? We have improvements in shared clipboard area there. Both VBox and Additions update is necessary.

[FelixG]

It works perfectly. And I think it goes faster (the software is old, and allows you to see the difference in speed).

Thank you very much for the solution.