virtualbox.org

I'm running into the same problem. Host OS is Windows 10, guest OS is Ubuntu 20.04.
The VM freezes completely. No keyboard or mouse interaction (clicks into the VM) is possible anymore.
Also the virtual box manager is completely frozen.
The only thing which is still working is the display of the virtual box menu inside the VM screen. When I move the mouse onto the (by default hidden) menu on the lower end of the screen, it gets visible, slides up from bottom. But it's not possible to select any action from the menu.
The only possible action is to kill both virtual box manager and VM. But this does not generate any log entries.
The log of the 6.1.14 VM looks very similar to the 6.1.16 log.
I'll attach bot 6.1.14 and 6.1.16 logs...

Try if using VMSVGA (default for Linux guests) helps.

fth0 wrote:Try if using VMSVGA (default for Linux guests) helps.

No, it doesn't because this causes random blank screens at startup.

Additionally, set the Video Memory to 128 MB, start the VM after rebooting the host, and post a new VBox.log file.

What do you want to achieve with this? The VM was running stable with this setup with any version before 6.1.16. There was no change inside the VM nor in the host OS. Why does changing the amount of video memory should fix the freeze problem?

Update: I changed the VM to use VMSVGA and 128MB (running 6.1.14). The blackscreen after login is still present. This might be no VirtualBox problem in general but an Ubuntu problem. But using VMSVGA is therefore no option for me.

Megabreit wrote:What do you want to achieve with this?

It's a troubleshooting step. Some of troubleshooting is taking shots from the hip. 6.1.16 is brand new, so we don't know what new bugs may have been introduced, and a certain amount of guessing is going to happen.

Megabreit wrote:Why does might changing the amount of video memory should fix the freeze problem?

FTFY. It is a guess after all. (Though, to be sure, fth0's guesses are much more like facts on many occasions.)
If any changes were introduced in video that weren't shown in the change log, then more video space may help. Additionally, increasing video RAM has helped some, though not all, non-responsive guests before.

Your 6.1.16 log has the Linux guest using the Windows video card, as fth0 pointed out. Please set the video card to VMSVGA, max video RAM, let the guest OS reboot a couple times. Then shut the guest down completely, start it again, note the wall click time when the guest was started. Run until you see the problem happen,, note the wall clock time again, then shut down the guest, from within the guest OS if possible, or by the guest Virtualbox window's Close box with Power-Off set if necessary. Post that log.

While running the guest for this log, please don't pause it. The posted 6.1.16 log showed a suspend/pause jump from 01:18:50 to 64:53:13.

You posted an update while I was editing my last post.

So just for the records:
Update: I changed the VM to use VMSVGA and 128MB (running 6.1.14). The blackscreen after login is still present. This might be no VirtualBox problem in general but maybe an Ubuntu problem. Using VMSVGA is therefore no option for me. Using VboxSVGA solved this problem and didn't show any other problems or side effects. VBoxSVGA is the way to go (for me).

Regarding a new log, please read my first post again: The guest VM was frozen. Completely. A shutdown from within the VM was not possible. The vbox manager was frozen. Completely. So a power-off from the VM menu or the vbox manager was not possible. This was happening more than once, and always both windows were frozen like described. There is no way to finish your described procedure. Only thing is to pick up the pieces... and I picked up all the logs I could possible get.

Megabreit wrote:please read my first post again:

It's easy to miss stuff. Those who are merciful will be treated with mercy.

Megabreit wrote:The guest VM was frozen. Completely. ... The vbox manager was frozen. Completely.

Artistically punctuated phraseology aside, I see that the typical log-gathering procedure needs another line:

If you cannot either close within the guest OS or with the guest window's close box, use your host OS's 'Task Manager' to kill all the Virtualbox processes. (Hopefully you don't have other guests running at this time, it will kill all of them.)

Then post the portion of the log that did get written. Logs are written on the fly, so there should be something.

If the Virtualbox manager is locking up too, then your issue may not be with this guest but with the whole Virtualbox installation. Or a host OS or PC issue. Also provide the VboxSVC.log found in C:\Users\[you]\.Virtualbox, after the main Virtualbox window seizes up.

Re the VMSVGA issue, try a new guest with VMSVGA. See if that guest also seizes up.

FWIW 6.1.16 is new and may have bugs introduced that were not in 6.1.14.

Megabreit wrote:Why does changing the amount of video memory should fix the freeze problem?

Generally speaking, if the video memory provided is not enough, Linux guests typically either hang during boot or later on, and the configurable maximum of 128 (or 256) MB usually doesn't hurt. So most of the time, there is no reason to keep this potential source of problems. That doesn't mean that your problem must have anything to do with it, though.

The time gap in the log is probably related to the fact that I suspend my Windows PC in the evening and keep the VM running. Since the VM freeze doesn't happen instantly (sometimes takes hours or a day to happen) and I will not keep the box running for days, this is nothing I can change. The same procedure (suspend the host os) was working fine for all (5.x, 6.0 and 6.1) installation in the past years. This issue doesn't seem to be related to the suspend, there are times when the PC wakes up, the VM is still running, and there are times when it isn't. The freeze also happens randomly over the day.
The VM is running a plain cheap Ubuntu on exactly one monitor with full-hd resolution. Before May 18.04, after May 20.04. All the time with 64 MB video memory. Therefore I seriously doubt that this is a configuration issue.

The problem started with 6.1.16. So we definitely have a bug in 6.1.16 here.

Currently I need the virtual box to get actual work done. This is why I downgraded to 6.1.14. I'll update logs when there is time to play with 6.1.16 again...

Made an account just to verify this issue, Megabreit. I have an ubuntu vm I've been using for a while - have changed no settings and experienced no issues until the 6.1.16 update. I'll be downgrading for the time being as well.

unrelated note: Scottgus1, weird/petty digs at folks trying to get help seems pretty unprofessional - especially coming from a site mod.

shæmus wrote:unrelated note: Scottgus1,

You might be right there, shæmus. Though coming back to a conversation from a few months ago it's hard to gather the "air" of the conversation to know if the responses were on point then or not, or if I was out of line, might be hard to do a couple months later, I do try to keep an even keel. I'm not always completely successful, but it is my goal.

Also, at the time, sometimes the responses I get to my sincere efforts to try to help can be snarky too, and on occasion that regrettably breeds more snarkiness on my part. The cycle does need to be broken.

Sincere thanks for your thoughts, and a reminder to me to keep it cool.

Just in case someone cares about this issue: The very same issue still exists in 6.1.18.

Going back to 6.1.14... again...