5.18 win 7 host win 8.1 guest 0x000000c4

[J.Dow]

Attached find the VBox.png, VBox.log, and Win8.1 thingie.vbox files all in VBox.zip.

The 8.1 image worked on 5.14 and earlier just fine.

The "vboxmanage setextradata "Win8.1 thingie" VBoxInternal/CPUM/CMPXCHG16B 1" fix does not work. (It does generate an appropriate line in the "Win8.1 thingie.vbox" file. In fact the command seems to do nothing. So perhaps the place I found it had it fat fingered.

Thanks
{^_^}

[socratis]

The "vboxmanage setextradata "Win8.1 thingie" VBoxInternal/CPUM/CMPXCHG16B 1" fix does not work.

That's an old workaround. Do not apply it.

00:00:13.607559 !!                 Guru Meditation 1155 (VINF_EM_TRIPLE_FAULT)

Are you sure you were not getting an error with 5.1.4? (note, it's .1.4, not .14) Because if that's the case, the developers would definitely want to hear about it.

[J.Dow]

With 5.1.4 it works
With 5.1.8 it fails

This is on different machines, both fully patched Win 7 64 and way more ram than needed to run the instance.

I copied over the image file from the working 5.1.4 install and put it on the other machine ( 5.1.8 ) and it fails. The log data is from the failure. I can produce a log of a running version from the machine running 5.1.4.

{^_^}

[socratis]

With 5.1.4 it works
With 5.1.8 it fails

This is on different machines

That's a completely different problem. I was referring to the same host. If the host differs, then all bets are off, makes sense, doesn't it? In which case the log deserves a more in depth look.

and way more ram than needed to run the instance.

Well, not quite...

00:00:03.376770 Host RAM: 12219MB (11.9GB) total, 8345MB (8.1GB) available
00:00:05.108349   RamSize  <integer> = 0x0000000200000000 (8 589 934 592, 8 192 MB, 8 GB)
00:00:05.108959   VRamSize <integer> = 0x0000000008000000 (134 217 728, 128 MB)

8192+128+overhead => You're living on the edge. Either close some applications on the host, buy more RAM for the host, or reduce the amount of RAM assigned to the guest.

00:00:05.108450   NumCPUs             <integer> = 0x0000000000000004 (4)
00:00:06.916259 CPUM: Logical host processors: 8 present, 8 max, 8 online, online mask: 00000000000000ff
00:00:06.916262 CPUM: Physical host cores: 4

You have assigned all your CPUs to the VM. The host is going to run low on resources, since VirtualBox cares about physical processors, not logical ones. See: CPU Cores versus threads.

I copied over the image file from the working 5.1.4 install

By "image" I hope you mean the whole VM folder, not just the VDI, right? That would include the .vbox file, which is the "recipe" for the VM, not just its hard drive.

Fix the three things I mentioned (RAM, CPUs, CMPXCHG16B) and see if it helps.

[J.Dow]

Good observation on amount of free RAM. However, I closed browsers to get about 9.5 G free. It still crashed the same way. Besides, I've noticed the amount of ram claimed when simply booting a Windows OS is much less than the amount VBox is authorized to claim.

Regarding number of CPUs, why would it suddenly stop working when it had been working? With only 2 processors it still crashes.

I copied over the .vdi file. I had previously installed on the desktop machine. I copied the whole thing over to the laptop, brought it up with no networking, changed the machine's network name, and turned on networking. It worked for well over a year through the Avira mess. It doesn't work now, just after 5.1.8 was installed. I don't run it very often. I use it for testing. Each month or two I run up the guests to update them. Worked last time. Failed this time. Only change was moving to 5.1.8. What can I say?

Incidentally, it gets as far as showing the Win 8.1 boot screen and fails a very few seconds after that splash comes up. It's valiantly trying to run.

{o.o}

[socratis]

If you want to see whether it's a bug in 5.1.8, that's pretty easy to do. Uninstall 5.1.8 and install 5.1.4. Your VMs do NOT get in harm's way, don't worry. If you don't get a crash with 5.1.4, but you do with 5.1.8 (ON THE SAME HOST), it's a bug and needs to be addressed.

[J.Dow]

OK, I tried going back. This seems to repeat the experience I had going back before. It crashes even back on 5.0.26. I changed it to 4096 megabytes. It still crashes. I even turned off the AV and it crashes. This is with 9.5 giga-BYTEs free or significantly less. A Win 7 32 bit VM works fine. 64 bit Scientific Linux 6.5 works Remote display on or off makes no difference.

I bit the bullet and installed 5.1.8 on the other machine and it works there so I don' t think it is a memory problem.

I copied the 5.1.8 install over to the laptop and changed one file location in the .vbox file. I ran it. It crashed the same way. About 3.6 seconds into the boot process it shows the same numbers except for the third one which moves around in the above 0xfffff80000000000 range. For grins and giggles I tried windows 2012 64 bit and windows 10 64 bit settings and they did not work either.

I'm going to try reinstalling since it's only a test install anyway. I'll add to this if it succeeds or fails.

{^_^}

[J.Dow]

Update:
Installing Win 10 x64 - 4 processors 6144 MB VBox stalls - no disk activity on DVD or HD early in DVD boot process. Heavy CPU activity - saturated processor.

Installing Win 8.1 x64 - not tried yet.

Installing Win 7 x64 - appears to work. 4 processors 6144 MB. Performing updates. Apparently functioning properly.

{^_^}

[michaln]

The "vboxmanage setextradata "Win8.1 thingie" VBoxInternal/CPUM/CMPXCHG16B 1" fix does not work.

It "doesn't work" because it's done automatically.

Please turn on paravirtualization for the guest (either default or Hyper-V which amounts to the same thing), re-run the guest and post the resulting VBox.log, assuming it still crashes (likely). There is something the Windows guest probably doesn't like about your CPU, but I can't quite see what. Paravirtualization should at least help capture a bit more information.

[J.Dow]

Paravirtualization is already default.
Enable VT-x/AMD-V is already on.
Enable Nested Paging is already on.

I wonder if the problem is related to the security environment 8 and 10 seem to prefer. One thing that has started to hammer its way through my thick skull is that updating VB on the over bloated Desktop (working machine) does not require a reboot most of the time. It does require a reboot on the bloated laptop (crashes).

Regarding "bloated", I used to develop video software. And these days I am playing with high sample rate software defined radios. Both activities benefit from bloated machinery. And since I am "nominally" retired, I get to play. Although most of the SDR playing has to be done outside virtual environments because it needs USB bulk transfer rates well in excess of what I have gotten with VB in past years.

{^_^}

[michaln]

Paravirtualization is already default.
Enable VT-x/AMD-V is already on.
Enable Nested Paging is already on.

Hmm, the VBox.log file you provided unfortunately disagrees. "GIM: Using provider 'None' (Implementation version: 0)" means no paravirtualization interface. And no such interface is used by the guest, that's also clear from the log. There is no "Paravirt provider" setting in the .vbox file.

This may be a bug in VirtualBox but I need to know more. Could you please paste or attach the output of 'VBoxManage showvminfo <your_vm>'? It should show two lines, "Paravirt. Provider" and "Effective Paravirt. Provider". Those show the setting and what it translates to.

I wonder if the problem is related to the security environment 8 and 10 seem to prefer.

I don't know if it counts as "security environment" but 64-bit Windows 8.1/10 has higher CPU requirements compared to Windows 8.0 and earlier. So it uses different CPU instructions and different code compared to earlier versions. Your CPU should be able to handle it, even though it predates Windows 8.1.

One thing that has started to hammer its way through my thick skull is that updating VB on the over bloated Desktop (working machine) does not require a reboot most of the time. It does require a reboot on the bloated laptop (crashes).

Could you please elaborate? VirtualBox installation or update is designed not to require a host reboot. If the installation/upgrade causes a crash, that's something we need to fix.

Although most of the SDR playing has to be done outside virtual environments because it needs USB bulk transfer rates well in excess of what I have gotten with VB in past years.

Past years yes. Nowadays the xHCI emulation should be able to transfer ~100 MB/s or more with a fast enough device (USB 3.0, since USB 2.0 tops out somewhere around 35 MB/s). Caveat, requires manual driver installation in Windows 7 (but not later) guests.

[michaln]

I imported your .vbox file. Over here it shows the paravirtualization provider as "legacy" and effective provider as "none". That is the expected behavior for a settings file with no paravirtualization entry.

[J.Dow]

Regarding the paravirtualization I copied the working version over to the laptop and it failed exactly the same way. I checked the GUI manager and IT thinks paravirtualization is turned on. I cleared it off the laptop for the other tests. So I am recopying it, making the location fix for the vdi file and disconnecting the virtual network cable to avoid local DNS issues. I'll run it up in a moment....

OK, it copied over as legacy. I see with 8.1 on the desktop it also says legacy when it is not running. When it is running it says default. I changed it and restarted the desktop - it works with no particular change in performance. I tried the laptop with default and Hyper-V with or without nested paging. All three crashed the same way. I've attached the logs for the three attempts.

All three crasges are 0x000000c4.
The first, second, and fourth addresses shown are
0x0000000000000091
0x000000000000000f
..
0x0000000000000000

The third varies in the 0xfffff80X0xxxxxxxx range with X being 1 or 2.

Incidentally I just checked the TESTS vm I've been playing with. The GUI says para is on, VT-x is on, and page nesting is on.

{^_^}

[michaln]

Okay. The bug check screen is unfortunately unhelpful because Windows 8.1 is buggy (known problem). The 0x000000c4 error the guest OS reports indicates a generic problem, but it actually happens in response to an unsupported CPU being detected. Basically the OS is broken and when it tries to show an error message about an unsupported CPU, it crashes, hiding the real cause.

Here's the key clue from the log: "CPUM: WARNING! Can't turn on NX/XD when the host doesn't support it!". We should really not even allow the VM to start in that case, because Windows 8.1 requires it (Windows 7 does not). NX/XD is the 'No-eXecute'/'eXecute Disable' bit which prevents code to be executed from certain pages.

Anyway, you probably have to go to your ThinkPad's BIOS and make sure the feature is turned on. I can't unfortunately tell you exactly what the option is called, it could be under Security -> Memory Protection -> Execution Prevention.

[socratis]

Here's the key clue from the log: "CPUM: WARNING! Can't turn on NX/XD when the host doesn't support it!".

1. Nice clue to keep in mind. Kind of tough to spot though...
2. Is it only Win8.x that requires it, or anything > Win8? Like Win10 for example.
3. Since we're in the warnings detail, and since it has been already mentioned in this thread, why since

   The VBoxInternal/CPUM/CMPXCHG16B fix "doesn't work" because it's done automatically

   and even if it is not explicitly enabled in the configuration, there is the following warning in the log:

   Warning: /CPUM/CMPXCHG16B is deprecated, use /CPUM/IsaExts/CMPXCHG16B instead.

   Is VirtualBox warning itself here?