NS_ERROR_FAILURE 0X80004005 When Try to Power up Windows 10

[RaymondTheBrave]

Hi,

My have VB 7.0 installed and running on Linux Mint 21 and it has been running so well. Quick to boot up and run generally very well. Then to day it will not start and I get the following error messages:-

Result Code: NS_ERROR_FAILURE (0X80004005)
Component: SessionMachine
Interface: ISession {c0447716-ff5a-4795-b57a-ecd5fffa18a4}

I cant see anything in the log at all. I have a done a search on the web and on this forum and not found anything that fits this.

I have not made any changes in the environment that I can think of that might of caused this.

I have not updated VB 7.0.
I assume the vbox.log is the latest log based on the update date and time and not the other logs 1,2,3
At the bottom of vbox.log are the following lines:-

07:08:21.457198 GIM: HyperV: Resetting MMIO2 regions and MSRs
07:08:21.461046 vmmR3LogFlusher: Terminating (VERR_OBJECT_DESTROYED)
07:08:21.461123 Changing the VM state from 'DESTROYING' to 'TERMINATED'
07:08:21.462836 Console: Machine state changed to 'PoweredOff'
07:08:21.463020 GUI: Request to close Runtime UI because VM is powered off already.
07:08:21.463087 GUI: Passing request to close Runtime UI from UI session to UI machine.
07:08:21.469261 GUI: UICommon: Handling aboutToQuit request..
07:08:22.981461 GUI: UICommon: aboutToQuit request handled!

What is a bit confusing is the time stamp does not reflect my actual time which was 15:00 or so.

I am at a loss to know what is wrong.

Machine Spces.png (74.34 KiB) Viewed 2954 times

[scottgus1]

Result Code: NS_ERROR_FAILURE (0X80004005)

This is the "an error happened" code, happens with every Virtualbox error, and doesn't mean anything. The rest of the error message was what we need to see.

What is a bit confusing is the time stamp does not reflect my actual time which was 15:00 or so.

Log timestamps start from the VM start at 0:00:00, not the host clock time. The host clock time is posted in the second line of the log.

I cant see anything in the log at all

We can't see anything in the log either, because you didn't zip and post it using the Attachments tab like you did the screenshot.

[RaymondTheBrave]

VBox.log.tar.gz

(38.35 KiB) Downloaded 6 times

This is the zipped logfile.

[scottgus1]

Thanks for the log. It does not show any errors. The VM runs for 7 hours, with a suspend at about 4 hours, but does not show any problems that I can see.

Is the error still happening?

[RaymondTheBrave]

It is in an aborted state when you look at the VB Manager Screen. I have tried to start it and it fails as per above.

VBOX Manager scren grab.png (100.27 KiB) Viewed 2939 times

Are there an steps I should take when a VM is in an aborted state?

Thanks

[scottgus1]

Please try to start the VM again and post the whole error message, including the part that has the CAPITALIZED_UNDERSCORE_SPACED_WORDS.

[RaymondTheBrave]

This is all I get when I try and copy the error message:-
Result Code:
NS_ERROR_FAILURE (0X80004005)
Component:
SessionMachine
Interface:
ISession {c0447716-ff5a-4795-b57a-ecd5fffa18a4}

There is no more.

VB Manager Screen.zip

(108.42 KiB) Downloaded 2 times

[scottgus1]

OK, thanks. That's unusual. It almost seems as if the VM aborts before the usual Virtualbox processes are fully started.

I wonder if your host updated something. After a reliable & restorable host backup, try an uninstall/purge of Virtualbox then do the prerequisites https://www.virtualbox.org/manual/ch02. ... nux-prereq then install Virtualbox again.

[fth0]

I assume the vbox.log is the latest log based on the update date and time and not the other logs 1,2,3

Correct!

We can't see anything in the log either, because you didn't zip and post it using the Attachments tab like you did the screenshot.

ROTFL

This is the zipped logfile.

From a VM run started around 2023-09-24T08:32Z and stopped around 2023-09-24T15:40Z.

Then to day it will not start

Which is 2023-09-25. So we know that no VBox.log file gets created on the problematic runs. Please try the following:

Open a Linux terminal and start the VM with VirtualBoxVM --startvm "Winodows 10" (the typo in the VM name is yours ). This command sometimes gives "more detailed error messages, especially for early failures before the VM execution is started" (according to the VirtualBox User Manual). Afterwards, please provide a zip file with the contents of the VirtualBox global configuration folder (~/.config/VirtualBox). The VBoxSVC.log files contained within that director might give us more insights.

[RaymondTheBrave]

I got this error messages:-
Issued command = VirtualBoxVM --startvm "Winodows 10"

Qt WARNING: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'

[RaymondTheBrave]

I performed the following and then reinstalled VBOX 7.0

sudo apt --purge remove virtualbox*

I noticed that there were some vbox 6. files that were removed.

So it is all working like it was.

So this can be closed.

Thanks for all your help.

[scottgus1]

Great! Glad you're up and running.

[RaymondTheBrave]

The problem is back again.

I dont understand this.

I did not change anything. It was working all day yesterday and today the first time I try and bring up the Windows 10 VM under Linux Mint I get the same error messages that I did in the first place.

1. Could it be linked to the filesystem being NTFS.
2. Would it be better if it was ext4 for example?
3. I booted up my windows 11 yesterday evening and could that have done something to the SSD disk to cause any problems. It is NOT running VBOX but I assume due to it being NTFS disk it checks some things.

I am attaching the requested logs as before.

4. For the time being would it make sense to go back to VBOX 6 just or just try VBOX 6 to see if that helps.
5. I did have qemu running at one point and still might have some stuff half installed and also virtual manager stuff. Could that be causing any issues.


Thanks.

[scottgus1]

I doubt the file system would be an influence, unless a new bug or a bit-flip has cropped up.

I did have qemu running

This could do it. KVM & Qemu can interfere with Virtualbox, though they more usually cause Guru Meditations. In the logged case the VM runs fully, and Qemu is not interfering.

Are you possibly running Docker on your host in between Virtualbox runs? Docker can use KVM/Qemu, if I remember correctly.

[fth0]

I am attaching the requested logs as before.

Please re-read the last paragraph of my previous post in this thread and provide the additional logs.