VBoxSVC.exe and VirtualBox.exe load VBoxC.dll several times per second [FIXED IN SVN]

[Bjoern Hoehrmann]

I've noticed strange drive access patterns when running VirtualBox 4.0.2 on Windows Server 2008 (a clean install with only service packs and updates applied) and used Microsoft's Process Monitor to see what's going on. It turns out that VBoxSVC.exe and VirtualBox.exe load VBoxC.dll several times per second, read a couple of bytes and then close the file again. This happens with 4.0.2 and 3.2.12, it does *not* happen with 3.1.0 which is the version I've used so far. This only happens when a guest is running (a linux version in my case, I've not tried any other). If no guest is running the file is not loaded again and again.

[nike]

I can confirm this behavior, and it seems (from stack trace in Process Monitor) that this behavior is result of COM marshalling/demarshalling process (when remote object is created or maybe called). I'm unsure why you consider that being a bug, and also curious if you see similar behavior with other out-of-process COM servers?

[gaborca]

"I'm unsure why you consider that being a bug"

I also noticed this behaviour, because I've got a relatively old harddrive, I keep hearing the seek sounds while I run VirtualBox, so I think it wears the device. It keeps reading the same few hundred bytes all the time.

[theallmighty]

same for the latest at moment 4.3.10 r93012 high load once a perioud, checked in the guest (winxp) - nothing happens, checked with procmon on host - constant "read file" operation on vboxc.dll

[sunlover]

theallmighty, please attach the procmon log. I could not reproduce the problem.

[mhanor]

This is how the stack looks like, for a VirtualBox.exe thread, when it opens/closes VBoxC.dll:
 http://pastebin.com/cqjAAai5

And VBoxSVC:
 http://pastebin.com/Ntf7kszq

[ianxxx]

Procmon log

[ianxxx]

Same problem here with Virtualbox 5.0.12

I did attach Procmon log.

[bird]

Another developer and I noticed this behavior some years ago and finding it kind of excessive as well. We suspect VBoxC.dll is being opened for reading/checking the type library so COM can make an object in VBoxSVC.exe accessible to a client process.

Thanks to ianxxx bringing this up again. Reminded me to spend some time completing a hopeful solution to this behavior. We are testing it and hope to ship it in the next major release of VirtualBox (sorry, won't appear in 5.0.x, too risky).