VBoxSVC.exe 100% CPU after WinXP SP3 Hibernate -> fixed in SVN/3.0.2

Just for clarification, here's steps to reproduce:

1. Open VB
2. Hibernate host
3. Awake the system from hibernate

= VBoxSVC.exe hogs CPU for several minutes (~5-10mins).. after a while the CPU hog stops and Windows is responding normally.

Updated to 2.1.2 and problem still persists. I just tested and the CPU hog after host hibernate lasted about 9 minutes!!

Am I the only one who has this problem? Could somebody test this and report back here if it's reproducible?

P.S. Should the version metadata be updated in this ticket?

Add the VBox.log file of such a session please.

I'm sorry but how's that going to help? I mean, isn't VBox.log files only generated when running guest OS's? Look at my steps to reproduce this problem, there's no step to run guest OS's = no VBox.log files! Or am I missing something here?

Misread then. Does the same happen when you have a VM running?

Log of the guest OS session running when hibernating and waking back the host.

Yes it does.. of course I might add, because the VBoxSVC.exe is running whether I have or haven't got a guest OS running (or if only running guest OS, = main VB window closed).

I guess you were after the log file from that session? Maybe it's of some use. Only interesting IMHO is the following:

00:35:33.247 Changing the VM state from 'RUNNING' to 'SUSPENDED'.
00:35:47.401 ERROR [COM]: aRC=VBOX_E_INVALID_VM_STATE (0x80bb0002) aIID={e3c6d4a1-a935-47ca-b16d-f9e9c496e53e} aComponent={Console} aText={Invalid machine state: 5)} aWarning=false, preserve=false
10:46:13.320 Changing the VM state from 'SUSPENDED' to 'RUNNING'.

What about suspend/resume? Same high cpu use by VBoxSVC? I can't reproduce this here with a Vista host.

You surely mean standby?

I think I got new data to this problem; it seems that the hang and the length of it is connected to the standby/hibernate length.

At first I tried the standby really quickly, standby and resume after about 10 seconds, no hang at all. I decided to test again, I put my PC to standby and went to make some food and watched a movie + tv for about 2½-3 hours, resume brought the desktop to the screen very slowly and the VBoxSVC.exe was again hogging the CPU.. this lasted about 2-3 minutes.

Last time I tried the hibernate, the system was in that state for about 3-4 hours and the hang lasted about 4 minutes after resume.

And my hibernate test before that lasted overnight and the hang lasted about 9 minutes after resume.

(yes, I do keep rough notes when I test bugs/problems.. I'm not a newbie with testing)

I think that this is an important observation and could lead to the culprit more easily.

Interesting observation. Will give that a try.

Still can't reproduce. Neither with Vista or XP SP3. Duration of hiberate doesn't make any difference here. Are you willing to test an instrumented build to log what's going on on your system?

This also happens on my system (XP x64 SP2). VBoxSVC.exe runs at 100% on one of the cores for a good 20 minutes after the host was turned off for 24 hours.

#3388 has been marked as a duplicate.

I have the same issue, Vista 64bit fully updated host, win 2003 guest

I can test an instrumented build to log what's going on on my system.

I also have the same issue, running Vista Business SP1 (32-bit) as host OS and Virtual Box 2.1.4.

Let me know if I can be of any help.

This happens on my system when it comes back from S3 sleep, Vista 32bit SP1 host with VirtualBox 2.1.4.

This still happens on 2.2.0 of virtualbox (Windows XP 5.1.2600)

Same here with Windows Vista Ultimate SP1. I have this problem since 2.1.2 (I think!!!)

Same here with Windows Vista Ultimate SP1 32-bits. I have this problem since 2.1.2 (I think!!!)

also seeing this problem in Windows Vista Home Basic. the cpu usage pegging by VBoxSVC.exe definitely seems directly associated to how long the system has been in suspend/hibernate/sleep.

Just installed 2.2.2r46594, Same issue after I hibernate my laptop (DELL Inspiron 1545,Vista Home Premium SP1; Intel Dual-Core T4200)for a night and the VBoxSVC.exe forces the *second* CPU core running at almost 100% usage for several minutes. No VM or VBox GUI is running at all.

This bug is the same as #2274.

I also have the same problem, VB 2.2.2.

Tested on hosts: 1. WinXP Pro SP3 32-bit, AMD Athlon X2 4600+ 2. Vista Business SP1 32-bit; Intel Core 2 Duo E6600

I have the same issue with version 2.2.2 on Win7 64-bit (also had it with previous versions and on Vista 64-bit).

In Process Explorer, I see that the thread consuming the CPU is the following:
Thread 4812
50% CPU (100% of one of two 1.8GHz cores)
Start address: MSVCR80.dll!endthreadex+0x80
Stack:
0 MSVCR80.dll!operator new+0x2
1 VBoxSVC.exe+0x181e57
2 VBoxSVC.exe+0x1851cf
3 VBoxSVC.exe+0x18565a
4 VBoxRT.dll!RTTimerLRStop+0x108
5 VBoxRT.dll!RTThreadReadLockDec+0x1e4
6 VBoxRT.dll!RTSemMutexRelease+0x198
7 MSVCR80.dll!endthreadex+0x47
8 MSVCR80.dll!endthreadex+0x104
9 kernel32.dllBaseThreadInitThunk+0xd
10 ntdll.dllRtlUserThreadStart+0x21

I have the same issue on Vista64 SP2 with Virtual Box Version 2.2.4., unfortunately the issue is still not fixed.

Same here: Vista64, Service Pack 1, Virtual Box 2.2.4 r47978

still quite broken in vista32 sp2 vbox 2.2.4

I do have this issue as well.

• Lenovo T60p
• Windows XP SP2
• VirtualBox 2.2.4 (I did have the same problem with 2.2)

I do have this happen even when I have NO Virtual Machines running. This sort of sucks, because it take 2-7 min to bring laptop from the standby mode, because VBoxSVC.exe hugs CPU.

I've just created an account just to say this:

SAME HERE!

Toshiba Tecra M7 Windows7 RC 32bit VirtualBox 2.2.4

One has to remember to shut down VirtualBox completely *before* suspend/hibernation... otherwise it gets very very busy after waking up.

Same Issue: Windows XP Prof SP3 32bit and Virtualbox 2.2.0/2.2.4. (hibernating and standby)

Same problem here with VB 2.2.4r47978 on Windows Vista Business 64-bit w/ SP2 running Windows Vista Business 32-bit VM. I usually don't hibernate the machine, only do standby, and as soon as it comes out of standby, it ties up the CPU 100% for several minutes. I have a Core 2 Duo 2.53 GHz processor w/ 4 GB RAM.

Seems like it's fixed in 3.0.0 :)

Thank you!

Can others confirm this as well?

I'm afraid I've said that too soon - the problem is still here :-(
Sorry for my mistake.

I guess the laptop didn't sleep long enough last time (just about 15-20 minutes or so) and that's why I didn't notice a high cpu usage.
This time, after waking up after about 10 hours, it's been thinking hard for sth like 10 minutes!?
It's the VBoxSvc.exe process showing 50% CPU usage on a Core2 Duo CPU.

I can also confirm that the problem still remains with the new 3.0.0 release as well. Still hogging the CPU at 50% for a long time.

Yep, problem still remains here too with 3.0.0. VBoxSVC.exe still churns away and hogs CPU completely. Just hibernated for about 3 hours and the "freeze" took about 3 minutes. Is there any progress on nailing this issue? Have any of the testers/coders been able to reproduce this?

Unfortunately we are unable to reproduce the problem. I even have the exact same machine (Thinkpad T60p) as one of the reporters with XP and don't see it. Are all of you able to reproduce this even when no VM is running? (just the VirtualBox GUI)

I am experiencing the exact same problem. I was using 2.2.4, but have recently upgraded to 3.0.0 and the problem remains.

My system: Windows XP Media Center Edition 2002 (basically the same as XP Pro), SP3 Dell Inspiron 6400 Intel Core 2 Duo T7200 @ 2.0GHz 1GB RAM Latest BIOS

I'm running Ubuntu Server 9.04 as a guest. I pause the guest and hibernate, but when I resume one of my CPU cores maxes out for an extended period (I've not yet waited to see how long for, but it's in excess of 10 mins). The offending process is VBoxSVC.exe.

Shutting down the guest does not stop this, however closing the VirtualBox GUI does.

@sandervl73: It happens as long as VBoxSVC.exe process is alive and you either go sleep or hibernate your machine and wake it up again.

Volunteers that wish to try out test builds should say so here. I'll wait a few days and will then send out links to test binaries next week. We are still unable to reproduce this problem, so the only solution is to try out a few things. Thanks in advance.

@sandervl73: I am able to reproduce this with just the GUI (even when no VM is running) on a Vaio 1GB Pentium M 1.2 GHz with Win XP SP3 host. I am still using Vbox 2.2.0, because setup ends prematurely for 2.2.4 and 3.0.0 (but I don't need any update before #2978 is fixed ;-) ).

Yes, please send a test binary link.

I can try the test build too.

I volunteer as well.

I volunteer to try out test builds.

I'd like to try the test build as well.

This is still a problem in VirtualBox 3.0.0 r49315. I am running a Vista 64-bit host. I notice the problem when I have a VM running or paused and I put the host to sleep. I haven't tried other scenarios. After I kill VBoxSvc and unpause the VM and try to enter seamless mode, it errors saying that there isn't enough video memory allocated and I should allocate more than 1mb of video memory... when it has already been allocated 64mb.

I've been experienced this symptom from 2.2.2 , 2.2.4 till 3.0.0, now I found that when I downgrade to install 1.6.6, it seems to be no such issue. Please give it a try if you like.

I've only noticed this issue today for the first time. I've been using different versions from 1.6.x up to 3.0.0 (current). Could it have anything to do with hardware virtualization? Until yesterday, my system bBIOS was locked not to use it, and I've just unlocked it.

After sleeping tonight (not hibernating), I woke up my PC this morning to see that VBoxSvc.exe was hogging one of the two cores of my Core2Duo CPU. The VirtualBox.exe process that ran the machine (Ubuntu Server Jaunty) was very low on CPU, as usual, and both inside the machine and the VirtualBox GUI there were no signs of slowness whatsoever. I noticed however that the Session Information Dialogue, which I still had open, did not respond and I had to close it (which went smooth).

I haven't tested any further for now, but these observations were new to me.

Forgot to mention, my host system runs Vista x86 (32bit), so apparently it affects both 32 and 64 bit versions of the software.

Looks like I found the problem. Will be fixed in 3.0.2. No need for testing anymore as I've been able to reproduce it. Thanks anyway!