Guest OS Windows 7 Error After upgrade to ver 5.1.116

[Faasis1215]

Installed version 5.1.116 successfully today however, got stuck in System Recovery Options when i run guest OS Windows 7. I had the mouse & keyboard auto captured but access to keyboard &/or mouse is lost except right-Ctrl key. When right-Ctrl key is pressed the mouse pointer appears and disappears when right-Ctrl key is pressed again.

Enclosed is the VboxHardening.zip file for reference.

[socratis]

First of all, the VBoxHardening.log is required if you have a problem on a Windows host starting any guest. You are notified about it and directed to include the log in your post.

Your host is Win8.1 and your guest is Win7, correct? Why did you get "stuck" in the System Recovery Options? How did you end up there? At this point of course the mouse and keyboard are going to be captured by the VM. Do you want to further explain what's going on?

[Faasis1215]

The Host is actually Server 2012 R2 rather than Windows 8.1.

I installed VBox version 5.1.14 in January 2017 and have 3 guests running headless. Yesterday, i noticed new version 5.1.16 shown on VBox Manager and downloaded. Then, proceeded to shutdown the 3 guests OS (Win-7 32-bit) by clicking Start in the VBox Manager and select Show then, shutdown. Once all the 3 guest OS were shutdown i proceeded to install version 5.1.16 then, hit upgrade. Once installed, it asked me to download the extension pack as well which i did and install right away.

Once done with the installation i went ahead and start one of the guest OS...load Win-7 normally but BSOD then loads Windows Error Recovery with 2 choices: Launch Startup Repair (recommended) or Start Windows Normally. I initially selected Start Windows Normally but it goes back Windows Error Recovery. Then, i selected Launch Startup Repair. Once inside the System Recover Option screen but then the cursor appears & disappears when hitting right-Ctrl key. No other keyboard keys appear to get captured by VBox and therefore, couldn't move forward with the recovery.

I did test the other 2 guest OS and had the same result.

[socratis]

A couple of things:

• Does downgrading to 5.1.14 "improve" the situation?
• Does upgrading to the latest test builds "improve" the situation?
• Do a "cold start"/"observe error"/"complete shutdown" cycle of the VM with VirtualBox 5.1.16. Right-click on the VM, Show Log, save the 1st log only, zip it and attach it?

[Faasis1215]

I downloaded versions 5.1.14 & 5.1.17 as per the link provided and will uninstall version 5.1.16 then, install 5.1.17. If version 5.1.17 doesn't work then, will reinstall version 5.1.14. Is there any special procedure in downgrading to 5.1.14?

I started the VM but fatal error on screen so i closed and selected shutdown & restore snapshot 4 (the last good snapshot). Then, restarted okay with trust relationship between our domain so i login the admin user. Resolve the trust relationship issue and change the domain to workgroup but application error (0x80000003) 0xf870aa0c during restarting process.

Anyhow, enclosed is the log you requested.

[Faasis1215]

Installed version 5.1.17 but had the same issue as version 5.1.16. The next step is to install version 5.1.14.

[Faasis1215]

Installed version 5.1.14 and related extension pack; started VM and selected 'start windows normally' with no problems. Reverting to version 5.1.14 seems to fix the boot issue and didn't have to restore my backup.

Thanks much for your help.

[socratis]

Thanks much for your help.

NO, WAIT!!! We're just getting started
You must have hit a regression (of sorts). You know what would really help? If you could repeat the log collection procedure with 5.1.14. That would give us a prime candidate for a comparison.

EDIT: I need to know the exact 5.1.17 version.

[Faasis1215]

We need the VM badly so i can't wait to get it resolve the way it should. Anyhow, the exact version of the upgrade is 5.1.17-113974-win.exe.

Enclosed is the log file for version 5.1.14 you requested. Please let me know if there's anything you need related to my issue earlier.

[socratis]

Thank you for the second log! I think that you may have hit a regression bug in 5.1.16, a not so widespread one. Here are the conditions/symptoms that you can observe that this might be the case:

1. The VM was working fine with 5.1.14.
2. BSOD with > 5.1.16, including today's test build, VirtualBox-5.1.17-113974.
3. The VM has the ICH9 chip enabled.

So, here's what you can try out; in the VM Settings » System » Chipset: change back the chipset to the default PIIX3. You could do that easily, at your own leisure. It might require a reboot of the VM after you've changed the chipset, but it should be an easy, automatic procedure.

And secondly, I'd like an explanation on why you changed the proposed template defaults for the chipset from PIIX3 to ICH9. Even if the answer is "just because I could", it would be useful. That's of course irrelevant of the existence of the bug or not.

[Faasis1215]

I have updated the VM's System Chipset to PIIX3. I don't remember the rational why i changed the default chipset to ICH9. One thing for sure it worked fine with version 5.1.14 (even though it is not recommended). Would you think this is the reason for the regression when i upgraded it to version 5.1.16?

[socratis]

One thing for sure it worked fine with version 5.1.14

That's why it's called a regression. As I said, it's not that widespread, only 1 report so far, but it's something that the developers asked us to keep an eye on. You fit the characteristics of the bug, that's why I proposed the chipset change. The proof will be if you go back to PIIX3 and VirtualBox 5.1.16 or greater runs successfully.

Finally, changing things at random is not the greatest idea in the world, if you don't understand the ramifications. Especially for something, which when you hover over it, the tooltip description is:

Selects the chipset to be emulated in this virtual machine. Note that the ICH9 chipset emulation is experimental and not recommended except for guest systems (such as Mac OS X) which require it.

[Faasis1215]

Finally, changing things at random is not the greatest idea in the world, if you don't understand the ramifications

I now remember why i selected ICH9 in favor of PIIX3 and it has something to do with Headless Start of VM. If PIIX3, you'll still have a GUI window open even if you open VM using Headless Start. ICH9 would have a VM without a window for remote display only.

So, in order for the latest upgrade to work one needs to change the System's chipset to default PIIX3??

[socratis]

So, in order for the latest upgrade to work one needs to change the System's chipset to default PIIX3??

I still don't know if that's the case. At this point it's a suspicion that this might be the bug that's affecting you. A guess. I'll need you to perform that test as I said.

After the bug is confirmed, the source found, the patch applied, the test build working, I expect that it will be fixed in a future update.

[socratis]

I now remember why i selected ICH9 in favor of PIIX3 and it has something to do with Headless Start of VM. If PIIX3, you'll still have a GUI window open even if you open VM using Headless Start. ICH9 would have a VM without a window for remote display only.

I maybe completely wrong here, but the type of the chipset, and whether there's a display is available or not, seems to me that they have as much relation as an airplane and a donkey.

I definitely can not reproduce it, neither do I remember anyone else reporting something similar to that. Are you 100% sure about that?