Trying to start it eats up ram and virtual memory and does not start.

[ArturPires]

Many of my VMs also have snapshots, but I'm not experiencing the problem described in this thread.

Yep, I smell a crucial fact still missing from this discussion, for example that all VMs are running from a slow drive, perhaps with Hyper-v also in the mix, and the additional overhead of loading from a bunch of snapshot files is making the lag especially noticeable.

The drive could be faster, but it has been working for years (you can see that Vista.vbox file is from 2016) and it didn't have any problem loading the snapshots with version 6.1.32-149290.

No Hyper-v on this computer, so that is not the cause of the problem.

[fth0]

Thanks for the log files, appreciated!

BTW, I hit the nail on the head with my wild guess. Let me explain:

1. The VM configuration (including snapshots) is stored in the .vbox files. VirtualBox versions 5.2 and newer only write the non-default settings, whereas VirtualBox versions 5.1 and older also wrote the default settings.

2. The default settings for Screen > Recording are <VideoCapture enabled="false" screens="18446744073709551615" [...]/>. Interesting number, eh?

3. VirtualBox 6.1.36 revised the handling of the Recording settings. When the VBoxSVC process reads the VM configuration, it tries to allocate 18446744073709551615 objects. To spare you the calculator, the number equals 2^64-1.

After reading your log files, I could easily reproduce the issue myself. I'm not sure why it only occurs when the Recording settings are read from the Snapshot section. But it doesn't really matter, because the VirtualBox developers were faster than me and already fixed the bug tonight (see 21034).

[ArturPires]

That shows that when we have enough information and knowledge, everything has an explanation.

What I think is strange is that, apparently, few people had this problem.

[mpack]

Three things remain unexplained:

1. What problem did the OP have, since it looks unlikely it would be the same as ArturPires.
2. How come ArturPires had the problem twice? (we don't appear to have both .vbox files).
3. How did number of screens come to be set to that particular number? It definitely is not random, nor is it typical of overflow or underflow bugs. The value in hex is 0x1999999999999999 (wrong, see edit below), obviously '9' has no special significance in hex, only humans get confused between decimal and hex. So this looks like a human mess-up. Whether that human was a VirtualBox dev remains to be seen, but I doubt that too since we have not seen this reported before AFAIK.

Edit:  Belay that. The number is not 0x1999999999999999. That's what you get if you paste the decimal number into the classic windows calculator app (the Win7 version I prefer to use). If you paste the same decimal number into an online hex converter then you get 0xFFFFFFFFFFFFFFFF, i.e. so that's -1 when interpreted as a 64bit signed integer. p.s. if you paste the decimal number into the modern Win10 calculator app then you get an error. Now it does look like a bug in a past version of VirtualBox.

[fth0]

What I think is strange is that, apparently, few people had this problem.

I identified the following theoretical (*) workflow to get into this problem:

Create a VM with VirtualBox 5.1 or earlier, so that the default Recording settings are written to the .vbox file. Then create a snapshot, so that those settings are preserved in the .vbox file. Update VirtualBox "over the years" up to 6.1.36, and you'll run into the issue today.

There are alternatives to that workflow, for example when actively using the Recording feature (leading to non-default settings), but I guess that the majority of today's VMs were created later than in the VirtualBox 5.1 time and never configured the Recording feature.

(*) A few years ago, in my early VirtualBox user days, I already noticed the "large" value of the screens attribute, but I didn't investigate it then. Yesterday, I only modified a current .vbox file to reproduce the issue, so I didn't exactly prove my theory above.

---

What problem did the OP have, since it looks unlikely it would be the same as ArturPires.

I don't see any information from the OP that contradicts my explanations. Why do you think it's unlikely to be the same issue?

How come ArturPires had the problem twice? (we don't appear to have both .vbox files).

The VirtualBox Manager starts the VBoxSVC process, which reads in all .vbox files. If any one of them contains the "bad" information, the problem occurs. ArturPires identified two VMs triggering this behavior, by selectively adding them to an testing installation. Or did I misunderstand your question?

How did number of screens come to be set to that particular number?

First of all, 18446744073709551615 == 0xFFFFFFFFFFFFFFFF == 2^64-1 is a 64-bit bitmask with all bits set, and most of the VirtualBox code handles it as such. Only some part of the new VirtualBox 6.1.36 changes interpret it wrong.

The default value 18446744073709551615 simply enables the screen recording on all (up to 64 possible) virtual screens. Although I'd suspect that VirtualBox wouldn't be very fast if you'd really try to use 64 virtual screens.

[mpack]

First of all, 18446744073709551615 == 0xFFFFFFFFFFFFFFFF == 2^64-1

I'm well aware of that, in fact I said so in my post.

[fth0]

I'm well aware of that, in fact I said so in my post.

Of course! I just repeated it concisely for the other readers of this thread.

[fth0]

This issue should be fixed in the VirtualBox test builds 6.1.37r152565 and newer.

[sideral]

This issue should be fixed in the VirtualBox test builds 6.1.37r152565 and newer.

I had a similar problem to the one described by the original poster, and I can confirm that new test builds resolve the issue. Thanks @fth0!

[JustinH]

fth0, thank you very much for your help. Your patience, kindness, and investigation work are most appreciated.

It is disappointing to see mpack's insensitive and almost rude responses.

[fth0]

fth0, thank you very much for your help. Your patience, kindness, and investigation work are most appreciated.

Thanks for your personal feedback, appreciated!

[mpack]

It is disappointing to see mpack's insensitive and almost rude responses.

It is disappointing to see people reading stuff that isn't there. Can you indicate which post was "almost rude"?

I gave an opinion on the most likely outcome, based on experience. In this case there was a different outcome - that's life. If you think you can do better then by all means spend more time here helping others, let's see how patient you are after a few thousand repetitions of the same small number of answers!

[ArturPires]

It is disappointing to see people reading stuff that isn't there.

For what it's worth, I don't think your answers were "insensitive and almost rude", maybe just a little dismissive of what was really being reported.
The most important is the intention.

If you think you can do better then by all means spend more time here helping others, let's see how patient you are after a few thousand repetitions of the same small number of answers!

Being a moderator in two other forums I know that feeling perfectly well.

[fsw]

Same out of memory problem with 6.1.36 on Windows. uninstalled and reinstalled several times. Went back to 6.1.34 which worked again.

[ArturPires]

Same out of memory problem with 6.1.36 on Windows. uninstalled and reinstalled several times. Went back to 6.1.34 which worked again.

Do you have any virtual machines with shapshots? It looks like that appears to be what causes the problem,