Win10 guest goes to GURU with VERR_VMX_UNABLE_TO_START_VM

[j.uha]

Dear community,

first of all, I'd like to thank all of you for supporting this awesome project! I'm very grateful being able to use such a great software in our environment.

Now to my problem. I'm having trouble with a Win10 guest on Ubuntu 18.04.3 LTS. The machine has a rather new Intel Core i7-9700, with 8 cores, and 32GB RAM. VT is available and turned on. The guest gets 8 logical cores and 16GB RAM.

The VM starts normally and works as expected. Everything worked fine for weeks just until I ran the update of a DATEV software collection (a huge accounting software from germany), installed on the guest. The update runs as expected, w/o error until one particular point where the VM changes to GURU meditation. This procedure is reproducible.

Having a look at the logs shows that 'VERR_VMX_UNABLE_TO_START_VM' might be the issue here. Looking deeper shows, that VT-x is supported, active and running as expected.

Two particular log lines remind me of the issue "Cannot start any VM (Win 10; 64-Bit; VBOX_E_IPRT_ERROR, VERR_VMX_UNABLE_TO_START_VM)" (sorry, I can not yet post links, since I'm a new member):

Code: Select all

00:01:11.851397 HM: VERR_VMX_UNABLE_TO_START_VM: VM-entry allowed-1  0x3ffff
00:01:11.851399 HM: VERR_VMX_UNABLE_TO_START_VM: VM-entry allowed-0  0x11ff

Unfortunately, as far as I understand the discusstion of the issue above, it was never solved?!

I honestly can't interpret these lines, but aren't they contradictory? VMX could be allowed or not, but both?! Could it be, that the DATEV update tries to start a VM inside the guest somehow? I activated Hyper-V on guest os btw..

I already tried to activate/deactivate different settings around VT-x support including "VT-X/AMD-V", "Nested VT-X/AMD-V", "PAE/NX", "Nested Paging" etc., without any changes.

I would be very grateful for any help, thank you very much in advance!

Best regards

[socratis]

The machine has a rather new Intel Core i7-9700, with 8 cores, and 32GB RAM. VT is available and turned on. The guest gets 8 logical cores

00:00:00.346496 NumCPUs <integer> = 0x0000000000000008 (8)
00:00:00.484881 CPUM: Logical host processors: 8 present, 8 max, 8 online, online mask: 00000000000000ff
00:00:00.485108 CPUM: Physical host cores: 8
00:00:00.486095 Full Name: "Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz"

Yeah... don't do that... don't assign all your CPUs to the VM. The host is going to run low on resources, since VirtualBox cares about physical processors (cores), not logical ones (threads). Just check the link for your CPU above, and make sure you read the text in the "?" next to the "# of Cores" and "# of Threads" in that Intel page...

[j.uha]

Thank you very much for your fast response!

I reduced the number of cores to 4 and just retried the update but the problem persists. The machine works fine, I run the DATEV-software-update and it goes to GURU at the very same point of the update process.

Find attached the VBox.log of this try. It seems to look the same as in the cases before.

[mpack]

I'm seeing lots of strange activity involving VBOXNP.DLL. This DLL is I believe related to GA shared folders, possibly indicating a problem with the host folder selected. Can you try disabling all Guest Additions shared folders?

[j.uha]

I attached the shared folder just in the last try, because I had to backup some data. The issue arose already w/o shared folders (see the first VBox.log).

But, it actually could have to do with the file system in some way. The DATEV update reproducibly triggers GURU at a point where it checks some file system paths, searching for database folders. I just talked to DATEV support and they confirmed that these are only local paths. I'll investigate which paths these are.

Do you have any other ideas? Having the any file system related things in mind?!

[mpack]

The only things I had in mind was some kind of corruption of the host filesystem, or special (virtual) folders being pulled in by the host OS, causing a driver crash.

[j.uha]

We just had GURU again, even w/o installing the DATEV update. So, things get worse :< I then disabled Guest Additions completely but we had GURU again.

Anybody with another idea?! If not, I'm afraid to switch to Win10 and use Hyper-V instead :/

[scottgus1]

Zip and post that guru meditation'ed vbox.log without the DATEV update.

[j.uha]

Find the log attached. As far as I read it, the problem is still the same. Everything looks quite familiar.

As I already wrote, I can't read these log files. So, it might be completely irrelevant but I recognized that the "failing cpu" has always the same memory reference as instruction error, namely "0x7". In every log, it is the same address:

Code: Select all

00:54:38.121610 HM: VERR_VMX_UNABLE_TO_START_VM:
00:54:38.121611 HM: CPU[3] Guest VMCS active
00:54:38.121612 HM: CPU[3] Instruction error    0x7
00:54:38.121613 HM: CPU[3] Exit reason          0x0
00:54:38.121614 HM: CPU[3] PinCtls              0x7f

..just to add at least something new from my side.

Thank you all for your time!

[scottgus1]

The errors before that Guru Meditation look like they're heavily involved with the CPU. Your CPU came out second quarter 2019, could just be that there's something new that the developers need to program for it, or something new in 6.1.0 that they need to handle.

Can you try downgrading Virtualbox to 6.0.14 or a later version of 5.2 and see if anything is different?

[j.uha]

I will give it a try, just on Monday next week. I'll come back then... have a nice weekend and thank you very much!

[j.uha]

I rolled back to 6.0.14 and the VM runs stable for nearly 2 days now (the last time with 6.1 it crashed after 3.5h w/o any activity on the system). Today I executed DATEV update and everything worked fine.

Seems that the last guess was right, thank you all!!

Merry christmas to all of you!

[socratis]

I'd hate to mark the thread as [Resolved], because rolling back isn't an ideal solution, it means it's a 6.1.0 regression and the developers should know about it.

Can you upload a log from a 6.0.14 session?

[j.uha]

Sorry, I was away for christmas holidays. Find attached the log file of a 6.0.14 session. I also filed a bug here.

Happy New Year to everyone!

[vboxbenutzer]

Hi there, I got a hint from user "fth0" to have a look in this thread.

I cannot include links in my posts, yet, so please navigate to thread id 96556.
There are two of my log files. I will attach a screenshot later, as soon as I am allowed to include links.

So far: Also DATEV update and installation of MSSQL package.