virtualbox.org

Windows 7 host. Ubuntu 20.04 Guest. VB 6.1.34r150636.

Booted into Ubuntu as normal. It offered to apply some latest patches (I think one was Linux kernel), I last booted maybe two weeks ago. While applying these updates a "critical error" occurred in VB. I can only click "OK" which powers off, or "Ignore", which says "leave it as is for debugging", but then it does not get to any prompt and I have no idea what to do.

Rebooting leads to same. This means I can no longer get into my Guest Ubuntu at all, which horrifies me, as I have been using it for years.

Content of Logs directory attached, as it tells me to do.

I presume, from previous experience, that this "Linux Guest" forum is the right place to post, rather then "Windows Host".

I realize you kind people here have many people to help but I should be so grateful for some early response, as at present I am terribly scared that I have no VB to get into and every indication that it is irrecoverably "corrupt"/"bad" so that I never will be able to recover...? Many thanks for whoever's time.

Possibly a RAM error. You are very close to saturating available RAM on your PC. I would reduce VM RAM to 3GB or even 2GB.

00:00:02.690311 Host RAM: 8156MB (7.9GB) total, 4960MB (4.8GB) available
...
00:00:02.949028 RamSize <integer> = 0x0000000100000000 (4 294 967 296, 4 096 MB, 4.0 GB)
00:00:02.949302 VRamSize <integer> = 0x0000000008000000 (134 217 728, 128 MB)

I note that you have a Win7 host. Note that Windows 7 is no longer an officially supported host OS in VirtualBox 6.1.x, though it still works for most. However, there's a chance this also means you are using Avast or AVG third party AV: that software has introduced a new virtualization based security option which defaults to on, you need to turn it off.

@mpack
First, thank you so much for your prompt reply.

I have reduced RAM for VB to 2GB --- still same when attempting to boot into it.

You are right that I use AVAST. I have disabled all its "shields" --- still same when attempting to boot into it.
Now, maybe this is not enough. I am Googling and trying to follow e.g. https://www.techshout.com/avast-hardwar ... alization/ to disable that, but unfortunately I am not finding the current AVAST interface is like they show and cannot find any "Settings" menu or whatever to get into, despite looking hard. I don't suppose you/anyone has any idea how to get to "new virtualization based security option which defaults to on, you need to turn it off" by any chance....?

I never moved from Win 7 as I found it so reliable compared to later Windows. It's a bit late now....

I have to go out for a couple hours now. Do you have any further ideas as to how I can get to at least recovering (i.e. being able to boot into) my VM, which remains scarily inaccessible...?

**UPDATE**
I have now found that AVAST setting. (Would anyone have guessed it appears under "Account > Troubleshooting"?!) And unchecked "Enable Hardware Assisted Virtualization". Unfortunately, still same message upon booting VM, still cannot get into it.

From where I am now have I completely lost the ability to boot into this VM???

jnb wrote:unchecked "Enable Hardware Assisted Virtualization". Unfortunately, still same message upon booting VM, still cannot get into it.

Did you reboot the host? Everyone who has had this issue reports good VM operation after telling 34d-party AV to stop using hardware virtualization.

Please post a new VM log.

Switched host Windows off. Took a deep breath Rebooted Windows. Can get into Linux Gust VM fine. Phew! Slowly re-enabled AVAST stuff, increased VM RAM to 3GB. All well, can still can get in.

Tried a software update inside Ubuntu again. It fetched new packages etc. While applying updates, the same thing happened, VB Critical Error.

Rebooted Windows. Can get into Linux VB again, so great.

I guess this means I had just better not try applying any more updates to the Ubuntu 20.04 in this VM, and just leave it as it is? Might try updates again in a few weeks/months' time, maybe the content of some one update will change and not crash VB?

If nothing else is trying to use VT-x then it isn't possible to get the VMX conflict you previously reported. If we have a new scenario then we need a new log. Just one VBox.log file this time please, plus the VBoxHardening.log will probably still be useful - though we know it's going to report the presence of Avast.

P.s. I'm moving this topic to "Windows Hosts" since the choice of guest OS doesn't seem relevant.

@scottgus (and also new post from @mpack has arrived)
Only just seen your post.

You are quite right about needing to reboot the Windows Host. Damn thing does not tell you to when you change the "Enable Hardware Assisted Virtualization" setting. I was in a rush earlier, sorry I did not try that myself at the time.

As you can see from my latest post, I am now able to get into the VB VM again even with that re-enabled. However, as you can also see attempting to apply whichever Ubuntu update re-causes the VB crash.

I could live forever without updates, but obviously not ideal. I could try re-disabling the Avast HW Virt setting and then seeing whether the updates go through, which I have not tried. Should I try that? Given my Win 7 Home, do I really need the Avast "Enable Hardware Assisted Virtualization"" switched on at all? I do realize my machine is not the most secure (e.g. still using Win 7), so is having to have that switched on the least of my worries and I can/ought do without? I don't require "perfect" AV protection, just a reasonable modicum.

Thanks in advance for your suggestion/opinion.

It's highly unlikely that running updates in the VM will cause the host OS Virtualbox to crash. Something is still getting in the way.

Note that if this:

jnb wrote:re-enabled AVAST stuff

means you turned on the hardware virtualization AV scanning again, as implied by this:

jnb wrote:even with that re-enabled

the you're only turning back on the thing that causes the trouble. And you won't get working Virtualbox until you stop turning it back on. QED.

Patient: Doc, it hurts when I do this...
Doctor: Well, then don't keep doing that!

jnb wrote:do I really need the Avast "Enable Hardware Assisted Virtualization"" switched on at all?

Already answered.
[quote=""mpack"]
that software has introduced a new virtualization based security option which defaults to on, you need to turn it off.[/quote]

@scottgus, @mpack
Sorry only just returned to this.

I now have AVAST's "Enable Hardware Assisted Virtualization"" permanently disabled (and fully rebooted).

It seemed to work initially, sadly now I just got the same "Guru Meditation" again after I left it running for a bit (although @scottgus has said that he thinks it ought work in all cases)

I presume from here I have three choices:

* Wait one more time to verify it still happens again, upload logs now for you to kindly look at anew?
* Completely remove any AVAST AV from PC and see if that permanently fixes?
* Downgrade to an earlier VirtualBox (6.0.x?) to see if it does not happen with that?

**UPDATE**
Just tried e.g. a sudo apt update. Gurus during file download/update. Attached new logs. Does it tell you anything now (with AVAST's "Enable Hardware Assisted Virtualization"" permanently disabled)?

A different error but the same cause.

jnb wrote:Downgrade to an earlier VirtualBox (6.0.x?) to see if it does not happen with that?

This isn't likely to help since the cause isn't coming from Virtualbox. It's like this: you make a sandwich for lunch. I then steal your sandwich. Your inability to eat the sandwich is not caused by the kind of sandwich you made. AV is stealing hardware virtualization from Virtualbox.

jnb wrote:with AVAST's "Enable Hardware Assisted Virtualization"" permanently disabled

Can we get a screenshot to show this, please?

Hi @scottgus1, thanks for answering
And yes I have rebooted a couple of times to be sure.

This isn't likely to help since the cause isn't coming from Virtualbox. It's like this: you make a sandwich for lunch. I then steal your sandwich. Your inability to eat the sandwich is not caused by the kind of sandwich you made. AV is stealing hardware virtualization from Virtualbox.

If I make a meat sandwich and you are vegetarian you might not steal my sandwich

As you can see from shot, I am claiming that AV is not doing that HW virt stuff. Oh, and just btw, FWIW I have the right

C:\Users\Jon\VirtualBox VMs\*

in my AVAST "exclude from scanning" list.

Things worked fine for a long time. I guess it is true AVAST has been updated, if that is indeed the cause. Just wondered whether, by chance, a VB 6.0 might not clash so much with AV.

That setting definitely is off. Thanks for the screenshot!

You certainly could go back to 6.0, it wouldn't hurt to try.

One other thing to look at is from "TormentedGothicPrincess", who also turned off the anti-rootkit shield:
viewtopic.php?f=6&t=106204&p=518832#p518832
I have no idea if this is necessary, but it would be interesting to check on.

As a shot in the dark, you could also try if unchecking "Enable Self-Defense" followed with a reboot helps. It would make sense to use a hypervisor to implement such a feature, just like Microsoft implements its Memory Integrity (HVCI) with Virtualization Based Security (VBS).

@scottgus1

One other thing to look at is from "TormentedGothicPrincess", who also turned off the anti-rootkit shield:

What a username, lol! The (latest) AV interface is rather different from that. Yes, there used to be an "Anti-Rootkit" thingie, now there is no sign of it. Goodness knows why these companies like to completely change their interfaces with regularity

@fth0

As a shot in the dark, you could also try if unchecking "Enable Self-Defense" followed with a reboot helps. It would make sense to use a hypervisor to implement such a feature, just like Microsoft implements its Memory Integrity (HVCI) with Virtualization Based Security (VBS).

Well, as it happens... I switched off everything else AV I could (without uninstalling), which was all the scanners plus that Self-Defender, the only option left on, and rebooted. I got into VB fine, did the full update & upgrade in the Linux guest, rebooted, all went well, for the first time since my problems. Now I have re-enabled the scanners and that Self-Defender, and so far all is working still. If it goes wrong again I will repeat but permanently disable Self Defender too. It's good to know that that could be the reason it was still Guruing