VBoxTray.exe using excessive CPU

[pansophysr]

Windows 10 Host running Widows Guests. Problem started after upgrading to 5.0.18 and installing the GAs. Problem remained after upgrading to 5.0.20.

Symptom is that apps running in the guest get very sluggish. Sometimes slide bars are unresponsive. Menu pull downs always open the first selection. Symptoms appear several minutes after VM is started, but once VBoxTray.exe starts eating the CPU, it does not disappear.

Started thread in forums at: ​https://forums.virtualbox.org/viewtopic.php?f=2&t=77784

mpack suggested going back to 5.0.16 after just installing 5.0.16 GAs did not fix problem.

Problem does not appear when running 5.0.16 with the 5.0.16 GAs

[pansophysr]

CPU usage VBox Tray

[pansophysr]

Log File

[kris.1024]

I have a similar issue on VB version: 5.1.26 r117224 on Windows 10 with all updates.

Guest is running Windows 7 with newest GA.

I noticed something strange though, regarding a mouse. It seems like the cursor is switching very fast (mb 30 times per second?) between a cursor used when typing in a text field and a regular white mouse pointer/arrow. What's more, it seems to be also clicking by itself without pressing a left mouse button. So when this bug happens it's enough to hover over clickable button to have that button clicked. For example, I was able to hover over shutdown button and shutdown the VM completely - without clicking the button at all.

Issue happens for me every 2-3 days of 10 h usage per day. I did not notice anything specific just before issue happens.

[MikaelG]

I concur with kris.1024, I have similar issue with same VB version. Running a Windows 10 guest on a windows 10 host. My colleagues also have the same issue. We have created a command file with these two lines:

"taskkill /F /IM VBoxTray.exe

start C:\Windows\System32\VBoxTray.exe"

Executing the command file on the guest, solves the issue for a time.

Replying to kris.1024:

I have a similar issue on VB version: 5.1.26 r117224 on Windows 10 with all updates.

Guest is running Windows 7 with newest GA.

I noticed something strange though, regarding a mouse. It seems like the cursor is switching very fast (mb 30 times per second?) between a cursor used when typing in a text field and a regular white mouse pointer/arrow. What's more, it seems to be also clicking by itself without pressing a left mouse button. So when this bug happens it's enough to hover over clickable button to have that button clicked. For example, I was able to hover over shutdown button and shutdown the VM completely - without clicking the button at all.

Issue happens for me every 2-3 days of 10 h usage per day. I did not notice anything specific just before issue happens.

[roadworrier]

I'm having the same problem with the latest Virtualbox (downloaded today -- Version 5.1.28 r117968 (Qt5.6.2)) . Thanks to MikaelG for the task killer batch file, it solves my problem when the VM becomes unusable because of the VBoxTray. The Virtualbox host machine is Windows 10, the client/guest is Windows 7.

[CH1414]

I'm having the same issue with Virtual Box 5.1.24. Host W7 Pro 64 bit Clients: W7 Ultimate 32 bit, W10 pro 64 bit. Killing the vboxtray process in task manager and restarting it from the command line helps but is annoying.

[tsobaone]

The issue is still there after years be there. Can we please get this fixed?

I've created dump of vboxtray.exe (5.1.26.0) when it was running high CPU (​memory dump). I tried profiling with procmon.exe but it shows none accessing resources, only creating and destroying threads. Cycling through this:

19:19:49.2333156	VBoxTray.exe	2336	Thread Create		SUCCESS	Thread ID: 3528
19:19:49.2335115	VBoxTray.exe	2336	Thread Exit		SUCCESS	Thread ID: 3528, User Time: 0.0000000, Kernel Time: 0.0000000
19:19:49.2335532	VBoxTray.exe	2336	Thread Create		SUCCESS	Thread ID: 4584
19:19:49.2337003	VBoxTray.exe	2336	Thread Exit		SUCCESS	Thread ID: 4584, User Time: 0.0000000, Kernel Time: 0.0000000
19:19:50.1346624	VBoxTray.exe	2336	Process Profiling		SUCCESS	User Time: 559.0625000 seconds, Kernel Time: 2797.8906250 seconds, Private Bytes: 2,359,296, Working Set: 60,379,136
19:19:51.1346051	VBoxTray.exe	2336	Process Profiling		SUCCESS	User Time: 559.2031250 seconds, Kernel Time: 2798.4375000 seconds, Private Bytes: 2,359,296, Working Set: 60,379,136
19:19:52.1345663	VBoxTray.exe	2336	Process Profiling		SUCCESS	User Time: 559.2812500 seconds, Kernel Time: 2799.1093750 seconds, Private Bytes: 2,359,296, Working Set: 60,379,136
19:19:53.1347230	VBoxTray.exe	2336	Process Profiling		SUCCESS	User Time: 559.4062500 seconds, Kernel Time: 2799.7031250 seconds, Private Bytes: 2,359,296, Working Set: 60,379,136
19:19:54.1348474	VBoxTray.exe	2336	Process Profiling		SUCCESS	User Time: 559.5468750 seconds, Kernel Time: 2800.3281250 seconds, Private Bytes: 2,359,296, Working Set: 60,379,136

Hopefully it does not run bitcoin mining or so.

[Max Fedotov]

Same issue in 5.2.6 (Windows 10 guest)

[Thomas B.]

Confirm: Problem still exists in 5.2.6.

I found out that at high CPU-usage on Host the problem happens more often.

When VBoxTray.exe has high CPU load then the Windows-Client becomes almost completely unresponsive, because of long delays - killing VBoxTray.exe is very hard to achieve then. I see that problem on my Windows 7 32 Bit Client at least every second day, often even multiple times per day.

Maybe it is important to note, that i disabled graphics-acceleration (2D and 3D) for the client because of problems (at least in past) with multiple GPU's (AMD and Intel) and usage of multiple monitors on Host, as this seems not to be a usual case. I also enabled the bidirectional clipboard what also seems not to be the default.

This problem should have highest priority of all actual problems, because "using a client" should be the main-goal of VirtualBox in my opinion.

EDIT: Even with disabled clipboard-exchange the problem happens.

[Socratis]

@Thomas B.

1. Your client *is* running, so it's not the highest priority issue. If this problem would delete files, especially from your host, *that* would be a high priority issue ;)

2. Not a lot of people are seeing this behavior, it's not easily reproducible (and I'm not talking about you, I'm talking on a freshly installed system). The question is to find the common denominator/culprit that might be causing this.

3. If your guest becomes completely unresponsive, make sure that you haven't assigned all your CPUs to your guest. And I'm not talking about "threads", I'm talking about "cores". Open a VBox.log and search for "Physical host cores" to see how many you actually have.

[BigEdSaxMan]

I am having the same exact problem. It's my workstation for work, that is virtualized, so it's affecting me big time. It is also 32 bit Windows 7. It took me a while to figure out that it was the VBoxTray.exe because the guest becomes mostly unresponsive (two minutes between mouse clicks or keystrokes to respond). My workaround for now is killing VBoxTray.exe and leaving it off.

This does not affect the host machine in any way, only the guest.

Let me know what I need to provide here to help diagnose this.

Thanks!!!

[nikN]

I see this too.

Oracle Linux 7 (OBI) Windows 10 (OBI)

I am not able to trace anything.

I re-installed the guest additions CD, made no difference.

I cannot put my finger on why tray app is suddenly "racing" but it will always start after about 1/2 hour after I boot.

I kill using task manager but then Copy/Paste into and out of the host fails. Strange thing is that It will start "racing" even if I have not done a copy/paste action since boot.

[Rusty_37]

This is happening to me also, I have captured a dump file on the process, but even compressed it is 14 Mb, how can I upload the file?

[Rusty_37]

ok, crash dump is like this

 Analysis Summary  
  Type Description Recommendation 
  Information 
DebugDiag did not detect any known problems in VBoxTray.DMP using the current set of scripts.


 


 

Table Of Contents
VBoxTray.DMP

   Top 5 threads by CPU time

   Thread report

   Well-Known COM STA Threads Report



 Report for VBoxTray.DMP



 Report for VBoxTray.DMP
Type of Analysis Performed   Hang Analysis 
Machine Name   PC 
Operating System   Windows 7 Service Pack 1 
Number Of Processors   2 
Process ID   4120 
Process Image   C:\Windows\System32\VBoxTray.exe 
System Up-Time   1 day(s) 01:24:40 
Process Up-Time   21:10:38 



Top 5 Threads by CPU time
Note - Times include both user mode and kernel mode for each thread Thread ID: 9     Total CPU Time: 00:00:55.203     Entry Point for Thread: 0x00000000 
Thread ID: 8     Total CPU Time: 00:00:12.999     Entry Point for Thread: 0x00000000 
Thread ID: 6     Total CPU Time: 00:00:01.781     Entry Point for Thread: 0x00000000 
Thread ID: 0     Total CPU Time: 00:00:00.015     Entry Point for Thread: 0x00000000 
Thread ID: 4     Total CPU Time: 00:00:00.00     Entry Point for Thread: 0x00000000 





Thread report

Thread 0 - System ID 4124
Entry point   0x00000000 
Create time   24/04/2018 13:04:56 
Time spent in user mode   0 Days 00:00:00.00 
Time spent in kernel mode   0 Days 00:00:00.015 




This thread is not fully resolved and may or may not be a problem. Further analysis of these threads may be required.



Function 
ntdll!KiFastSystemCallRet 
ntdll!ZwWaitForMultipleObjects+c 
KERNELBASE!WaitForMultipleObjectsEx+100 
kernel32!WaitForMultipleObjectsExImplementation+e0 
user32!RealMsgWaitForMultipleObjectsEx+13c 
VBoxTray!RTCString::substr+382 
VBoxTray!RTCString::substr+8f1 
VBoxTray!RTSemEventRemoveSignaller+91ae 
kernel32!BaseThreadInitThunk+e 
ntdll!__RtlUserThreadStart+70 
ntdll!_RtlUserThreadStart+1b 




Back to Top 


Thread 1 - System ID 4128
Entry point   0x00000000 
Create time   24/04/2018 13:04:57 
Time spent in user mode   0 Days 00:00:00.00 
Time spent in kernel mode   0 Days 00:00:00.00 




Function 
ntdll!KiFastSystemCallRet 
ntdll!ZwWaitForMultipleObjects+c 
ntdll!TppWaiterpThread+32e 
kernel32!BaseThreadInitThunk+e 
ntdll!__RtlUserThreadStart+70 
ntdll!_RtlUserThreadStart+1b 




Back to Top 


Thread 2 - System ID 4136
Entry point   0x00000000 
Create time   24/04/2018 13:04:57 
Time spent in user mode   0 Days 00:00:00.00 
Time spent in kernel mode   0 Days 00:00:00.00 




This thread is not fully resolved and may or may not be a problem. Further analysis of these threads may be required.



Function 
ntdll!KiFastSystemCallRet 
ntdll!NtDeviceIoControlFile+c 
KERNELBASE!DeviceIoControl+f6 
kernel32!DeviceIoControlImplementation+80 
VBoxTray!RTUtf16End+1da 
VBoxTray!RTUtf16End+45b 
VBoxTray!RTSemEventRemoveSignaller+e83 
VBoxTray!RTCString::copyFromN+218 
VBoxTray!RTThreadFromNative+123 
VBoxTray!RTThreadYield+2b6 
VBoxTray!RTUtf16End+5812 
VBoxTray!RTUtf16End+589c 
kernel32!BaseThreadInitThunk+e 
ntdll!__RtlUserThreadStart+70 
ntdll!_RtlUserThreadStart+1b 




Back to Top 


Thread 3 - System ID 4140
Entry point   0x00000000 
Create time   24/04/2018 13:04:57 
Time spent in user mode   0 Days 00:00:00.00 
Time spent in kernel mode   0 Days 00:00:00.00 




This thread is not fully resolved and may or may not be a problem. Further analysis of these threads may be required.



Function 
ntdll!KiFastSystemCallRet 
ntdll!NtDeviceIoControlFile+c 
KERNELBASE!DeviceIoControl+f6 
kernel32!DeviceIoControlImplementation+80 
VBoxTray!RTUtf16End+1da 
VBoxTray!RTUtf16End+5515 
VBoxTray!RTUtf16End+54b 
VBoxTray!RTCString::substr+3451 
VBoxTray!RTCString::copyFromN+218 
VBoxTray!RTThreadFromNative+123 
VBoxTray!RTThreadYield+2b6 
VBoxTray!RTUtf16End+5812 
VBoxTray!RTUtf16End+589c 
kernel32!BaseThreadInitThunk+e 
ntdll!__RtlUserThreadStart+70 
ntdll!_RtlUserThreadStart+1b 




Back to Top 


Thread 4 - System ID 4144
Entry point   0x00000000 
Create time   24/04/2018 13:04:57 
Time spent in user mode   0 Days 00:00:00.00 
Time spent in kernel mode   0 Days 00:00:00.00 




This thread is not fully resolved and may or may not be a problem. Further analysis of these threads may be required.



Function 
ntdll!KiFastSystemCallRet 
ntdll!NtDeviceIoControlFile+c 
KERNELBASE!DeviceIoControl+f6 
kernel32!DeviceIoControlImplementation+80 
VBoxTray!RTUtf16End+1da 
VBoxTray!RTUtf16End+45b 
VBoxTray!RTCString::substr+2f07 
VBoxTray!RTCString::copyFromN+218 
VBoxTray!RTThreadFromNative+123 
VBoxTray!RTThreadYield+2b6 
VBoxTray!RTUtf16End+5812 
VBoxTray!RTUtf16End+589c 
kernel32!BaseThreadInitThunk+e 
ntdll!__RtlUserThreadStart+70 
ntdll!_RtlUserThreadStart+1b 




Back to Top 


Thread 5 - System ID 4148
Entry point   0x00000000 
Create time   24/04/2018 13:04:57 
Time spent in user mode   0 Days 00:00:00.00 
Time spent in kernel mode   0 Days 00:00:00.00 




This thread is not fully resolved and may or may not be a problem. Further analysis of these threads may be required.



Function 
ntdll!KiFastSystemCallRet 
ntdll!NtDeviceIoControlFile+c 
KERNELBASE!DeviceIoControl+f6 
kernel32!DeviceIoControlImplementation+80 
VBoxTray!RTUtf16End+1da 
VBoxTray!RTUtf16End+45b 
VBoxTray!RTSemEventRemoveSignaller+144b 
VBoxTray!RTCString::copyFromN+218 
VBoxTray!RTThreadFromNative+123 
VBoxTray!RTThreadYield+2b6 
VBoxTray!RTUtf16End+5812 
VBoxTray!RTUtf16End+589c 
kernel32!BaseThreadInitThunk+e 
ntdll!__RtlUserThreadStart+70 
ntdll!_RtlUserThreadStart+1b 




Back to Top 


Thread 6 - System ID 4156
Entry point   0x00000000 
Create time   24/04/2018 13:04:57 
Time spent in user mode   0 Days 00:00:00.156 
Time spent in kernel mode   0 Days 00:00:01.625 




This thread is not fully resolved and may or may not be a problem. Further analysis of these threads may be required.



Function 
ntdll!KiFastSystemCallRet 
ntdll!ZwWaitForSingleObject+c 
KERNELBASE!WaitForSingleObjectEx+98 
kernel32!WaitForSingleObjectExImplementation+75 
kernel32!WaitForSingleObject+12 
VBoxTray!RTLocalIpcServerListen+b8 
VBoxTray!RTSemEventRemoveSignaller+1cba 
VBoxTray!RTCString::copyFromN+218 
VBoxTray!RTThreadFromNative+123 
VBoxTray!RTThreadYield+2b6 
VBoxTray!RTUtf16End+5812 
VBoxTray!RTUtf16End+589c 
kernel32!BaseThreadInitThunk+e 
ntdll!__RtlUserThreadStart+70 
ntdll!_RtlUserThreadStart+1b 




Back to Top 


Thread 7 - System ID 4160
Entry point   0x00000000 
Create time   24/04/2018 13:04:57 
Time spent in user mode   0 Days 00:00:00.00 
Time spent in kernel mode   0 Days 00:00:00.00 




This thread is not fully resolved and may or may not be a problem. Further analysis of these threads may be required.



Function 
ntdll!KiFastSystemCallRet 
ntdll!NtDelayExecution+c 
KERNELBASE!SleepEx+65 
KERNELBASE!Sleep+f 
VBoxTray!RTThreadSleepNoLog+d 
VBoxTray!RTSemEventRemoveSignaller+772b 
VBoxTray!RTCString::copyFromN+218 
VBoxTray!RTThreadFromNative+123 
VBoxTray!RTThreadYield+2b6 
VBoxTray!RTUtf16End+5812 
VBoxTray!RTUtf16End+589c 
kernel32!BaseThreadInitThunk+e 
ntdll!__RtlUserThreadStart+70 
ntdll!_RtlUserThreadStart+1b 




Back to Top 


Thread 8 - System ID 4164
Entry point   0x00000000 
Create time   24/04/2018 13:04:57 
Time spent in user mode   0 Days 00:00:00.796 
Time spent in kernel mode   0 Days 00:00:12.203 




This thread is not fully resolved and may or may not be a problem. Further analysis of these threads may be required.



Function 
ntdll!KiFastSystemCallRet 
user32!NtUserShowWindow+c 
VBoxTray!RTSemEventRemoveSignaller+38c3 
VBoxTray!RTSemEventRemoveSignaller+3f75 
VBoxTray!RTSemEventRemoveSignaller+4075 
user32!InternalCallWinProc+23 
user32!UserCallWinProcCheckWow+14b 
user32!DispatchMessageWorker+357 
user32!DispatchMessageA+f 
VBoxTray!RTSemEventRemoveSignaller+42af 
VBoxTray!RTThreadFromNative+123 
VBoxTray!RTThreadYield+2b6 
VBoxTray!RTUtf16End+5812 
VBoxTray!RTUtf16End+589c 
kernel32!BaseThreadInitThunk+e 
ntdll!__RtlUserThreadStart+70 
ntdll!_RtlUserThreadStart+1b 




Back to Top 


Thread 9 - System ID 4176
Entry point   0x00000000 
Create time   24/04/2018 13:04:57 
Time spent in user mode   0 Days 00:00:02.875 
Time spent in kernel mode   0 Days 00:00:52.328 




This thread is not fully resolved and may or may not be a problem. Further analysis of these threads may be required.



Function 
ntdll!KiFastSystemCallRet 
ntdll!NtDeviceIoControlFile+c 
KERNELBASE!DeviceIoControl+f6 
kernel32!DeviceIoControlImplementation+80 
VBoxTray!RTUtf16End+1da 
VBoxTray!RTUtf16End+5515 
VBoxTray!RTUtf16End+11b0 
VBoxTray!RTUtf16End+3d90 
VBoxTray!RTSemEventRemoveSignaller+2cda 
VBoxTray!RTCString::copyFromN+218 
VBoxTray!RTThreadFromNative+123 
VBoxTray!RTThreadYield+2b6 
VBoxTray!RTUtf16End+5812 
VBoxTray!RTUtf16End+589c 
kernel32!BaseThreadInitThunk+e 
ntdll!__RtlUserThreadStart+70 
ntdll!_RtlUserThreadStart+1b 




Back to Top 


Thread 10 - System ID 4660
Entry point   0x00000000 
Create time   24/04/2018 13:05:27 
Time spent in user mode   0 Days 00:00:00.00 
Time spent in kernel mode   0 Days 00:00:00.00 




Function 
ntdll!KiFastSystemCallRet 
ntdll!NtWaitForWorkViaWorkerFactory+c 
ntdll!TppWorkerThread+209 
kernel32!BaseThreadInitThunk+e 
ntdll!__RtlUserThreadStart+70 
ntdll!_RtlUserThreadStart+1b 




Back to Top 


Thread 11 - System ID 4692
Entry point   0x00000000 
Create time   25/04/2018 10:13:26 
Time spent in user mode   0 Days 00:00:00.00 
Time spent in kernel mode   0 Days 00:00:00.00 




Function 
ntdll!KiFastSystemCallRet 
ntdll!NtWaitForWorkViaWorkerFactory+c 
ntdll!TppWorkerThread+209 
kernel32!BaseThreadInitThunk+e 
ntdll!__RtlUserThreadStart+70 
ntdll!_RtlUserThreadStart+1b 




Back to Top 


Thread 12 - System ID 4768
Entry point   0x00000000 
Create time   25/04/2018 10:14:56 
Time spent in user mode   0 Days 00:00:00.00 
Time spent in kernel mode   0 Days 00:00:00.00 




Function 
ntdll!KiFastSystemCallRet 
ntdll!NtWaitForWorkViaWorkerFactory+c 
ntdll!TppWorkerThread+209 
kernel32!BaseThreadInitThunk+e 
ntdll!__RtlUserThreadStart+70 
ntdll!_RtlUserThreadStart+1b 




Back to Top 

Well-Known COM STA Threads Report
STA Name    Thread ID    Thread Status    Call Status 

 Main STA    0 In-Call (bad symbols)    not fully resolved and may or may not be a problem. Further analysis of this thread may be required 

 
 
 


 
 Script Summary  
  Script Name Status Error Code Error Source Error Description Source Line 
CrashHangAnalysis.asp Completed   
 

[danielc2]

I have been having the same problem for a while. Following this ticket. Too bad this has been open for 2 years without resolution!

[Socratis]

Replying to danielc2:

Too bad this has been open for 2 years without resolution

Well, they have older issues to address (#33), so don't feel left out. ;)
And the fact that not everyone sees (and mainly the developers) doesn't help either...

[Kobbema]

I have WindowsXP on a Windows10 laptop, running VirtualBox 5.2.12, with memory: host 8Gb, VM 2Gb.

I installed some software and expected a more heavy load, so I increased the memory to 3Gb. The result was that VboxTray used >95% of cpu. I scaled the memory back to 2Gb and VboxTray was quiet again.

[Daniel Miller]

Me and everyone at my organization are seeing this issue with VBoxTray CPU usage which ends up making the guest and finally the virtualbox app itself completely unresponsive. We've got homegrown solutions popping up to kill off the tray exe occasionally. Anecdotally, it seems it often happens when a lot of content is put in the clipboard. Some users seem to be able to repeat fairly reliably by attempting drag/drop of files between host and guest. I don't like to "me too" bug reports without providing valuable new information, but it seems like there may be a perception that not many people see this error. They do. As I talk to colleagues and other professionals in my industry, I've started hearing a common thing, that people are switching to Windows HyperV instead of Virtual Box because of the instability of Windows 10 (i'm not sure this assumption it is only a Windows 10 issue is correct) guests in Virtual Box.

[mrblobby]

Same issue: Ubuntu 16.04.4 LTS Host 64Bit, Win7SP1 Guest 64bit. 2 (of 8) cores allocated, 6G Ram (of 16). Issue only seen when using Seamless mode. Win7 becomes unresponsive, Guest cursor flickers/changes rapidly (as though getting continued mouse click entries/responses). Unable to stop this behaviour once active unless (already opened task manager and) kill vboxtray.exe. Makes Guest useless.

[mrblobby]

SOrry, should have said running VBox Version 5.2.8 r121009

[Mihai Hanor]

I can reproduce a situation where VBoxTray hogs the CPU, by dragging a file over the screen area of an Windows 7 64 bit VM, 2 or 3 times, in fast succession. Host Windows 10 1709 64 bit. The logs are for a debug build.

drive.google.com/open?id=1KetGq7H0UUI317cmwuud02wCBAFditNo

[Markus Schaber]

I have the same problem, in a Windows 10 Guest, MacOS host. The guest is configured with 3072MB RAM and 2 cores.

Apart from the VBox Tray app, the desktop window manager also uses up lots of CPU. Both symptoms disappear when killing the VBox Tray app, and restarting it.

AS I happen to have dev tools (VS 2015 etc) within the VM, is there anything I can do to gather more information?

[Rusty_37]

"I can reproduce a situation where VBoxTray hogs the CPU, by dragging a file over the screen area of an Windows 7 64 bit VM, 2 or 3 times, in fast succession. Host Windows 10 1709 64 bit. The logs are for a debug build.

drive.google.com/open?id=1KetGq7H0UUI317cmwuud02wCBAFditNo"

I agree, this reproduces it for me also, VM is windows 10, main machine Ubuntu 18:04 LTS VBox version 5.2.12

[sowens]

I can confirm that the problem is reproducible on Linux Mint 18.3, running VBox 5.2.12 r122591. Dragging a file over the virtual machine 2-3 times will cause a spike in vboxtray application after a couple of seconds and vboxtray never recovers.

[Lorenzo G]

Same problem for me. It happened recently (within the past 2 months). I've noticed it happens mostly when I launch any application from the Microsoft Office suite (Word, Powerpoint, Excel); we're running Microsoft Office 365 Business.

I can't reproduce it consistently, hence the uncertainty.

I've also noticed it happens more often when I start VirtualBox in windowed mode, then resize the window, then launch the Office application. It "feels" like it's a combination of clipboard + window size + black magic.

My VM has Vt-X and nested paging enabled, 64Mb video memory and no 3d or 2d. I've tried enabling them but it makes no difference. Disabling nested paging, on the other hand, breaks Windows.

Guest is Windows 10 with all patches installed. VirtualBox is 5.2.12 with the corresponding guest additions.

[Ingo Karkat]

Same here; it started after I upgraded from VirtualBox (+ Extension Pack) 5.0.10-104061 to 5.1.34-121010.

This is an Ubuntu 16.04.4 LTS 64-bit host running a Microsoft Windows 10 Enterprise (10.0.14393 Build 14393) VM that uses 3584 of 8192 MB RAM and 2 of 4 CPU cores.

VBoxTray.exe suddenly occupies one entire CPU core, killing and restarting helps for a while. Problem occurs about once every day, depending on how much I use the system.

[SnoopyLane]

Same here. I'm running VirtualBox 5.2.12r122591. Host is Windows 7 x64. Guest is Windows XP x86. 3D and 2D acceleration are both disabled.

What does VboxTray.exe actually do? I don't mean why is it burning 100% CPU, I mean what is it's job? Or to put it another way: if I remove it completely what will I be missing out on?

[SnoopyLane]

I just partly answered my question: killing VboxTray.exe kicked me out of Seamless Mode, which is a big deal for me. Would be so much nicer if this actually got fixed.

[Billamay77]

VboxTray.exe is consuming a lot of CPU in my configuration:

Host: Lenovo T460, Oracle Linux 7.5 with kernel 3.10.0-862.6.3.el7.x86_64, VBox 5.2.14 r123301 (Qt5.6.1) with extensions - an Oracle standard company laptop

Guest: Windows 10 OBI (EN-W10P64-10.0.02.0)

Thanks.

[pentagonik]

Please have a look at our Wiki, there you'll find instructions about how to enable guest-side logging: https://www.virtualbox.org/wiki/AdditionsLogging

The created log file hopefully should shed some light on the issue about what's going on.

[Mihai Hanor]

No log gets created. I haven't figured it out why.

[Billamay77]

Hello,

I set:

HKLM\SYSTEM\CurrentControlSet\Services\VBoxGuest\LoggingEnabled = 0xFF (REG_DWORD)

and system-wide variables

VBOXTRAY_RELEASE_LOG_DEST=D:\Temp (which exists in my guest) VBOXTRAY_RELEASE_LOG=all.e.l.l2.l3.f

and rebooted the guest.

because this should suffice for the tray issue. Have I done right? No logs up to now. Are they supposed to appear right after the reboot or after any event?

-- by the way, the CPU issue is not occurring now.

Thanks.

[Rusty_37]

Hi,

i seemed to have got logging working, recreated the fault as above description and attached file called vboxservice.zip. have a look and see if that helps.... Russ

[pentagonik]

Hi Russ, unfortunately this is not the right log we need -- the log you posted is from VBoxService, not from VBoxTray (which seems to create the high CPU load). Can you please try again getting the right log? Thanks!

[Billamay77]

Hello,

it's happening now, on VBox 5.2.16 (latest at the time of writing).

I setup logging as in Comment 30, but no logs are produced. https://www.virtualbox.org/ticket/15478#comment:30

Any idea on how to enable logging for VBoxTray in addition to the above?

Thanks.

[Billamay77]

Sorry, I had to poweroff the machine.

Replying to Billamay77:

Hello,

it's happening now, on VBox 5.2.16 (latest at the time of writing).

I setup logging as in Comment 30, but no logs are produced. https://www.virtualbox.org/ticket/15478#comment:30

Any idea on how to enable logging for VBoxTray in addition to the above?

Thanks.

[Rusty_37]

Hi,

I have tried getting logging to work on the VBoxTray.exe, but have been unable to get any output except the initial start up.

VBoxTray 5.2.16 r123759 win.x86 (Jul 16 2018 16:07:47) release log 13:40:22.012571 00:00:00.000000 000008c0 main Log opened 2018-08-14T13:40:22.012571000Z 13:40:22.012571 00:00:00.000000 000008c0 main OS Product: Windows 10 13:40:22.012571 00:00:00.000000 000008c0 main OS Release: 10.0.17134 13:40:22.012571 00:00:00.000000 000008c0 main Executable: C:\Windows\System32\VBoxTray.exe 13:40:22.012571 00:00:00.000000 000008c0 main Process ID: 4948 13:40:22.012571 00:00:00.000000 000008c0 main Package type: WINDOWS_32BITS_GENERIC

so pretty useless and any suggestions you have would be welcome.

However, I loaded procmon to see if I could find anything about the high load.

It says VboxTray.exe is waiting for dwm.exe and i have dumped the high load processes and this is the result. No idea if it will help

dwm.exe

ntoskrnl.exeKiUnexpectedInterrupt+0x26 ntoskrnl.exeKeUnstackDetachProcess+0x2c17 ntoskrnl.exeKeWaitForSingleObject+0x290 ntoskrnl.exeMmMapIoSpaceEx+0x2eff ntoskrnl.exeKiDeliverApc+0x1db ntoskrnl.exeKeUnstackDetachProcess+0x34e1 ntoskrnl.exeKeUnstackDetachProcess+0x2c17 ntoskrnl.exeKeWaitForMultipleObjects+0x3f9 ntoskrnl.exeObWaitForMultipleObjects+0x294 ntoskrnl.exeObReferenceObjectByHandle+0x62d ntoskrnl.exeExReleaseRundownProtectionEx+0x15ef ntdll.dllKiFastSystemCallRet KERNELBASE.dllWaitForMultipleObjects+0x18 dwmcore.dll!MilTransport_Release+0xb854 dwmcore.dll!MilTransport_Release+0xb185 dwmcore.dll!MilTransport_AddRef+0x3f1 KERNEL32.DLLBaseThreadInitThunk+0x24 ntdll.dllPssNtCaptureSnapshot+0x79e ntdll.dllPssNtCaptureSnapshot+0x772

VBoxTray.exe

one thread with high cpu

ntoskrnl.exeKiUnexpectedInterrupt+0x26 ntoskrnl.exeKeUnstackDetachProcess+0x2c17 ntoskrnl.exeKeWaitForSingleObject+0x290 ntoskrnl.exeMmMapIoSpaceEx+0x2eff ntoskrnl.exeKiDeliverApc+0x1db ntoskrnl.exeKeUnstackDetachProcess+0x34e1 ntoskrnl.exeKeUnstackDetachProcess+0x2c17 ntoskrnl.exeKeWaitForSingleObject+0x290 VBoxGuest.sys!RTSemEventMultiReset+0x180 VBoxGuest.sys!RTSemEventMultiWaitEx+0x18 VBoxGuest.sys!RTSemEventMultiWaitNoResume+0x1a VBoxGuest.sys+0x2fd0 VBoxGuest.sys+0x3085 VBoxGuest.sys+0x5c68 VBoxGuest.sys+0x5f3b VBoxGuest.sys+0x3396 VBoxGuest.sys+0x3446 VBoxGuest.sys+0x4d9f VBoxGuest.sys+0x106e VBoxGuest.sys+0x1426 ntoskrnl.exeIofCallDriver+0x48 ntoskrnl.exeNtDeviceIoControlFile+0x5d5 ntoskrnl.exeNtDeviceIoControlFile+0x2a ntoskrnl.exeExReleaseRundownProtectionEx+0x15ef ntdll.dllKiFastSystemCallRet KERNEL32.DLLDeviceIoControl+0x3e VBoxTray.exe!RTUtf16End+0x1da VBoxTray.exe!RTEnvFreeUtf8Block+0x8d5 VBoxTray.exe!RTUtf16End+0x16c8 VBoxTray.exe!RTUtf16End+0x3e63 VBoxTray.exe!RTCString::substr+0x6c9a VBoxTray.exe!RTCString::copyFromN+0x218 VBoxTray.exe!RTThreadFromNative+0x123 VBoxTray.exe!RTThreadYield+0x2b6 VBoxTray.exe!RTEnvFreeUtf8Block+0xbd2 VBoxTray.exe!RTEnvFreeUtf8Block+0xc5c KERNEL32.DLLBaseThreadInitThunk+0x24 ntdll.dllPssNtCaptureSnapshot+0x79e ntdll.dllPssNtCaptureSnapshot+0x772

other thread with high cpu

ntoskrnl.exeKiUnexpectedInterrupt+0x26 ntoskrnl.exeKeUnstackDetachProcess+0x2c17 ntoskrnl.exeKeWaitForSingleObject+0x290 ntoskrnl.exeMmMapIoSpaceEx+0x2eff ntoskrnl.exeKiDeliverApc+0x1db ntoskrnl.exeKeUnstackDetachProcess+0x34e1 ntoskrnl.exeKeUnstackDetachProcess+0x2c17 ntoskrnl.exeKeWaitForSingleObject+0x290 ntoskrnl.exeKeRemoveQueueEx+0x9a8 ntoskrnl.exeProbeForWrite+0x177f ntoskrnl.exeProbeForWrite+0x1428 ntoskrnl.exeNtRequestWaitReplyPort+0xc7 ntoskrnl.exeLpcRequestWaitReplyPortEx+0x2a win32kfull.sysDwmSyncFlushForceRenderAndWaitForBatch+0x94 win32kfull.sys!xxxBroadcastDisplaySettingsChange+0x422 win32kfull.sysNtUserSendInput+0x93 ntoskrnl.exeExReleaseRundownProtectionEx+0x15ef ntdll.dllKiFastSystemCallRet VBoxTray.exe!RTCString::substr+0x7f35 VBoxTray.exe!RTCString::substr+0x8035 USER32.dllMessageBeep+0x87 USER32.dll!DispatchMessageW+0xc3c USER32.dll!DispatchMessageW+0x1d3 USER32.dll!DispatchMessageA+0x10 VBoxTray.exe!RTCString::substr+0x826f VBoxTray.exe!RTThreadFromNative+0x123 VBoxTray.exe!RTThreadYield+0x2b6 VBoxTray.exe!RTEnvFreeUtf8Block+0xbd2 VBoxTray.exe!RTEnvFreeUtf8Block+0xc5c KERNEL32.DLLBaseThreadInitThunk+0x24 ntdll.dllPssNtCaptureSnapshot+0x79e ntdll.dllPssNtCaptureSnapshot+0x772

also attached screenshot so you can see the test set up

let me know if you have any ideas.

best regards Russ

[Rusty_37]

Hi,

I might have had a breakthrough on a workaround and indicate a little more about the issue. I would be good to get others opinion on my thoughts.

I was looking at

https://www.virtualbox.org/ticket/16025?cversion=0&cnum_hist=1

and

​https://askubuntu.com/questions/940023/16-04-lts-on-virtualbox-drag-drop-from-pc-to-ubuntu-not-working

and this got me thinking.

I looked at permissions etc on directory

/tmp/VirtualBox Dropped Files

and i could see that when i reproduce the fault, the directory does not get created or if it is created, it is empty.

I found by trial and error that if I switch off drag 'n' drop off, my guest machine (windows 10) has a tendency to crash from time to time.

However, i i have shared clipboard to bidirectional and drag mode to Guest to host the guest machine is stable, drag and drop actually works in that direction, and the high load does not occur, well not in 5 days, which for me is a record

I therefore personally think it is some kind of interaction in the bidirectional drag and drop

Russ

[pentagonik]

Thanks Russ, I'll have a look at that.

[bob_256]

I may be able to provide some additional information on this problem. I can now reliably trigger this behavior on my system. My host is OpenSuse Leap 15 with Virtualbox version 5.2.14.

The guest OS is XP-SP3. I have been running this full screen for months with no problems. I have been toying with the idea of running things in seamless mode so I created a minimum XP guest to test seamless mode with. I immediately started to see the high CPU problem. Based on Rusty_37's observations I started to look at drag an drop.

With drag and drop enabled, if when draging any host object, such as a link, and it merely passes over any guest element rendered on the host desktop high CPU is triggered. Turning drag and drop off will return CPU usage to normal.

Bob

Edit: I just verified the same behavior also occurs with a Windows 7 SP1 guest.

[tucan]

I have been encountering this issue every few days. I am running VirtualBox 5.2.18 on Win 10 host, and running several Win 7 32 VM's as guests, on which I do my programming, and which communicate with each other using bridged LAN connections.

Every few days I see the CPU usage on one of the guests ramp up from <5% to around 70%, and then the host in turn ramps up and everything becomes unusably slow and laggy. Rebooting the offending VM cures the problem.

After reading this thread I tried turning off bidirectional drag and drop on the offending host VM, and instantly its CPU usage drops back to normal. Re-enabling drag and drop doesn't cause the issue to re occur.... it seems to work as a way to reset it.

Hope that is useful info

[Rusty_37]

Hi

I can confirm that above workaround works for me also. disabling drag and drop stops the high load, and then re-enabling it doesnt cause the issue.

I had some more time to investigate, I started the guest with drag and drop disabled, started fine. The I enabled drag and drop to bidirectional and tailed the vbox log on the host ubuntu machine and this may shed some light on the issue. When I disable drag and drop the output stops

russ@russ-desktop:~/VirtualBox VMs/Windows_10$ cd Logs/ russ@russ-desktop:~/VirtualBox VMs/Windows_10/Logs$ ls VBox.log VBox.log.1 VBox.log.2 VBox.log.3 russ@russ-desktop:~/VirtualBox VMs/Windows_10/Logs$ tail -F VBox.log 00:01:16.668060 VMMDev: Guest Log: Already at desired resolution. No Change. 00:01:16.694508 VMMDev: Guest Log: VBOXNP: DLL loaded. 00:01:24.283117 VMMDev: Guest Log: OpenGL Warning: crPixelCopy3D: simply crMemcpy'ing from srcPtr to dstPtr 00:01:24.284035 VMMDev: Guest Log: OpenGL Warning: crPixelCopy3D: simply crMemcpy'ing from srcPtr to dstPtr 00:01:24.284644 VMMDev: Guest Log: OpenGL Warning: crPixelCopy3D: simply crMemcpy'ing from srcPtr to dstPtr 00:01:24.285222 VMMDev: Guest Log: OpenGL Warning: crPixelCopy3D: simply crMemcpy'ing from srcPtr to dstPtr 00:01:24.286378 VMMDev: Guest Log: OpenGL Warning: crPixelCopy3D: simply crMemcpy'ing from srcPtr to dstPtr 00:01:24.287090 VMMDev: Guest Log: OpenGL Warning: crPixelCopy3D: simply crMemcpy'ing from srcPtr to dstPtr 00:01:24.287713 VMMDev: Guest Log: OpenGL Warning: crPixelCopy3D: simply crMemcpy'ing from srcPtr to dstPtr 00:01:24.288407 VMMDev: Guest Log: OpenGL Warning: crPixelCopy3D: simply crMemcpy'ing from srcPtr to dstPtr

set drag and drop to bi directional

00:04:22.338530 Drag and drop mode: Bidirectional 00:04:22.501902 GUI: UIMediumEnumerator: Medium-enumeration finished! 00:04:22.609126 GUI: UIMediumEnumerator: Medium-enumeration finished!

copy file from host to guest by dragging

00:04:29.567922 VMMDev: Guest Log: DnD: Error handling format (0 bytes) 00:04:29.568960 VMMDev: Guest Log: DnD: Error handling format (0 bytes) 00:04:29.861637 VMMDev: Guest Log: DnD: Error handling format (0 bytes) 00:04:29.862347 VMMDev: Guest Log: DnD: Error handling format (0 bytes) 00:04:32.006797 VMMDev: Guest Log: DnD: Error handling format (0 bytes) 00:04:32.007794 VMMDev: Guest Log: DnD: Error handling format (0 bytes) 00:04:33.040600 VMMDev: Guest Log: DnD: Error handling format (0 bytes) 00:04:33.042060 VMMDev: Guest Log: DnD: Error handling format (0 bytes) 00:04:34.052004 VMMDev: Guest Log: DnD: Error handling format (0 bytes) 00:04:34.053156 VMMDev: Guest Log: DnD: Error handling format (0 bytes) 00:04:34.084452 VMMDev: Guest Log: DnD: Error handling format (0 bytes) 00:04:34.085401 VMMDev: Guest Log: DnD: Error handling format (0 bytes) 00:04:36.089653 VMMDev: Guest Log: DnD: Error handling format (0 bytes) 00:04:41.467669 VMMDev: Guest Log: AssertLogRel D:\tinderbox\add-5.2\src\VBox\Runtime\win\RTErrConvertFromWin32.cpp(442) int cdecl RTErrConvertFromWin32(unsigned int): <NULL> 00:04:41.467739 VMMDev: Guest Log: Unhandled error 1816 00:04:41.468914 VMMDev: Guest Log: DnD: Processing event 0284cfd0 failed with 1816 (VERR_UNRESOLVED_ERROR), skipping 00:04:41.469061 VMMDev: Guest Log: AssertLogRel D:\tinderbox\add-5.2\src\VBox\Runtime\win\RTErrConvertFromWin32.cpp(442) int cdecl RTErrConvertFromWin32(unsigned int): <NULL> 00:04:41.469115 VMMDev: Guest Log: Unhandled error 1816 00:04:41.469141 VMMDev: Guest Log: DnD: Processing proxy window event 204 on screen 0 failed with VERR_UNRESOLVED_ERROR 00:04:42.915894 VMMDev: Guest Log: AssertLogRel D:\tinderbox\add-5.2\src\VBox\Runtime\win\RTErrConvertFromWin32.cpp(442) int cdecl RTErrConvertFromWin32(unsigned int): <NULL> 00:04:42.915933 VMMDev: Guest Log: Unhandled error 1816 00:04:42.915949 VMMDev: Guest Log: DnD: Processing event 028220e8 failed with 1816 (VERR_UNRESOLVED_ERROR), skipping 00:04:42.915970 VMMDev: Guest Log: AssertLogRel D:\tinderbox\add-5.2\src\VBox\Runtime\win\RTErrConvertFromWin32.cpp(442) int cdecl RTErrConvertFromWin32(unsigned int): <NULL> 00:04:42.915993 VMMDev: Guest Log: Unhandled error 1816 00:04:42.916016 VMMDev: Guest Log: DnD: Processing proxy window event 204 on screen 0 failed with VERR_UNRESOLVED_ERROR 00:04:44.331110 VMMDev: Guest Log: AssertLogRel D:\tinderbox\add-5.2\src\VBox\Runtime\win\RTErrConvertFromWin32.cpp(442) int cdecl RTErrConvertFromWin32(unsigned int): <NULL> 00:04:44.331186 VMMDev: Guest Log: Unhandled error 1816 00:04:44.331248 VMMDev: Guest Log: DnD: Processing event 028596a8 failed with 1816 (VERR_UNRESOLVED_ERROR), skipping 00:04:44.331316 VMMDev: Guest Log: AssertLogRel D:\tinderbox\add-5.2\src\VBox\Runtime\win\RTErrConvertFromWin32.cpp(442) int cdecl RTErrConvertFromWin32(unsigned int): <NULL> 00:04:44.331375 VMMDev: Guest Log: Unhandled error 1816 00:04:44.331467 VMMDev: Guest Log: DnD: Processing proxy window event 204 on screen 0 failed with VERR_UNRESOLVED_ERROR 00:04:45.721665 VMMDev: Guest Log: AssertLogRel D:\tinderbox\add-5.2\src\VBox\Runtime\win\RTErrConvertFromWin32.cpp(442) int cdecl RTErrConvertFromWin32(unsigned int): <NULL> 00:04:45.721750 VMMDev: Guest Log: Unhandled error 1816 00:04:45.721813 VMMDev: Guest Log: DnD: Processing event 0282d470 failed with 1816 (VERR_UNRESOLVED_ERROR), skipping 00:04:45.721897 VMMDev: Guest Log: AssertLogRel D:\tinderbox\add-5.2\src\VBox\Runtime\win\RTErrConvertFromWin32.cpp(442) int cdecl RTErrConvertFromWin32(unsigned int): <NULL> 00:04:45.721981 VMMDev: Guest Log: Unhandled error 1816 00:04:45.722045 VMMDev: Guest Log: DnD: Processing proxy window event 204 on screen 0 failed with VERR_UNRESOLVED_ERROR 00:04:47.108073 VMMDev: Guest Log: AssertLogRel D:\tinderbox\add-5.2\src\VBox\Runtime\win\RTErrConvertFromWin32.cpp(442) int cdecl RTErrConvertFromWin32(unsigned int): <NULL> 00:04:47.108176 VMMDev: Guest Log: Unhandled error 1816 00:04:47.108252 VMMDev: Guest Log: DnD: Processing event 028442f0 failed with 1816 (VERR_UNRESOLVED_ERROR), skipping 00:04:47.108325 VMMDev: Guest Log: AssertLogRel D:\tinderbox\add-5.2\src\VBox\Runtime\win\RTErrConvertFromWin32.cpp(442) int cdecl RTErrConvertFromWin32(unsigned int): <NULL> 00:04:47.108450 VMMDev: Guest Log: Unhandled error 1816 00:04:47.108530 VMMDev: Guest Log: DnD: Processing proxy window event 204 on screen 0 failed with VERR_UNRESOLVED_ERROR 00:04:48.784728 VMMDev: Guest Log: AssertLogRel D:\tinderbox\add-5.2\src\VBox\Runtime\win\RTErrConvertFromWin32.cpp(442) int cdecl RTErrConvertFromWin32(unsigned int): <NULL> 00:04:48.784818 VMMDev: Guest Log: Unhandled error 1816 00:04:48.784887 VMMDev: Guest Log: DnD: Processing event 028384c8 failed with 1816 (VERR_UNRESOLVED_ERROR), skipping 00:04:48.784950 VMMDev: Guest Log: AssertLogRel D:\tinderbox\add-5.2\src\VBox\Runtime\win\RTErrConvertFromWin32.cpp(442) int cdecl RTErrConvertFromWin32(unsigned int): <NULL> 00:04:48.784978 VMMDev: Guest Log: Unhandled error 1816 00:04:48.785072 VMMDev: Guest Log: DnD: Processing proxy window event 204 on screen 0 failed with VERR_UNRESOLVED_ERROR 00:04:50.179621 VMMDev: Guest Log: AssertLogRel D:\tinderbox\add-5.2\src\VBox\Runtime\win\RTErrConvertFromWin32.cpp(442) int cdecl RTErrConvertFromWin32(unsigned int): <NULL> 00:04:50.179687 VMMDev: Guest Log: Unhandled error 1816 00:04:50.179736 VMMDev: Guest Log: DnD: Processing event 02849948 failed with 1816 (VERR_UNRESOLVED_ERROR), skipping 00:04:50.179779 VMMDev: Guest Log: AssertLogRel D:\tinderbox\add-5.2\src\VBox\Runtime\win\RTErrConvertFromWin32.cpp(442) int cdecl RTErrConvertFromWin32(unsigned int): <NULL> 00:04:50.179853 VMMDev: Guest Log: Unhandled error 1816 00:04:50.179896 VMMDev: Guest Log: DnD: Processing proxy window event 204 on screen 0 failed with VERR_UNRESOLVED_ERROR 00:04:51.545580 VMMDev: Guest Log: AssertLogRel D:\tinderbox\add-5.2\src\VBox\Runtime\win\RTErrConvertFromWin32.cpp(442) int cdecl RTErrConvertFromWin32(unsigned int): <NULL> 00:04:51.545652 VMMDev: Guest Log: Unhandled error 1816

this keeps going until I turn off drag and drop

it stops and load returns to normal

[Rusty_37]

Ok, i have been playing around with this for a day or so, and now understand the fault much more clearly.

set drag and drop to host to guest

in the guest minimise all open windows

left click the mouse on the desktop

go to host and drag and drop file

the file will be copied correctly no high load

now open one of the minimised windows and left click the mouse on it

now go to host and drag and drop

this fails and the high load occurs

so it has to do with the selected item in guest

[Rusty_37]

Ok, drag and drop in the other direction, from guest to host suffers from a similar issue

the dropeed files actually seem to end up in /tmp/VirtualBox Dropped Files directory. not on the host desktop. This is outlined on

​https://askubuntu.com/questions/940023/16-04-lts-on-virtualbox-drag-drop-from-pc-to-ubuntu-not-working

so go to the item to be dragged and dropped hover over item on guest hold left mouse down and drag to host. This fails with a time out. If you are looking at the virtual box directory on host, the time directory appears, but not the item itself.

now go back to guest machine. hover over item to be dragged and dropped, and left click mouse and release, so the item is highlighted. Now left click mouse and hold it down and drag it host machine, and this works and the item appears in the host machine virtual box directory

[jws]

Drag and drop might make the problem easy to reproduce, but I experience it with drag and drop disabled.

[Rusty_37]

I agree completely, its the same for me. The above tests for me prove that its not really a drag and drop issue at all, but a mouse focus issue in reality. I was just trying to get a reliable test case that would help someone fix the code. I also experience it from time to time, with drag and drop disabled.

[Rusty_37]

I have retested against build 6.0, and the good news is, that it appears fixed for me. I will use it long term and see how I get on.

[pentagonik]

Thanks for your feedback -- please let us know your further findings so that we can close the bug eventually.

[Rusty_37]

Hi,

it has been a week, and I have everything turned on, cut and paste, clipboard etc and havnt seen the issue.

So i think it can be closed and say fixed in version 6

thanks Russ

[alanbirtles]

Still happening with virtual box 6.0.4

[alanbirtles]

Happened again today at 09:31:39 (I think, I forgot to write down the time before shutting down the machine) whilst the guest was locked. I was performing a disk intensive task on the host (not sure if this is relevant). Service logs attached, I haven't been able to get the tray to write any logs.

[amk]

Needed to regularly kill the VBoxTray.exe when eating lot of CPU. Yesterday upgraded Mac HW, OSX 10.14.6. Installed VirtualBox 6.0.12, copied Guests, reinstalled Guest additions.

Today the fan became noisy, Activity monitor showing Windows VirtualBox VM using 114% host CPU. Windows Task Manager showing VBoxTray.exe eating 56% of guest CPU. Had to kill again. I have no idea what could trigger the issue. If any data can be collected to help, please advise.