VirtualBox

Ticket #15662 (closed defect: fixed)

Opened 14 months ago

Last modified 2 months ago

Shared Folders freeze under pressure

Reported by: PierreYager Owned by:
Priority: critical Component: shared folders
Version: VirtualBox 5.1.2 Keywords: freeze
Cc: Guest type: Windows
Host type: Windows

Description

I have a Windows 7 development box for my main project. I use shared folders to build the release executable (Delphi code, Git, Finalbuilder to create the installation package).

When I start the build under VBox 5.1.2, at a point in time, something freeze. The shared folders seems "disconnected" (visible from the windows explorer but not browseable anymore). And I can't shutdown the guest OS. Have to kill it from VirtualBox Manager GUI (or by clicking the "close" button)

Host is Windows 10 1607 v14388.0 Guest is Windows 7 Pro (updates applied)

With VirtualBox 5.0.26 (and below) it works. With VirtualBox 5.1.2 it fails even with Guest Additions 5.0.26.

Attachments

Windows 7 Pro-2016-07-22-10-45-32.log Download (126.4 KB) - added by PierreYager 14 months ago.
Guest OS log

Change History

Changed 14 months ago by PierreYager

Guest OS log

comment:1 Changed 14 months ago by akhameole

I have the same issue, but with host Ubuntu 16.04. Whole OS gets stuck after accessing shared folders. Windows 7 and Windows server 2012 guests are affected, but Windows XP seems to work fine.

The issue began after upgrading from 5.0.24 to 5.1.0. Upgrading from 5.1.0 to 5.1.2 didn't do any difference.

Last edited 14 months ago by akhameole (previous) (diff)

comment:2 Changed 14 months ago by jds86930

I'm having the same issue. Host is Windows 7 x64, guest is Windows 7 x64. I've seen this issue with VB 5.1.0 and 5.1.2. Downgraded to 5.0.26 & it was fine. In my case, the guest is issuing lots of file reads & directory scans of shared files files/folders (no writes).

comment:3 Changed 14 months ago by akhameole

More details about my issue: Shared folders works fine on 32bit guests (Win7, WinXP). Freezing problems appears only with 64bit guests (Win7, Windows server 2012)

Last edited 14 months ago by akhameole (previous) (diff)

comment:4 Changed 14 months ago by Dariusz

I have the same issue with 5.1.0 and 5.1.2. The last working release is 5.0.26.

It only happens when shared folder is used e.g. copying files from/to it. But then after some time it happens 100% times.

I run Win 7 Pro 64-bits guest on OS X host (10.11.6).

comment:5 Changed 14 months ago by redox

I have the same issue with 5.1.2.

I run a Win 10 64-bit guest on an arch linux host.

comment:6 Changed 13 months ago by kschleisiek

I have exactly the same problem:

Host ist ubuntu_12. The "freezing shared files" only happens on Win7_64 guest, Win7_32 and WinXP_32 guests work fine. Will downgrade to VB 5.0.28. Have not yet checked the behaviour of ubuntu_16 64 bit guest.

comment:7 Changed 13 months ago by Martin HAaß

Same problem here on VBox 5.1.2, host: debian testing x64, guest: win8.1 pro x64. VBox release 5.0.24 works

Last edited 13 months ago by Martin HAaß (previous) (diff)

comment:8 follow-up: ↓ 9 Changed 13 months ago by Dariusz

No change with 5.1.4 release. Still the same issue

comment:9 in reply to: ↑ 8 Changed 13 months ago by redox

Replying to Dariusz:

No change with 5.1.4 release. Still the same issue

I can also confirm this.

comment:10 follow-up: ↓ 11 Changed 13 months ago by sunlover

I've reproduced this hang twice. But it takes quite a long tome to reproduce. Now the VM runs over weekend, zipping files on shared folder without a hang.

Could anyone please test if the problem is reproducible when using Guest Additions 5.0.x with VirtualBox 5.1.4 host? Thanks.

comment:11 in reply to: ↑ 10 Changed 13 months ago by redox

Replying to sunlover:

Could anyone please test if the problem is reproducible when using Guest Additions 5.0.x with VirtualBox 5.1.4 host? Thanks.

Still reproducible with Arch Linux (kernel 4.7.1) and VirtualBox 5.1.4 with Guest Additions 5.0.24r108355.

Compiling files which sit in a shared folder freezes the folder in just a couple of seconds for me (object files were also written to the shared folder).

Last edited 13 months ago by redox (previous) (diff)

comment:12 Changed 13 months ago by lefty

Same here with Win10 (host) & Win7 (guest). If happening, it's usually not possible to shutdown the guest cleanly. Downgrading to VirtualBox 5.0.26 solved this quite annoying issue.

Seems that not pressure causes the problem, but moving focus from the guest to another application during IO on the shared folder.

comment:13 Changed 13 months ago by Dariusz

Does anybody know if this issue is on VBox developers radar? So far I have not seen any comment from them.

comment:14 Changed 13 months ago by frank

It is. sunlover is a VBox developer.

comment:15 Changed 13 months ago by emperor

I can corroborate this problem on a 64-bit Gentoo host with a 64-bit Windows 7 Guest OS. 5.0.24 and below is OK. Beyond 5.0.24 exhibits problem with heavy shared folder access.

comment:16 Changed 13 months ago by strenix

I have the same issue. I tried to delete folder with 9000+ files, all shared folders became inaccessible, I was not even able to shutdown the OS, I needed to force shutdown from the host. The issue is perfectly reproducible in my setup. Guest OS: Windows 7 CZ (latest updates till the date); Host OS: Ubuntu 12.04.5 LTS (linux kernel 3.13.0-95-generic); Virtual Box version: 5.1.4; Both VB guest additions and VB extension pack installed. Architecture x64 (both guest and host).

Last edited 13 months ago by strenix (previous) (diff)

comment:17 Changed 13 months ago by juozapyne

Same here Windows 10 64 bit as host and windows 7 64 bit as guest. When fast downloading torrents it freezes. Thanks got I found this issue and downgraded to 5.0.26

comment:18 Changed 13 months ago by ageinfo

Same problem

Downgrade to 5.0.26 solve the problem

comment:19 follow-up: ↓ 20 Changed 13 months ago by Frykky

same problem with 5.1.4

comment:20 in reply to: ↑ 19 Changed 13 months ago by lalex86

Same here 5.1.4. Happy to see i'm not alone :)...it's very frustating all the RESET i have to do in the middle of the work.

comment:21 Changed 13 months ago by frank

  • Priority changed from major to critical

comment:22 Changed 13 months ago by sunlover

The problem is not fixed in VirtualBox 5.1.6.

comment:23 Changed 12 months ago by JackieKu

Same here with Gentoo host and Windows 8.1 64-bit guest. My use case is running uTorrent and seeding a lot of files from a share folder. 5.0.26 host is also fine here, even with 5.1.4 guest additions.

Last edited 12 months ago by JackieKu (previous) (diff)

comment:24 Changed 12 months ago by Kyo

Same problem, but guest is a WinXP 32bit

comment:25 follow-up: ↓ 26 Changed 12 months ago by sunlover

The hang is fixed in latest VirtualBox 5.1 guest additions (5.1.x revision 110849+) from https://www.virtualbox.org/wiki/Testbuilds

The bug was in the guest additions. VirtualBox 5.1 increased probability of triggering the bug.

Please test. Thanks.

comment:26 in reply to: ↑ 25 Changed 12 months ago by Kyo

Thanks sunlover, so far no more freeze in the WinXP 32bit guest.

comment:27 Changed 12 months ago by J. Fry

Seems to have solved my problems as well. Thanks for the fix!

comment:28 Changed 12 months ago by frg

If the fix is simple any chance to get a 4.2.37 guest additions build? For Vista and 7 guest additions after 4.3.13-93752 are just sluggish when enabling 3D. 4.2.36 work very well there if you only want to enable Aero and do some light work.

I practically hung my 7 VM with heavy load using the new additions.

comment:29 Changed 12 months ago by sunlover

comment:30 Changed 12 months ago by frg

Great. Big thanks. Much appreciated.

As a side note: I cleaned out all older files in the guest and reinstalled 110849. The 110849 additions are now behaving much better. I think I might be able to switch to the current line in the near future.

comment:31 Changed 12 months ago by Dariusz

Win 7 Pro 64-bits guest on macOS host seems to work now without any issues with shared folders.

I have tested with the latest Vbox (5.1.7-110927) and additions (5.1.7-110861) testbuilds.

Thx!

comment:32 Changed 11 months ago by frank

  • Status changed from new to closed
  • Resolution set to fixed

Fix is part of VBox 5.1.8. Please make sure to upgrade the Guest Additions.

comment:33 Changed 10 months ago by hmijail

I am seeing some similar behavior in VirtualBox 5.1.8 r111374. Guest Ubuntu 16.04, Host macOS Sierra 10.12.1, current Guest Additions installed. I'm using Eclipse to build sources (about 100 files) in a shared folder; it is about 3x slower than building on the command line (I assume Eclipse is indexing or whatever in the background during the build), and frequently something gets stuck in Eclipse (one core at 100% with a "Java" process) so it can't be closed correctly.

At that point, killing the Java process, or even shutting down the whole Linux guest doesn't work; it just blocks forever.

Interestingly, the VM doesn't report the CPU usage, and even after pausing the VM the VirtualBox process in the host still keeps using 100% of one core.

At that point, one can save the VM, close VirtualBox and reopen it, and the VM works.

So it looks like the sharing folder mechanism is getting stuck in the host-side part of VirtualBox.

comment:34 follow-up: ↓ 35 Changed 10 months ago by frank

Sorry, Ubuntu guests are a different issue, see #14089.

comment:35 in reply to: ↑ 34 Changed 10 months ago by hmijail

I'll move it there, thank you.

comment:36 Changed 2 months ago by DanielB

Is there an update to this issue? I'm having the exact same problem, the shared folder suddenly freezes and there's no other way to make it work but to kill the vm (shut down won't work).

Host: macOS Sierra 10.12.5 Guest: Windows 7 Professiona SP 1, 64 Bits VirtualBox: 5.1.22 r115126 (Qt5.6.2)

comment:37 Changed 2 months ago by DanielB

  • Status changed from closed to reopened
  • Resolution fixed deleted

This issue continues to happen to me, even after upgrading to 5.1.24 r117012 (Qt5.6.2)

comment:38 Changed 2 months ago by sunlover

  • Status changed from reopened to closed
  • Resolution set to fixed

DanielB, the originally reported problem has been fixed. There is no need to re-open the old ticket even if you experience a similar issue.

Open a new ticket, attach VBox.log of the frozen VM session and provide at least some info about the issue (when it happens, etc), if you want someone to look at it.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use