VirtualBox

Ticket #19165 (assigned defect)

Opened 23 months ago

Last modified 21 hours ago

Shared Clipboard crashes on Ecomstation

Reported by: FelixG Owned by: pentagonik
Component: clipboard Version: VirtualBox 6.1.0
Keywords: Cc:
Guest type: other Host type: Windows

Description

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

Attachments

VboxSharedClipboardClass_Error.png Download (10.9 KB) - added by FelixG 23 months ago.
Vbox.log Download (141.6 KB) - added by FelixG 23 months ago.
ProcessExplorer_MiniDumps.7z Download (351.2 KB) - added by FelixG 23 months ago.

Change History

Changed 23 months ago by FelixG

Changed 23 months ago by FelixG

comment:1 Changed 23 months ago by fbatschu

  • Status changed from new to awaitsfeedback
Last edited 23 months ago by fbatschu (previous) (diff)

comment:2 Changed 23 months ago by FelixG

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

comment:3 Changed 23 months ago by fbatschu

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.virtualbox.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.

Last edited 23 months ago by fbatschu (previous) (diff)

comment:4 Changed 23 months ago by 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?

comment:5 Changed 23 months ago by 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.

Changed 23 months ago by FelixG

comment:6 Changed 23 months ago by pentagonik

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

comment:7 Changed 23 months ago by pentagonik

  • Owner set to pentagonik
  • Status changed from awaitsfeedback to assigned

comment:8 Changed 23 months ago by 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

Last edited 23 months ago by pentagonik (previous) (diff)

comment:9 Changed 22 months ago by 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.

comment:10 Changed 19 months ago by 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.

comment:11 Changed 15 months ago by 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"?

comment:12 Changed 7 months ago by 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.

comment:13 Changed 4 months ago by 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.

comment:14 Changed 2 months ago by 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.

comment:15 Changed 7 days ago by 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.

comment:16 Changed 21 hours ago by 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.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use