[VBoxVmService] -> Discussion & Support

[scottgus1]

Trip, that link from Erdeslawe contains precisely the information you need. Read it again carefully.

[erdeslawe]

Trip,

As Andy said, just above the list of possible installation files it says "MSVCR120.dll (2012)".

Don't uninstall any other versions of the VC++ Redistributable that are already installed unless you know for certain that they are not needed by some other software that you have installed, as those apps will stop working if they can't find a copy of the version they need in the location they expect to find it.

[Trippp]

Hi Scott and erdeslawe,

I’ve got some good news and some bad news. First off, you (Scott) were absolutely right, I didn’t read the article carefully enough. Specifically, I didn’t recognize that the name of the missing dll indicated the redistributable package that it came from. MSVCR120.dll indicates 2012, which was not installed, so I installed it (with partial success, see below) and tried to reinstall Pumpkin.

The bad news is that I got the same error message. I looked in the windows/system32 directory and msvcr120_clr0400.dll is there but not msvcr120.dll so the file is definitely missing.

Without much hope I followed the instructions further down in the article and entered the following commands:

regsvr32 ntdll.dll /s
regsvr32 msdxm.ocx /s
regsvr32 dxmasf.dll /s
regsvr32 wmp.dll /s
regsvr32 wmpdxm.dll /s

This did not help either.

When I looked more closely at the system requirements for Visual C++ Redistributable for Visual Studio 2012 Update 4 I noticed that Win 10 was not supported (obviously, it was not yet released). Also during the installation, one of the three files (VSU4\vcredist_arm.exe) would not run on my system. The other two (VSU_4\vcredist_x64.exe and VSU_4\vcredist_x86.exe) installed correctly.

Would you have any suggestions for the next step?

Trip

[scottgus1]

Only thing is to hope the VBoxVMservice developers see this & have ideas.

Otherwise, try using the Task Scheduler idea to start the guest instead, as explained in your original thread.

[Trippp]

Scott and erdeslawe,


I poked around a little more on the Internet and saw a recommendation to install the 2013 C++ redistributable. \

And that worked!!!

So now I can proceed with the main show.

My apologies again for this unnecessary detour. I very much appreciate your guidance in getting me this far.

Trip

[scottgus1]

No problem, Glad you got something working! I guess we'll see you back in your original thread?

[oucil]

I'm using the VBoxVMService to keep a Plex server (CentOS7) running on a VM, and I've got a collection of shared folders used with it. I recently needed to move one of those shared folders on the host (Win10) and updated the settings via the VB console accordingly. When launched from the VB Console, everything worked as expected, but then when I rebooted and let the VBoxVMService bring the machine up, it reverted to the old shared folder details and failed to mount that folder.

In my investigation I was looking at the .vbox XML file for the Guest VM, and to my surprise it still contained the OLD shared folder details. Further I found another file, a .vbox-prev file which contains the proper path info which didn't make a lot of sense (is that PREView or PREVious, or something else??) In any case, the .vbox-prev file also contains the warning not to edit it directly but to use the VB Console.

This is where I'm stuck, the Console shows the new locations as I've saved them, but the XML file which the SVC relies upon is still not up to date. So where are the correct settings stored, and how can I force VB to push the up to date changes out to the .vbox file so I can get this working again?

Thanks,
Kevin.

[scottgus1]

'prev' does mean previous, yes. When Virtualbox needs to write a new .vbox, it writes a .tmp file, the present .vbox get's renamed to .vbox-prev, then the .tmp gets renamed to .vbox. The .vbox-prev is the last good settings through this process, in case something goes wrong.

Virtualbox is very much attached to the user account a guest is started in. When a guest is run with one account, and a different user account is used to log into the PC then the main Virtualbox window and vboxmanage commands will not work to control or edit the guest. VboxVMservice runs the guest under a different account, so it can run guests without anyone being logged in, and edits to guest settings after logging in will fail.

Use the VboxVMservice commands to shut down the guest while you're logged in. Then you should be able to edit the guest settings and have them stick.

[oucil]

Use the VboxVMservice commands to shut down the guest while you're logged in. Then you should be able to edit the guest settings and have them stick.

Thanks @scottgus1, that helped. I was understood the different users, and was already using the Service commands to start / finish the VM, but going through that cycle a couple more times ended up eventually pushing the changes out. Still seems odd that the changes to a VM aren't immediately saved to that VM's definition, the SVC is pointed at the same physical .vbox file regardless of the fact it's another user booting the machine, but I can see how it might cache a copy of the file maybe during a session, so I tried rebooting the host during the process which I have a feeling was the trick. Either way, at this point, at least I know I can get around this.

Cheers,
Kevin.

[scottgus1]

Good, glad your guest is working!

seems odd that the changes to a VM aren't immediately saved to that VM's definition, the SVC is pointed at the same physical .vbox file regardless of the fact it's another user booting the machine

True, but because the service is using a different account (probably SYSTEM or something, not another log-in account) to run the guest, even though the service has access to your account's files, the guest is now running under a different account, and cannot be edited until you bring the guest back under your account by stopping it in VbxVMservice.

[socratis]

@oucil
VBoxVmService is actually a 3rd party application, not VirtualBox. We have a specific thread that deals with it. I've merged your post to that thread.

[sdevdutt41]

I have been doing some tryouts yesterday. it seems that VBoxSDL is somehow directly accessing the Graphicscard. I always ended up having at least the outline of the SDL window visible on my user's desktop and experiencing some graphical errors, even though I redirected the output to another (invisible) desktop. It seems, I will have to put some more effort into that. It would be great to get in touch with the actual developers of SDL, to think about implementing a true headless mode within the application and maybe instead sending out the textual boot messages via some virtual guest to host "pseudo-serial" or whatever socket connection to get at least a little feedback, what is going on with guest-os...