Windows7 guest aborted

[sdd]

Windows 7 guest OS fails with "aborted" status, a couple of seconds after startup screen.

Host Ubuntu 14.04 x64
Guest Windows 7 x64

VirtualBox 5.1.14 r112924

Log attached

VirtualBox 4.3.36_Ubuntu r105129 has the same guest OS running ok.

An it ran ok in virtualbox 5.x until I ran upgrade.

[socratis]

1. Your VBox.log is truncated. Partial logs are not useful.
2. Your VBox.log has been edited. Do not do that. It doesn't help comparisons or viewing.

With the VM shut down completely (not paused or saved), right-click on the VirtualBox Manager and select "Show Log". Save the first "VBox.log" only, ZIP it and attach it in your response (see the "Upload attachment" tab below the reply form).

[sdd]

Log attached.

I've also tried /sbin/vboxconfig in case kernel version changed on ubuntu host, to no effect.

I use rdp to get to ubuntu host, so that it's desktop environment is xfce4 and not standard unity. That created no problems before. When I worked with virtualbox on-site last time, virtual machine ran ok. The only 2 things different (that I can think of) right now are rdp and total package upgrade I ran on host.

virtualbox 5.0.32 r112930 works fine. It seems I have accidentally upgraded to 5.1 through virtualbox manager's popup dialog. Ubuntu upgrade wouldn't upgrade virtualbox for it has no official repo for 5.x virtualbox.

[socratis]

total package upgrade I ran on host.

I have accidentally upgraded to 5.1

We're talking about really major changes here. I would expect the total host update to be more affecting compared to the VirtualBox version. You can always downgrade to 5.0.x for VirtualBox, it's a minute or two process.

00:00:00.128698 NumCPUs           <integer> = 0x0000000000000008 (8)
00:00:00.238806 CPUM: Logical host processors: 8 present, 8 max, 8 online, online mask: 00000000000000ff
00:00:00.238853 CPUM: Physical host cores: 4

Not only you have assigned all your physical cores to your guest, you have assigned all your logical cores (hyperthreaded CPUs) to your guest! Unless you have a canister of aether nearby, there's nothing left for your host. The thing is that you're going to run into problems if you don't reduce the #CPUs assigned to the guest. Take them down to 2 and see if it improves the situation. Here's a more in-depth explanation from a VirtualBox developer. Mind you when he refers to physical CPUs, he means exactly that; physical, not logical:

Why is it a bad idea to allocate as many VCPUs as there are physical CPUs?

You cannot have the best of both worlds. Most modern Intel CPUs have VT-x preemption timers, which VirtualBox has been using for years now. This lets us run chunks of guest code and still get interrupted to run host code depending on how we program the preemption timer. However, the question is not whether we can or cannot interrupt guest code, we normally can. The problem is that there are tasks that require to be run in reasonable frequency & amount of time both on the host *and* the guest. If you starve the host or guest of interrupts or introduce latency because there simply isn't enough compute power available, you will be creating bottlenecks.

Getting in and out of executing guest code via VT-x is still quite an expensive operation. We call it a world-switch or world round-trip, (i.e. VM-entry, execute guest, VM-exit). This is done in ring-0 (kernel) on the host, sometimes (especially on Windows hosts) we are forced to return all the way to ring-3 sometimes in order to satisfy DPC (Deferred Procedure Call) latency. Overall, you're going to have strange latencies introduced in unexpected places if you "overcommit". It is totally possible to run 4 VCPU VM on a 4 CPU host (I do it on my own my Linux dev box sometimes) but it is not something you should be doing if you care about reasonable performance; in extreme cases of overcommitment you may encounter program misbehavior (like when disk requests times out) which the programs are never designed to handle. In the not so severe case you may end up with some strange timeouts but not fatal errors.

[sdd]

After total host upgrade version 5.0 still works and 5.1 does not. I've recreated my W7 vbox with each version change during experiments. My guess is that problem is with 5.1, still. Anyway, update of system packages should not be a valid reason for 5.1 to fail W7 vbox, so it's still a bug.

5.0 works fine, in practice, with "overcommitted" CPUs. Excerpt you brought up was interesting, though. I really need CPUs there for heavy lifting. I'll try to experiment on this, thank you.

I don't remember if I've tried normal number of CPUs with 5.1. I will and I'll post my results here.

Update: 5.1 with 2 CPUs doesn't work either.