VirtualBox

Ticket #19165 (closed defect: fixed)

Opened 3 years ago

Last modified 10 months ago

Shared Clipboard crashes on Ecomstation => Fixed in SVN

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 3 years ago.
Vbox.log Download (141.6 KB) - added by FelixG 3 years ago.
ProcessExplorer_MiniDumps.7z Download (351.2 KB) - added by FelixG 3 years ago.

Change History

Changed 3 years ago by FelixG

Changed 3 years ago by FelixG

comment:1 Changed 3 years ago by fbatschu

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

comment:2 Changed 3 years 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 3 years 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 3 years ago by fbatschu (previous) (diff)

comment:4 Changed 3 years 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 3 years 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 3 years ago by FelixG

comment:6 Changed 3 years ago by pentagonik

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

comment:7 Changed 3 years ago by pentagonik

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

comment:8 Changed 3 years 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 3 years ago by pentagonik (previous) (diff)

comment:9 Changed 3 years 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 2 years 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 2 years 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 18 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 15 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 14 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 12 months 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 11 months 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.

comment:17 Changed 10 months ago by galitsyn

  • Status changed from assigned to closed
  • Resolution set to fixed
  • Summary changed from Shared Clipboard crashes on Ecomstation to Shared Clipboard crashes on Ecomstation => Fixed in SVN
Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use