NS_ERROR_FAILURE (0x80004005) Component: MachineWrap

[volko]

Dear forum, I'm running out of ideas, I need your wisdom....

Been running Virtualbox 6.0.4 for some time now, Linux host had uptime of about ~30 days and Virtualbox process with a VM has been running also that long.

Yesterday I stopped everything, rebooted, upgraded to Virtualbox 6.0.6 and... getting this error when starting virtual machine again from the GUI:

The virtual machine 'xxx' has terminated unexpectedly during startup with exit code 1 (0x1).

Result Code: NS_ERROR_FAILURE (0x80004005)
Component: MachineWrap
Interface: IMachine {5047460a-265d-4538-b23e-ddba5fb84976}

Observations so far:

• No VBox.log is even created.
• It's not 6.0.6 specific, downgraded back to 6.0.4 and also does not work. Yes, tried also complete VB remove and reinstall, including kernel modules.
• It's not the specific VM itself I last used, another one also does not start.
• Kernel (4.19.xx) did not change.
• Kernel modules report nothing except successful loading.
• Some packages did change/were upgraded in the last ~30 days.
• I'm not aware of any other significant changes in the last days on this system.

I googled for long now - any hints how to debug this further appreciated, I need to get stuff done not play with VB... :-/

[mpack]

There should be a VBoxSVC.log file in the hidden ".VirtualBox" folder. Perhaps that might throw some light.

At a guess I'd think you may be mixing repo and official VirtualBox version code modules, hence VirtualBox failing to start up.

[socratis]

Linux host

Right... the next more "generic" statement would be "I have a host"...
Like "I have a dream" and never telling us your dream!

We need to know details. More details, like distro/version/revision and the output of:

• 
  VBoxManage -version
  uname -a

The "hidden ".VirtualBox" folder" that mpack is referring to, might have changed location and can now be under "~/.config/VirtualBox/VBoxSVC.log".

[volko]

Yes, it is now under "~/.config/VirtualBox/VBoxSVC.log" -- thank you for the pointer.

Looking at the file it just says:
>00:00:09.681049 Watcher ERROR [COM]: aRC=NS_ERROR_FAILURE (0x80004005) aIID={5047460a-265d-4538-b23e-ddba5fb84976} aComponent={MachineWrap} aText={The virtual machine 'xxx' has terminated unexpectedly during startup with exit code 1 (0x1)}, preserve=false aResultDetail=0
...and nothing more :-/

I now have two boxes side by side, both had 6.0.4 working fine for some time.
One is not upgraded and still working, the other the upgraded one where 6.0.4 AND 6.0.6 no longer works.
Diffing VBoxSVC.log from both of them I see nothing standing out.

My guess is one of the distro packages that was upgraded meanwhile breaks any new VB install, question is which one.
So if I would simply reinstall VB 6.0.4 on the currently working one it would also break.

Is there a way to get a more verbose error of VB where stops?

# VBoxManage --version
6.0.4_Gentoo r128164
# uname -a
Linux horizon 4.19.26 #1 SMP Sat Mar 2 17:55:18 CET 2019 x86_64 Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz GenuineIntel GNU/Linux

So the last full rebuild was done at Mar 2 (VB kernel modules) - and something changed since then :-/

[volko]

I found a backup from beginning of March, I took from the backup:
kernel's .../misc/vbox* modules
/usr/lib64/virtualbox/* content, which should be all VB executables/libs, right?

Still does not work.
This points more to that Virtualbox itself is not the problem but another package that was updated meanwhile and is used by VB.

If there is no way to get a more detailed error message from VB, I'll have to put the backuped rootfs on a USB SDD,
boot from that and then upgrade package by package (and rebuild+try virtualbox also everytime) until it breaks.
This is a lot of work and I'd rather spend Easter differently... :-/

(note to self: in the future do weekly full-system backups, not monthly)

[volko]

So I made a standalone, local 6.0.4 build from source tarball into tmp directory.... and it works!
With the kernel modules unchanged, so they are not the problem.
With the system libraries unchanged, so they are not the problem?
It is not a permission problem, ran the working and non-working version as root?

Good thing: I can run the VM again when I need to do stuff.
Bad thing: I'm not smarter what is the problem, and I already spent 2 full days hunting

[volko]

after xx rebuilds, it seems the builds with --disable-hardening work, the one with hardening throw the error.

to recap:
Identical source tarball (6.0.4), identical build process.
Used to build+run fine a little while ago with hardening on,
now something changed on the system that a fresh, hardened build throws error.

What does hardening do, and what system components does it depend on?
Instead of a global on/off switch, can I selectively enable individual features of hardening and bisect this further?

[SrimalPriyanga]

Host: Ubuntu 18.04
Guest: Windows 10
The machine was work smoothly until unexpectedly this error occurs
Result Code: NS_ERROR_FAILURE (0x80004005) Component: MachineWrap
******* Solution ******
I haven't made any update or any changes to host or guest recently, Therefor I looked carefully "VirtualBox VM" folder and recognize
" *.vbox " file name has changed as follows " Windows10-1.15-linux.vbox " so first I rename the file as " Windows10.vbox" now vdi and vbox file appear as follows
" Windows10.vbox "
" Windows10.vdi "

close all the windows and restart both Host and Guest, IT'S WORKING ...!!
In my case this the simple solution that worked for me.