5.1 regression: Operations involving network adapters freeze the guest

[cremor]

Since VirtualBox 5.1 was released I tried to upgrade from 5.0 multiple times. But every time I try, I get guest freezes for operations that involve network adapters. I've never had this problem with any version before, including all 5.0 versions. Downgrading to 5.0 (currently using 5.0.26) fixes the problem.

I currently know of two ways to reproduce the freeze. It isn't reproducable 100% of the time, but about 75% - enough to be very annoying in regular use.

1. Trying to connect to a VPN network. I have two VPN connections installed: "FortiClient SSLVPN" and "F5 Networks BIG-IP Edge Client", both reproduce the freeze. The freeze happens after their windows are visible.
2. Opening the "network adapters" window in the Windows system settings. The freeze happens before the window is visible.

So it seems like if something is done with my virtual network adapters, the freeze happens. Since opening the system settings window or a VPN client window is enough, it seems like it is related to something like a status query.
When the guest is frozen, the host task manager shows about 30% CPU usage (just above one core on my 4 core machine) for the VirtualBox process all the time. The guest is completely unresponsive, I can only do a hard shutdown.

I've attached the log files and minidump from a freeze. During this I just started the guest, waited a minute until everything was loaded, right clicked on the start menu button and clicked on "network connections". This was enough to reproduce the freeze.


My environment:

VirtualBox 5.1.6 (but the freeze was already in 5.1)
Extension pack and guest additions installed and updated to same version as VirtualBox

Host:
Windows 10 version 1511 Enterprise x64 with all updates
Intel Core i5-6600, 16 GB RAM
Network adapter: Intel I219-V

Guest:
Windows 10 version 1511 Enterprise x64 with all updates
4 cores and 6 GB RAM assigned
ICH9 chipset, IO-APIC, PAE/NX, Hyper-V, VT-x and Nested Paging enabled
Virtual network adapter: Intel PRO/1000 MT Desktop using bridge configuration

[scottgus1]

Have you tried using the guests without the VPN software installed? Not many folks seem to be reporting major network glitches with 5.1.

Although it could be a combination of the VPN and Virtualbox 5.1. I would try 5.1 and no VPN and see if the problems exist there. (Might need a fresh temporary guest for this.) If the problem is not there before the VPN is installed, but soon as the VPN is installed the problems come back, the developers might want to hear about it on the Bugtracker

Are you using NAT as the Virtualbox networking style?

[scottgus1]

Another possibility, the network card drivers for the default card Virtualbox emulates for a guest are provided by the guest OS itself. OS-provided drivers sometimes don't have the full capability of manufacturer-generated drivers. You can upgrade the network card drivers in a Virtualbox guest. Find out what kind of card the guest is using then go to that card's manufacturer and install the drivers.

[cremor]

I'll try it with a fresh guest when I get some spare time.

No, I'm not using NAT. As written in the first post, I'm using bridged networking.

I could try to find some Intel drivers for the virtual network adapter, but this shouldn't be required for normal operations, right? All driver requirements should be handled by the guest additions in my opinion.

[socratis]

All driver requirements should be handled by the guest additions in my opinion.

That would be a nightmare to maintain. That's why the drivers for the virtual hardware are left up to the guest OS. Simply the default hardware selection is such that the guest OS has native support for the presented virtual hardware.

[cremor]

Yes, of course. That's what I meant.
And since I'm using the default virtual network adapter for Windows 10 guests, the OS drivers should be fine, right?

[socratis]

Yes, they should be absolutely fine. What scottgus1 suggested is not to rely on the built-in Microsoft drivers but to install the Intel ones.

The problem lies somewhere else, most probably in the interaction between the VirtualBox and the VPN software. A couple of things you can try: 1) install VirtualBox without the bridged support, 2) install VirtualBox without the HostOnly adapter, 3) a combination of both. If that doesn't work, or if you narrow down the problem to a specific module, as scottgus1 said, head to the bugtracker.

[scottgus1]

I'm going to peg using Bridged as the possible problem for testing, and this may be because of possible code changes in 5.1. (Sorry, Cremor, I didn't see that in your first post.)

I have not tried to install true VPN software in a guest. But from what I've read in the forum on the subject, VPNs rule with an iron fist over the network connection, often not allowing anything else to work. Since Bridged puts the guest's network card in the same network as the host's network, there may be conflicts.

Since the intent is to VPN, I would try NAT, to at least get you going for now.

Of course this test does not account for the report that all this worked in 5.0, so I'm probably wrong.

If switching to NAT on 5.1 works, or if you are able to demonstrate that bridged on 5.0 works, but on 5.1 bridged does not work, then the developers would most likely want to hear about it.

[cremor]

I just got the same freeze with NAT, again just by opening the Windows network adapter configuration window after a fresh reboot. This was with 5.1.8.

I've created a ticket now: https://www.virtualbox.org/ticket/16122

[scottgus1]

Something has arisen with NAT, could be the source of you problem, see: viewtopic.php?f=1&t=80310 and viewtopic.php?f=1&t=80222&start=15#p376473
The developers are crunching on it.