4.x -> 5.x crash

[Mikha Mikhin]

I updated my virtual box from 4.* to 5.*, now my virtual PCs crash when I start them from any snapshot.

P.S. Can't get log from VM.

[Frank Mehnert]

Not enough information. There should be at least a VBoxSVC.log file and I highly doubt that there is no log file in the VM directory, at least the VBoxHardening.log file should be there.

[Mikha Mikhin]

Attached logs.

[Frank Mehnert]

The saved state was created with VBox 4.3.10. Hard to say why the bit was saved in the VM state. Could you try the following:

1. On the command line (cmd.exe), do set VBOX_ASSERT=none then start the VM from that command line with VirtualBox -startvm VM_NAME.
2. Save the VM state with 5.1.26
3. Try to load the VM state.

If this works then this is a workaround to make your 4.3.10 saved states working.

[Socratis]

Replying to frank:

1. On the command line (cmd.exe), do set VBOX_ASSERT=none then start the VM from that command line with VirtualBox -startvm VM_NAME.
2. Save the VM state with 5.1.26
3. Try to load the VM state.

If this works then this is a workaround to make your 4.3.10 saved states working.

1. Does this workaround simply suppress the error message from coming up?
2. Is this workaround cross-platform? (I would bet on "Yes")
3. Do you have to save the state with the newer VirtualBox? What's the purpose of that step?
4. Is this the/a suggested workaround for old saved states which refuse to load in newer VirtualBox versions? Preferred to the "Discard Saved State"?

[Frank Mehnert]

That workaround prevents that the release assertion will immediately terminate the process. It might or might not help in this specific case. Cross-platform yet, just respect how environment variables are set.

Saving the state with the newer version of VBox is supposed to save a "sane" state. I'm aware of a few very old reports about VBox 4.3.x having this problem, thus I assume that this was fixed in the meantime.

No, please do never set VBOX_ASSERT to suppress release assertions without a good reason. This is a workaround only for this particular issue. A release assertion is normally something we cannot handle otherwise, and suppressing a release assertion normally does not make much sense -- because this would just move the crash / malfunction to an unrelated code location.

[Socratis]

OK, makes sense to reserve it only for special cases, aka not a generic workaround. Forgotten already ;)

[Frank Mehnert]

Replying to socratis:

Forgotten already ;)

Good boy :)

[Mikha Mikhin]

Now Vbox crashes with this error:

[Mikha Mikhin]

Don't ignore me please. I still can't start some snapshots because of "Guru Meditation" crash.