6.0.10 r132072 crashes Windows VM when Shared Folders are used

[maravento]

OS Host: Ubuntu Mate 18.04.2 x64 VM: Windows 7 SP1 pro x64 VirtualBox version + Guest Addition: 6.0.10 r132072 UAC: disabled

Bug Description: When accessing an executable (.exe) exclusively from a shared disk, Virtualbox crash error irql zero at system service. This does not happen with Windows 10 VMs (I have not tested with other systems). Neither happens in Windows 7 if the executable is in the c: drive (desktop or directories). It also does not happen with version 6.0.8 r130520

Link Bug Video 6.0.10 r132072: ​https://mega.nz/#!vR8yRArb!xsshqGCtIqVYBxtZAiKmeuS6VNiyP_My9ggS4no9O-Y

Link Image Normal Run 6.0.8 r130520: ​https://mega.nz/#!DAFT0YzD!cEZflU3ySvgNS2cjt1R3xC4ZIP2YVR2fwqLYx6Cj1wE

[ccorn]

Similar problem here, directly after upgrading from VirtualBox 6.0.8.

Host is Archlinux (Linux 5.2.1 running on a dual Intel Xeon E5-2670 machine, 128 GiB RAM). VirtualBox version is 6.0.10 r132055 with Extension pack 6.0.10 r132072. Guest System is Windows7 professional (x64), configured with 8 GiB RAM, 4 cores. Guest additions 6.0.10 are installed.

The usual file operations on a shared folder (read/write, automatic, persistent) seem to work. Peeking into a ZIP, opening a PDF, editing an XML file, deleting a folder: works. But single-clicking on an EXE (so basically just selecting, not yet opening) results in a Bluescreen. Switching the explorer view from details to icons also results in a Bluescreen, so I think the bug is triggered by some preview attempt. That only happens in shared folders.

Deactivating Windows defender's realtime protection did not help. Rolling back the most recent Windows updates and reinstalling the VirtualBox Guest additions did not help either.

[Socratis]

I think that tickets #18768 and a report on ticket #18704(#comment1) are describing the same issue.

Replying to ccorn:

But single-clicking on an EXE (so basically just selecting, not yet opening) results in a Bluescreen. Switching the explorer view from details to icons also results in a Bluescreen, so I think the bug is triggered by some preview attempt. That only happens in shared folders.

I couldn't reproduce it on an OSX 10.11.6 host, with a Win7-32 VM, no matter what I tried. I'll try the same on a Mint19 host and on a Win10-64 host. My share is ReadOnly if that matters, I didn't see it specified in your reports...

@maravento, you're getting a 0x0000004a STOP.

@ccorn, are you getting the same STOP?

[maravento]

Replying to ccorn:

Similar problem here, directly after upgrading from VirtualBox 6.0.8.

Host is Archlinux (Linux 5.2.1 running on a dual Intel Xeon E5-2670 machine, 128 GiB RAM). VirtualBox version is 6.0.10 r132055 with Extension pack 6.0.10 r132072. Guest System is Windows7 professional (x64), configured with 8 GiB RAM, 4 cores. Guest additions 6.0.10 are installed.

The usual file operations on a shared folder (read/write, automatic, persistent) seem to work. Peeking into a ZIP, opening a PDF, editing an XML file, deleting a folder: works. But single-clicking on an EXE (so basically just selecting, not yet opening) results in a Bluescreen. Switching the explorer view from details to icons also results in a Bluescreen, so I think the bug is triggered by some preview attempt. That only happens in shared folders.

Deactivating Windows defender's realtime protection did not help. Rolling back the most recent Windows updates and reinstalling the VirtualBox Guest additions did not help either.

Provisional solution (until they fix the bug):

1. Uninstall Guest Additions 6.0.10 inside the VM Win7 and turn off the virtual machine
2. Uninstall Virtualbox 6.0.10
3. Install 6.0.8 + Extension pack 6.0.8
4. Start the Win 7 VM and install Guest Additions 6.0.8

[maravento]

Mega links removed

[XWolf Override]

The same for me on Windows 8: IRQL_GT_ZERO_AT_SYSTEM_SERVICE bsod at startup. Disabling shared folders allow me to boot.

It works perfect after updating VirtaulBox but before updating the guest additions.

[Socratis]

@XWolf Override

You're getting the same 0x0000004a STOP error (IRQL_GT_ZERO_AT_SYSTEM_SERVICE).

@ALL

• What's your host? Exactly please, including build, version, bitness (32- or 64-bit).
• What's your guest? Exactly please, including build, version, bitness (32- or 64-bit).
• What's the share type? Read-Only or Read-Write? Auto-mounted or not? Letter manually assigned or not, if auto-mounted?

Examples that I've actually tried:

• Host: OSX 10.11.6 (15G22010).
• Guest: Windows 7, build 7601 SP1, 32-bit.
• Share: Read-only, NOT automounted.
• Result: NO CRASH

• Host: Mint 19, 4.18.0-17-generic #18~18.04.1-Ubuntu SMP Fri Mar 15 15:27:12 UTC 2019 x86_64.
• Guest: Windows 7, build 7601 SP1, 32-bit.
• Share: Read-only, NOT automounted.
• Result: NO CRASH

I have a feeling that it's for Read-Write shares, where the Windows Explorer is trying to create or modify the "Thumbnails.db". I have that turned off on my Win VMs.

Related discussion in the forums: ​https://forums.virtualbox.org/viewtopic.php?f=2&t=93359

This was first reported in 2019-05-31...

[maravento]

Replying to socratis:

I think that tickets #18768 and a report on ticket #18704(#comment1) are describing the same issue.

Replying to ccorn:

But single-clicking on an EXE (so basically just selecting, not yet opening) results in a Bluescreen. Switching the explorer view from details to icons also results in a Bluescreen, so I think the bug is triggered by some preview attempt. That only happens in shared folders.

I couldn't reproduce it on an OSX 10.11.6 host, with a Win7-32 VM, no matter what I tried. I'll try the same on a Mint19 host and on a Win10-64 host. My share is ReadOnly if that matters, I didn't see it specified in your reports...

@maravento, you're getting a 0x0000004a STOP.

@ccorn, are you getting the same STOP?

Yes. All information is on the ticket described at the beginning.

[silian87]

Hello, same here (IRQL_GT_ZERO_AT_SYSTEM_SERVICE) after updating virtual box even disabling folder preview.

Host: Windows 10 64bit build 16299.547

Guest: Windows 7 64bit build 7601 SP1

[Sizy458]

the problem caused by the driver Virtualbox Guest shared folder (virtualbox additions 6.0.10)

[boxer01]

As I wrote in the other ticket (#18704), this is an issue with a slightly different cause (one have to access the executable to trigger it, not just open the folder with the executable file), but the same results. In the end one have a BSOD in the guest with a different number (IRQL_GT_ZERO_AT_SYSTEM_SERVICE and not the 0x1e (KMODE_EXCEPTION_NOT_HANDLED)), but just before the BSOD the guest video driver also crashes, which causing the resolution reduction in the guest just before the crash.

I put the additional information in the other ticket and probably we should see this difference as important.

[maravento]

I believe that Oracle already has enough information to correct this error. I don't think there is much more to contribute.

[Socratis]

Replying to maravento:

And why Oracle does not fix this bug instead of continuing to "talk" about the bug.

Where exactly did you see Oracle talking? I haven't seen any developer commenting here, have you???

Everything is already said and documented. There is nothing more to say.

Seriously now? What exactly is documented? What conclusion have you reached from the reports so far? That some people see it and some don't? That's not too much to work with, you do understand that right? Unless there's a reproducible scenario, nothing can get fixed. And I'm not talking about your case, I'm talking about a developer chiming in and saying that they've reproduced it. Till then, there will be a lot to be said...

[Wo_soll_ich_fliehen_hin?]

error code

[Wo_soll_ich_fliehen_hin?]

This is happening here as well, and it happens every time I cause the "situation".

Host: Windows 10 (1903 64bit)

Guest: Windows 7 (6.1 7601 SP1 64bit)

Settings: KVM mode, 1 or 4 CPUs, 2048Gb I/O APIC on, ICH9, VTx on, nested paging on, direct 3D is not installed.

Machine: Dell 7010, i7 3370, 8Gb Ram

Situation: Opening a shared folder in VBox, mounted as Y:/, (the Pokemon Iberia main folder, a free RPG maker mod game ​https://pokemon-iberia.fandom.com/es/wiki/Pok%C3%A9mon_Iberia_Wiki) full of programs and icons. It doesn't happen when I open other network folders full of icons, when I open other local folders or run other programs. It doesn't happen if I copy the shared folder to the guest desktop and open it from there (the game is playable in this situation).

Version: Oracle VirtualBox 6.0.10 r132072, VirtualBox Guest Additions 6.0.10.

Today I updated Oracle and Guest Additions from the previous version (6.0.8), which ran flawlessly.

Error code is showed on attached picture (bug.png).

[Bert van Hoesel]

Experiencing the same issue with VBox 6.0.10 for both host and guest additions and vboxsrv share read/write

Used hosts are 64 bit Linux Mint Mate 19.1 (amd and intel). Up to date on updates with kernel 4.15.0.54. With Guests both Windows 7 and 10 (1903). At least Win 10 is up to date!

The weird thing is that it is not happening with all exe files. For example the latest rufus 3.6 installation exe from ​https://rufus.ie/ does not expose the issue. But a system font change utility advchange.exe from ​https://www.wintools.info/index.php/advanced-system-font-changer does expose the issue. In my example as soon as the advchange.exe is in a vboxsrv shared directory the Windows 10 machine hangs on accessing the directory and reboots after a few seconds. Windows 7 gives a BSOD first. At the moment the BSOD disappears to fast to see the error. But I assume it is the same as mentioned earlier.

For me a working r/w configuration is alse vbox 6.0.10 with guest additions 6.0.8. For a r/o share 6.0.10 guest additions do work.

After experiencing a lot with different versions for vbox and additions I noticed that is did matter whether or not I rebooted the host machine. For example after testing the r/o situation and then switching to r/w to expose the problem and next switching back to r/o the issue stil exists. Tried to restart several vbox services but could not replicate a clean reboot.

Similar when down grading the guest additions from 6.0.10 to 6.0.8, again the issue was only solved after a reboot of the host.

The log snippet below from the last try where the issue was reproduced:

00:00:39.624016 GUI: UIMachineLogicNormal::sltCheckForRequestedVisualStateType: Requested-state=0, Machine-state=5
00:00:51.684516 VMMDev: Guest Log: VBOXNP: DLL loaded.
00:01:36.000458 GIM: HyperV: Guest indicates a fatal condition! P0=0x1e P1=0xffffffffc0000005 P2=0xfffff80626049b20 P3=0x0 P4=0xffffffffffffffff
00:01:36.000549 GIMHv: BugCheck 1e {ffffffffc0000005, fffff80626049b20, 0, ffffffffffffffff}
00:01:36.000550 KMODE_EXCEPTION_NOT_HANDLED
00:01:36.000550 P1: ffffffffc0000005 - exception code - STATUS_ACCESS_VIOLATION
00:01:36.000550 P2: fffff80626049b20 - EIP/RIP
00:01:36.000550 P3: 0000000000000000 - Xcpt param #0
00:01:36.000550 P4: ffffffffffffffff - Xcpt param #1
00:01:38.700119 AHCI#0: Reset the HBA
00:01:38.700146 VD#0: Cancelling all active requests
00:01:38.700655 AHCI#0: Port 0 reset
00:01:38.701710 VD#0: Cancelling all active requests
00:01:39.903206 VMMDev: vmmDevHeartbeatFlatlinedTimer: Guest seems to be unresponsive. Last heartbeat received 4 seconds ago
00:01:49.172459 VMMDev: Guest Log: VBoxGuest: BugCheck! P0=0x1e P1=0xffffffffc0000005 P2=0xfffff80626049b20 P3=0x0 P4=0xffffffffffffffff
00:01:49.172635 GIM: HyperV: Reset initiated through MSR
00:01:49.172670 Changing the VM state from 'RUNNING' to 'RESETTING'
00:01:49.175454 GIM: HyperV: Resetting MMIO2 regions and MSRs
00:01:49.175672 PIT: mode=3 count=0x10000 (65536) - 18.20 Hz (ch=0)
00:01:49.175985 Stopping the host clipboard service

I was watching the log with tail -f so I can connect actions to the time-stamps.

At 00:00:51.684516 I was logged on and started browsed some directories.

On 00:01:36.000458 I clicked on the directory containing the advchange.exe file.

[boxer01]

Replying to maravento:

And why Oracle does not fix this bug instead of continuing to "talk" about the bug.

Really often @socratis would respond here with something like: if you so clever, why didn’t you done these corrections already? Because this is open source and you could check out the code. I wouldn’t tell you such a thing, because if you would have time, space and knowledge to do this, you would probably already started to debug. I saw some god analysis and patches here in the past. But thanks god, this time the response of socratis was moderate and only tells you, that we still have not enough information.

The other answer for your question is also simple: Oracle put the resources depending on the importance of the issue and the question of paying customer dependency on the issue. So if we are lucky and this is also used by somebody who pays a real money, through licenses or support contracts, then we have a chance that this would be solved quickly. But if the big companies are unaffected by this because they use NFS shares for thing like this, then we have to wait a little bit longer.

Let me give you some examples on some of my tickets and troubles with this product in the past. The issue with the black screen in the guest after the dimming of the host display (#18592) was first reported in the mid-April and was resolved at the end of June. This is quick.

There were some other issues with the share folders. The first one is the issue with no transferring in case of the files or folders without names, just with extension (period or hidden files on Linux) (#17626). First reported by myself in March 2018, later I found some earlier tickets with the same situation. In April this year I got some extra issues with shared folders (#18566). And started with some betas of 6.0 back in November 2018 shared folders simply stop working after some amount of operations. All of this was solved at the beginning of June 2018. I took a little bit more time.

The last one are the sound crackling and de-synchronization problems due to rewrite of the sound sub-system. Started back in July 2016 in 5.1 the new design was reverted later. But it reappears with the same issue in October 2017 in 5.2 (#17225). This time the changes wasn’t reverted and it took till September 2018 to solve the biggest crackling issue. So now one can use it, but some small issues are still here, like sound would be stuck if you change the output device on the host or slight de-synchronization after some time.

So now you have a picture, and we could hope that this wouldn’t take too long to fix.

[Eddye]

Same issue here. Laptop: Lenovo G40-80 Core I7 8 GB RAM Host and Guest Disk: SSD (Shared folder is in a HDD Disk) Host: Linux 4.18.0-25-generic #26~18.04.1-Ubuntu SMP Thu Jun 27 07:28:31 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux Guest: Windows 7, build 7601 SP1, 64-bit. Share: Read-Write, Automounted, Permanent. Result: Crash with blue screen and memory dump followed by automatic reboot of the guest machine.

The issue started after Virtualbox and Guest aditions update done yesterday. I identified it when I tried to ran mputty(which are in a shared folder and in a second Hard Disk).

My workarround was to copy the exe file from the shared folder to Guest local folder. This way I can run the files.

I hope it can be solved soon.

[burghard]

Replying to maravento:

Provisional solution (until they fix the bug):

Uninstall Guest Additions 6.0.10 inside the VM Win7 and turn off the virtual machine
Uninstall Virtualbox 6.0.10
Install 6.0.8 + Extension pack 6.0.8
Start the Win 7 VM and install Guest Additions 6.0.8

I just downgraded the guest additions to 6.0.8 inside the VM and everything work as before.
Host: Mint 19.1
Guest: Win7 x64

[Fergicide]

After upgrading 6.0.8 + tools to 6.010, same result for me with Win10 host and WinServer2012R2 guest: as soon as guest sees an .exe in the shared folder, it crashes and spontaneously reboots. Have rolled back entirely to 6.0.8.

[Qu]

Same for me, both host and guest OSes are Windows 10 v.1803, when accessing shared folder VM Win 10 crashes every time. Virtualbox is v6.0.10.

[HRZ d. Universität Bielefeld]

Problem is also reproducable by me. But the effect is a little bit different: Host: CentOS 7.6.1810 with current updates/patches, Kernel ML 5.2.x, VirtualBox 6.0.10_132072_el7-1 Guest: Windows EE 10/1903 , Sophos Antivirus , Guest additions 6.0.10 / 6.0.8 The guest worked until accessing a shared folder whith Guest Additions 6.0.10. When accessing a shared folder (via Explorer or even via cms) the system freezes immediately (mouse pointer is movable, but without system reactions) and reboots without any message/error. Downgrading just the guest additions to 6.0.8 solved the problem for me.

[Bucky]

Same here. Win10 host, two Win10 guests. Both crash on attempt to browse shared folder. No error message - the guests just suddenly reboot.

No such problem with Linux guest.

[divnivan]

Apparently the same problem, but I cannot even open a shared folder with an .exe file in it. It crashes the guest Windows immediately, Win 8.1 and Win 7 both.

Here's the host system: Arch Linux local/virtualbox 6.0.10-1

Powerful x86 virtualization for enterprise as well as home use

local/virtualbox-ext-oracle 6.0.10-1

Oracle VM VirtualBox Extension Pack

local/virtualbox-guest-iso 6.0.10-1

The official VirtualBox Guest Additions ISO image

local/virtualbox-guest-modules-arch 6.0.10-1

Virtualbox guest kernel modules for Arch Kernel

local/virtualbox-guest-utils 6.0.10-1

VirtualBox Guest userspace utilities

local/virtualbox-host-modules-arch 6.0.10-1

Virtualbox host kernel modules for Arch Kernel

(I will downgrade now)

[GM 1863]

Same for me. I have two shared folders. One folder is a fisical folder of the host machine and it work correctly. The other folder is a network folder of the host machine. In the virtual machine as soon as i select that folder the virtual machine crash. The virtual machine is a Windows 7 OS and the version is 6.0.10.

[maravento]

Replying to socratis:

Replying to maravento:

And why Oracle does not fix this bug instead of continuing to "talk" about the bug.

Where exactly did you see Oracle talking? I haven't seen any developer commenting here, have you???

Everything is already said and documented. There is nothing more to say.

Seriously now? What exactly is documented? What conclusion have you reached from the reports so far? That some people see it and some don't? That's not too much to work with, you do understand that right? Unless there's a reproducible scenario, nothing can get fixed. And I'm not talking about your case, I'm talking about a developer chiming in and saying that they've reproduced it. Till then, there will be a lot to be said...

Please do not spam. My comments are for developers. If you are not one of them, why do you answer? Let those who know take over. There are already enough contributions. I hope they correct it in the next version of Vbox

[chudongyu]

Same issure here.

Host:

Manjaro 18.0.4 Illyria, Linux 4.19.60-1, x86_64.

i5-6276U, 8GB RAM

Guest:

Guest: Windows8.1 Build 9600

VirtualBox Version:

virtualbox: 6.0.10 r132055.
extension: 6.0.10 r132072.

---

VBOX 6.0.8 works fine but 6.0.10 would always crash when I open a shared folder containing some exe files. 'explorer.exe' refuses to work and cpu usage goes up rapidly. Then several seconds later the guest windows crashes.

[boxer01]

I‘ve tested my scenario (#18704) with read-only setting, then with auto-mount and then with permanent setting, adding them to others one at a time. This makes really no difference, the crash is still the same.

A put the logs of the shared folder access on the host from Process Monitor here, so developers could see what is going on there. As everybody could see, VBox sometimes goes even further to the next file in the folder before the crash. The malicious software removal tool is the only one which triggers the issue, but not always the last one which was red.

[boxer01]

Logs of the shared folder access on the host from Process Monitor

[boxer01]

Replying to HRZunibi:

Looks more like situation in “my” ticket. (#18704) Would you please look at the reason or number of the BSOD? @chudongyu, @GM 1863, @divnivan, @Bucky, @Qu, @Fergicide: could you do the same, if it possible?

[Socratis]

Replying to maravento:

Please do not spam. My comments are for developers. If you are not one of them, why do you answer?

I didn't realize that this was a closed, invitation-only club! Maybe you have something else in mind?

Are you kidding me? (if not something else?) Where did you get that idea, honesty now, that only developers can comment? With the amount of time that I've spent gathering info, merging threads, pointing people to the appropriate places, marking tickets as duplicate, seriously, are you going to try and silence me? How about other people? You're going to tell them to not comment because they're not developers and you don't like pointing out the mistakes in your comments?

This is an open source project, not a banana republic. You don't get to decide who comments and who doesn't. It's not even close to what you can and can't do. Not even the admins would talk down to a user like this.

Let those who know take over. There are already enough contributions. I hope they correct it in the next version of Vbox

1) No, there aren't enough contributions, not all can reproduce it, we have to find what's common on those that do have the problem, and 2) Yeah, I hope that they fix it with the next release, even though I'm not personally affected. But it will definitely not be thanks to your efforts...

[maravento]

Replying to socratis:

Insist: My comments and the bug described are for oracle developers. If you are not an Oracle developer, do not answer my messages or use them for other purposes.

[maravento]

Update: I have detected that the problem occurs only when we insert the Guest Additions 6.0.10 CD into the Windows 7 VM and reinstall (we update from 6.0.8 to 6.0.10)

Host: Ubuntu/Mint and derivatives

Provisional Solution: Install or upgrade to VirtualBox 6.0.10 r32072 and install Extension_Pack 6.0.10 without problems. Just avoid updating (inside the VM) the Guest Additions to 6.0.10 and leave it in 6.0.8

Unconfirmed: Debian, RedHat and derivatives, Windows Server (All versions), XP

[maravento]

provisional solution VBox_6.0.10 + Guest Add 6.0.10 + Inside VM W7 6.0.8 without updating

[BobW]

Issue is related to Antivirus scan?

Not to jump in here unnecessarily, but I am having this problem with Ubuntu 18.04 host and Windows 10 guest using guest extensions 6.0.10 like everyone else, and just noticed something I haven't seen mentioned.

I can use a shared folder that does not contain any .exe files, and having set it up as a temporary share and then bringing up File Explorer, I had my antivirus popup with a blank alert box (no message for some reason) - Emsisoft, though I don't think that matters. It never does this.

I'm wondering if this problem people are seeing is related to something an antivirus does on scanning the folder for viruses? Which, of course, would include .exe files.

Anyway, just a thought. Unfortunately, I don't have any time right now to research this, since I have an effective work-around using a scratch shared folder with no .exe files. If I need an .exe, change the extension and then copy it to the guest somewhere and change it back.

[maravento]

Replying to BobW:

Issue is related to Antivirus scan?

Not to jump in here unnecessarily, but I am having this problem with Ubuntu 18.04 host and Windows 10 guest using guest extensions 6.0.10 like everyone else, and just noticed something I haven't seen mentioned.

I can use a shared folder that does not contain any .exe files, and having set it up as a temporary share and then bringing up File Explorer, I had my antivirus popup with a blank alert box (no message for some reason) - Emsisoft, though I don't think that matters. It never does this.

I'm wondering if this problem people are seeing is related to something an antivirus does on scanning the folder for viruses? Which, of course, would include .exe files.

Anyway, just a thought. Unfortunately, I don't have any time right now to research this, since I have an effective work-around using a scratch shared folder with no .exe files. If I need an .exe, change the extension and then copy it to the guest somewhere and change it back.

Hi. BobW. I have detected the problem in a Windows 7 SP1 Pro x64 VM, without antivirus, antimalware, antiransomware or other security program (installable or portable version), however I suppose anything can happen with this bug.

[Qu]

Rolled back to 6.0.8 and all good now. So the 6.0.10 is buggy.

[bookevg]

I have some issue with Windows 7 SP1 Pro x64 VM. Also I have some issue with Windows10 1903 x64 VM but VM restarted without blue screen. So I rolled back to 6.0.8 and all good now

[GJ]

Replying to maravento:

OS Host: Ubuntu Mate 18.04.2 x64 VM: Windows 7 SP1 pro x64 VirtualBox version + Guest Addition: 6.0.10 r132072 UAC: disabled

Bug Description: When accessing an executable (.exe) exclusively from a shared disk, Virtualbox crash error irql zero at system service. This does not happen with Windows 10 VMs (I have not tested with other systems). Neither happens in Windows 7 if the executable is in the c: drive (desktop or directories). It also does not happen with version 6.0.8 r130520

Link Bug Video 6.0.10 r132072: ​https://mega.nz/#!vR8yRArb!xsshqGCtIqVYBxtZAiKmeuS6VNiyP_My9ggS4no9O-Y

Link Image Normal Run 6.0.8 r130520: ​https://mega.nz/#!DAFT0YzD!cEZflU3ySvgNS2cjt1R3xC4ZIP2YVR2fwqLYx6Cj1wE

I have exactly the same problem on a CentOS 7 host running a Windows 7 VM. Since I have downgraded to VirtualBox 6.0.8 the problem is gone!

[dinosaur0]

I have the same problem with Windows 7 Ultimate and Windows 10 VMs (64 bits for all).

I downgraded first to VirtualBox v6.0.8, not touching either the extension pack or the guest additions (both still v6.0.10's) and still got the same crashes.

Then I downgraded to the extension pack v6.0.8's, still to no avail.

Then I downgraded to v6.0.8's guest additions on all my VMs, and finally could browse my shared data folders without crashing.

Finally, I updated to VirtualBox v6.0.10 and extension pack v6.0.10, just keeping the v6.0.8 guest additions in my VMs, and things are still working fine.

Conclusion: the bug is Windows's guest additions v6.0.10.

[erwin9]

Same problem here, on Linux RedHat 7.6 as host, Windows 10 as guest, and VB 6.0.10

An interesting note:

• When installing the VM guest additions 6.0.8 over 6.0.10 to downgrade them, and then rebooting (restart action from inside the OS), the problem persists ...
• It only disappears by doing a shutdown of the VM from inside the OS, which "powers it off", and then a start on the VB Manager, that the problem really disappears after the downgrade.

[Rich DiCroce]

I've encountered this issue. It's definitely something to do with having EXE files in the directory you're trying to share. I happened to have one EXE in the directory I was trying to share. Specifically, ChromeDriver 2.38. I created a subdirectory and moved the EXE there. Browsing to the share root worked fine after that. Browsing to the subdirectory that contained the EXE caused the BSOD.

[Creat]

I can also confirm this problem. When setting a share to auto-mount, and just viewing the content I get a blue screen. It only happens the moment I scroll down to reveal the .exe file(s), so I can also confirm it has to do with some sort of access to those.

It also does NOT happen when the very same share is not auto-mounted, but manually mounted (including via windows 'reconnect at logon' during boot). I'm not sure if it only happens when specifying a drive letter, or also when leaving the field empty (but since it now seems to default to z:, not the first free letter, I can't use that so I didn't try).

Host: Win 10 x64 1903 (18362.239) Guest: Win7 x64 SP1 EN, 100% updated (whatever that means)

Vbox: 6.0.10 r132072 Guest additions: 6.0.10r132072

I did not use VBox 6.0.8, so can't say if anything changed (directly upgraded from 5.xxx, not sure which exactly).

[bricowan]

Kernel minidumps from Win 2012

[bricowan]

Had this happen after an upgrade of 5.2 VB extensions to 6.0.10. Saved minidump files. I have a more complete memory dump at ​https://drive.google.com/open?id=1qGF7b5SxcJ-wb52f4J9LX6MhI5oF2JtD

[bricowan]

Also, this only happens in windows explorer, using the command line (and not executing files from the shared folder works fine.

[EIHGB8]

VM hangs and then BSOD when accessing some folders on a file share (mapped drive) after upgrading from version 5.* to 6.0.10 r132072. Does not matter if program in folder is run from shortcut or folder viewed in Windows Explorer. It appears to track files/file names. Files can be coped to another shared folder and problem follows. If some files are deleted problem vanishes, but I cannot track it down single issue/file, as problem vanishes when get down to combination of 3/4 files.

Host and Guest are Win10.

[tedro]

Complete lockup happens as soon as Windows Explorer is used to navigate shared folder files. Tried moving shared folder to directory with few or no files and still total lockup. Problem experienced on Windows Server 2016 Standard guest on Windows 10 host and also MacOS Mojave host. Multiple guests on both hosts each with identical behavior. Command window appears to be OK, but executing a file produces a complete guest OS crash.

[boxer01]

Just tested with fresh guest additions, version 6.0.11-132500. My issue (#18704, 0x1e (KMODE_EXCEPTION_NOT_HANDLED) BSOD already on access of the shared folder) is gone, on both 6.0.11-132665 and 5.2.33-132658. Thanks to everybody who helped to get this fixed.

[LavieS]

My issue seems to fit this ticket -- my Win 10 Pro virtual machine crashes when using Shared Folders -- although some details differ from what other commenters have listed.

Host: Win 10 Home, Comodo free anti-malware security; 16GB RAM, Ryzen 3 3200G apu (4 cpu cores, 4 threads, gpu), MSI X470 Gaming Plus motherboard, Crucial MX500 500GB sata ssd (C:), three additional sata hard drives (E: M: N:).

VirtualBox 6.0.10 (trusted by Comodo as "windows system application").

Guest: Win 10 Pro + Guest Additions 6.0.10 (plus some Personalization settings such as screen saver, hide taskbar, etc), no other apps installed yet in guest; 8GB RAM, 3 cpu cores 100%, 20GB vdi on host's C: ssd drive.

Steps to reproduce guest crash:

1. Create new folder "VMshare" on host sata hard drive (E:\VMshare).
2. Use VirtualBox Manager to add E:\VMshare as shared folder S: (automount, not readonly).
3. In host, copy COMODO installation file ("Comodo CIS - cispremium_only_installer.exe", 74.1 MBytes) to the shared folder E:\VMshare.
4. Start guest and log in. (Normal Start)
5. In guest, open S: using Windows Explorer (a.k.a. "This PC").
6. At this point the guest opens the window to S: but then immediately freezes, including the guest's mouse cursor, and instead of displaying any files it just displays the Windows message "Working on it..." that normally would be displayed so briefly that one wouldn't notice it.
7. After the freeze, usually the guest machine will reboot within about 5 to 20 seconds. Sometimes it just stays frozen (doesn't reboot itself). On one occasion, the host displayed an execution error message ("VirtualBoxVM.exe - Application Error: The instruction at 0x00007FF9CD996060 referenced memory at 0x0000000000000010. The memory could not be read. Click on OK to terminate the program.") and the guest stayed frozen (didn't reboot itself). I haven't seen any BSODs.

Note: I previously succeeded with Shared Folders with two other exe files: Spybot Anti-Beacon (9.26 MBytes) and MalwareBytes (61.3 MBytes). Both installed into the guest okay and I then deleted their installation exe files from S: (or perhaps I deleted them from E:\VMshare). Then I encountered the crashes with the Comodo file. I uninstalled both Anti-Beacon and MalwareBytes to test whether the Comodo file wouldn't crash a nearly clean guest, but that didn't help.

[fduenas]

Same Bug Here. It seems to happen with 6.0.10 an latest guest Windows 10 64 but security updates- I have succesfully fixed but needed to return to 6.0.8 an removing latest security updates form the windows guest. I have one VM with windows 10 v1903 which has no fix because I cannot undone that update.

To reproduce:

1) Create a shared folder 2) access any exe installer like 'access 2010 engine' or any other setup exe file 3) the screen and VM freezes

[sunlover]

Does the crash happen with latest 6.0 guest additions from https://www.virtualbox.org/wiki/Testbuilds ?

[agoeb]

Replying to sunlover:

Does the crash happen with latest 6.0 guest additions from https://www.virtualbox.org/wiki/Testbuilds ?

Just tried with guest additions 6.0.11-132749, and the crash does not happen anymore.

Also: It did not only happen on executables, but also on certain DLLs in shared folders.

[Edit: Cannot reproduce anymore, so I assume it was indeed fixed witih guest additions 6.0.11-132749. Modified my comment accordingly.]

[Martin Wildam]

Same issue with Windows 2003 Server guest on Ubuntu 18.04 and Virtualbox 6.0.10 r132072. Problem does not occur when Guest additions do not get updated and stay on 6.0.8.

[Martin Wildam]

I have created a VBScript with several tests (folder, file, network access) and it works smoothly on "local" drive (within the VM) but creashes when trying to run an exe from the shared folder (security exceptions in Windows are set which would allow running the exe from network drive). I also tried browsing through network drive and I got the bluescreen immediately when browsing to a directory that contains executables.

[DigiHawk]

Running on MacOS Host (10.14.6) with Windows 7 Ultimate SP1 guest on 6.0.10. Was having the same issue, a shared folder with an .exe inside it would crash my guest (blue screen of death). Rolling back to 6.0.8 seems to have solved it.

[retsi]

Hello I confirm it seems to be a bug in shared folders used by a Windows10 guest with some .exe files (virtualbox v6.0.10 r132072 with same version of extension pack and addons v6.0.10). Not on all .exe files were concerned, but it always appeared in a big folder with 3000 files. With same version of Virtualbox and extension pack, everything is now OK after installing addons v6.0.8. Perhaps a bug only in addons W10 v6.0.10 ? Best regards

[Martin Wildam]

Definitely does not only happen in W10 - I have already mentioned, that same also under older Windows 2003 server (which worked fine with v6.0.8) and definitely also with far less than 3000 files in a folder. As agoeb mentioned - happens under several circumstances. I also tried totally different executables than LavieS did. I experienced the BSOD even only by opening the network folder in Explorer, containing some executables (one level above I could see the folder contents - even more files - but no executables).

[Socratis]

In case you missed it, because I see reports with the standard 6.0.10 and return to the 6.0.8 GAs...

sunlover asked you to try the Test Builds:

Does the crash happen with latest 6.0 guest additions from https://www.virtualbox.org/wiki/Testbuilds ?

[sunlover]

To clarify: the crash should be fixed in guest additions *6.0.xx_r132480* or newer.

If you still experience the crash with the latest testbuild (https://www.virtualbox.org/wiki/Testbuilds) then attach the corresponding VBox.log.

[VBUser1]

I've updated VB today and received the same error. I had no problem with the former release of VB. Hopefully Oracle will fix this soon.

For me the following workaround helped: I removed the shared folder and setup a host-only network for the VB. After that I shared a folder in the host machine and used this folder in the VB-Client as a network folder. I was than able to read from- and write into that folder.

[Damon Harris]

Replying to sunlover:

To clarify: the crash should be fixed in guest additions *6.0.xx_r132480* or newer.

I can confirm that VBoxGuestAdditions_6.0.11-132749.iso solves the issue atleast in my Windows 10 guest :)

[me-kell]

I can confirm too that Version 6.0.11-r132799 with guest Windows 10 Enterprise and host Windows 7 don't crash on this issue.

[abletech-sb]

I can confirm resolution on a Windows 10 guest, updating to VBoxGuestAdditions_6.0.11-132749.iso

[Martin Wildam]

I can either confirm fix with latest guest additions test build (VBoxGuestAdditions_6.0.11-132749.iso) on Ubuntu 18.04 host with Windows 2003 Guest. Thanks to everyone involved.

[HRZ d. Universität Bielefeld]

The fix from VBoxGuestAdditions_6.0.11-132749.iso is working for me. Problem resolved.

[shmu26]

The issue was solved for me, too, by updating to VirtualBox-6.0.11-132749, and then installing the GuestAdditions that was offered.

[jjc1921]

Oh, thank goodness I found this.

I've been having Windows guest bluescreens whenever I open a project in Visual Studio over Shared folders for a week now. I upgraded from Win 7 to 10 and I reinstalled 10 fresh like 3 times to no avail. I had one other VM which didn't have this issue but it seems likely now that I must never have updated its guest additions when I was testing it.

Note: The version of Visual Studio didn't matter. 2010/2017/2019 all caused the crash.

I've now upgraded to V 6.0.12 r133076 with a Ubuntu 18.04 host.

The update still bluescreens when trying to open the project on Win10 however when I restored a snapshot to Win7 and updated the guest additions. I was able to open the project without a crash.

Would providing details for Windows 10 help anyone.

[Socratis]

@jjc1921

If the update to 6.0.12 still crashes your Win10 VM, but not the Win7 VM, then most probably you're facing a different issue.

I would suggest to post the details about this on the ​VirtualBox forums, a lot more eyes there. More than 95% of the issues are resolved in the forums, which keeps the developers focusing on the bug fixes and enhancements, and there is no need for another ticket to keep track of.

[jjc1921]

@socratis Thanks

[Martin Wildam]

Tested Windows 2019-Server guest with 6.0.12 on Ubuntu 18.04 for the given issue and cannot reproduce. Cannot either reproduce on Windows 2008r2 guest any more. So I think @jjc1921, you are having a different issue. However, I don't have Visual Studio, so cannot test exactly your situation.

[dmz73]

Win10 guest crash log when accessing shared folder on Win10 host

[dmz73]

I have just had a crash happen with latest virtualbox 6.0.12 upgraded from 6.0.10 with latest extension pack 6.0.12 and guest tools installed. Host is Windows 10 and guest is Windows 10. The issue occurred on multiple computers with Windows 10 upgraded to latest version in guest and 1903 and 1809 on the host. Attaching a log from latest crash.

[Socratis]

Replying to dmz73:

00:00:04.471633 AIOMgr: Endpoint for file 'C:\VirtualMachines\DevWin10\DevWin10-SysVol1-s257.vmdk' (flags 000c0723) created successfully

Are you sure you have enough VMDK chunks? I don't think I've ever seem a 258-chunk VM before... :D

virtualbox 6.0.12 upgraded from 6.0.10 with latest extension pack 6.0.12 and guest tools installed

00:00:02.392627 VirtualBox VM 6.0.10 r132072 win.amd64 (Jul 12 2019 09:34:54) release log
00:00:02.438210   Oracle VM VirtualBox Extension Pack (Version: 6.0.10 r132072; VRDE Module: VBoxVRDP)
00:00:11.321078 VMMDev: Guest Additions information report: Version 6.0.10 r132072 '6.0.10'

First of all, just so that we don't get lost with the improper terminology, there's no "guest tools", there's "Guest Additions".

And no, you do not have the latest VirtualBox, you haven't actually updated the ExtPack on your host, neither the GAs on your guest. Expect BSODs until you do...

[hexaae]

I still have this issue: host Win 10 Pro 1903, Guest Win 10 Pro 1903 + Guest Additions. If I uninstall Guest Additions there are no BSODs on the guest.

[yesyesyes]

I have the same issue but have found that the shares sometimes work and sometimes crash the virtual machine.

If I create a share and place one particular file in it, accessing the file from within the virtual machine will cause it to crash. The file is: jdk-12.0.2_windows-x64_bin.exe

Other executable files can be placed in the share without problem, as can a text file, but if this file is in the share, either alone or with other files, accessing the share cause the virtual machine to crash and restart.

My workaround has been to put the files on a USB thumb drive and mount that. Then the file can be accessed without problem.

Hopefully the dev team will be able to reproduce the problem and develop a fix.

[Socratis]

@yesyesyes

Do you happen to have any 3rd party antivirus on the host and/or the guest?

[yesyesyes]

@socratis

Malwarebytes Anti-Malware, is on the host only.

[Socratis]

@yesyesyes, can you uninstall it? And I mean completely uninstall it, not just disable it, that might not be enough.

If that's not an option, see if you can add an exception for ALL things VirtualBox, and your VM files.

[yesyesyes]

@socratis

I'm traveling so don't have another machine to experiment with. I wouldn't even begin to contemplate reducing security to compensate for buggy software.

Accessing the file via a USB drive shows that all is fine with the security software and with the file I'm trying to access. Hopefully the Oracle dev team will fix their problem.

Another option might be to go back to an older version of Virtualbox. I wonder if the virtual machines will still work with an older version? anyway, that's not something I can try until next month, on a separate computer.

[Socratis]

Replying to yesyesyes:

I wouldn't even begin to contemplate reducing security to compensate for buggy software.

Which one is the buggy software? How sure are you about it? I'm trying to eliminate all potential culprits, and antivirus software has been shown time and again to cause problems. Also, you definitely don't compromise your security if you stick with the built-in antivirus. You definitely don't need a 3rd party antivirus.

Accessing the file via a USB drive shows that all is fine with the security software and with the file I'm trying to access.

Not really, that's a completely different mechanism for accessing the data, that doesn't prove anything so far.

... that's not something I can try until next month, on a separate computer.

Chances are that a different computer will most probably yield a different result.

[yesyesyes]

In this case the buggy one for me is the one that has been 'upgraded' and which now crashes without warning in a known and reproducible way while the other software and files work as expected.

It's not as if I started the thread.

Maybe Oracle will find and fix it, or maybe they won't. Perhaps they will test the scenario detailed. I have a workaround for my needs. Hopefully that will be the only problem in what is otherwise very useful and functional software.

[Socratis]

Replying to yesyesyes:

In this case the buggy one for me is the one that has been 'upgraded'

So, if you downgrade the issue goes away? Just downgrading the GAs would be enough (I think), otherwise try to downgrade both the VirtualBox installation on your host and the GAs on your guest.

Maybe Oracle will find and fix it, or maybe they won't.

The truth of the matter is that the issue seems to have been fixed for the majority of the users, with the exception of you and 'hexaae' (without any further details). And Oracle has verified it in its own test machines. So, something is not-standard in your setup, and I'm trying to find out what. I had an idea about the existence of an antivirus, because they've been known to interfere. If you don't want to help in the triage of the issue I can understand it. But don't expect that something will be addressed, if that something cannot be easily replicated.

[yesyesyes]

No I haven't said I have downgraded. I just pondered that it might be a future option - to go back to 5.2.

'The truth of the matter' is that this bit of Oracle software has been buggy lately - and obviously some bugs still exist.

As I have a work around that meets my current needs I'll leave it with Oracle to address these quality issues.

[Martin Wildam]

@yesyesyes: Please, do not generalize. You could substitute Oracle with pretty every other software vendor in your post and you will be right. Things are getting worse unfortunately. You are still heard here which I find pretty good. So let's try to contribute and maybe you could deactivate your antivirus just for few minutes (you may take your maschine off the net during this test) to test if that helps. Then that does not mean nobody is going to fix it in Virtualbox, it just may mean that the crash could happen if some other process is blocking the file and then maybe somebody can either reproduce this in a lab and THEN finally there is a chance to get it fixed.

[sunlover]

I can only repeat what was already said many times: If you still experience the crash with the latest testbuild (https://www.virtualbox.org/wiki/Testbuilds) then *attach the corresponding VBox.log*.

[gombara]

Replying to yesyesyes:

@socratis

I'm traveling so don't have another machine to experiment with. I wouldn't even begin to contemplate reducing security to compensate for buggy software.

Accessing the file via a USB drive shows that all is fine with the security software and with the file I'm trying to access. Hopefully the Oracle dev team will fix their problem.

Another option might be to go back to an older version of Virtualbox. I wonder if the virtual machines will still work with an older version? anyway, that's not something I can try until next month, on a separate computer.

We are a relatively small team developing and maintaining a feature-rich, multi platform software. It is free and open source which is a great contribution to community. Instead of getting aggressive and impolite about each and every bug you run into you can do your best to provide information which will help us hunt down and eliminate the problem. That said filing a bug report (no matter how complete and crucial it seems to the reporter) does not guarantee that it will be taken care off immediately (or ever). As usual we have more bugs than developers and we have to prioritize. If you are suffering so much because of the bugs maybe you have to consider using some other solution for your use case.

[yesyesyes]

Replying to sunlover:

I can only repeat what was already said many times: If you still experience the crash with the latest testbuild (https://www.virtualbox.org/wiki/Testbuilds) then *attach the corresponding VBox.log*.

Great news - that now works!

Version '12' had still failed but that version '13' shares the files without issue. I can copy any binary file from the share to the client's C: drive and they then execute.

Was that work already in progress?

One thing that was a bit different; When I did the "Insert Guest ...CD..." on the client it DID NOT autorun. I went to the CD drive on the client and double clicked the .EXE which then ran in the usual way.

Anyway - Thank you.

[Bert van Hoesel]

Happy to report another successful test with the 6.0.12 VBox install with the 6.0.13 guest additions on my config (Linux Mint Mate host and Win7 and Win10 guests, details in comment 15). The 6.0.12 guest additions did not solve the issue!

[Socratis]

Hmm... two people are now reporting a failure with 6.0.12 and a success with 6.0.13. My "educated" guess would be that there were a couple of corner cases that weren't addressed with 6.0.12, but got fixed after that release.

Thanks to both for reporting back, I'll start suggesting the test builds, just to play it safe...

[dmz73]

I have installed the correct virtual box version and extensions and I assumed that log file with .1 was one that would have the crash info and current log file was new but it seems that was not the case. Now I have attached VBox.log.2.zip which shows the correct version of virtual box and I hope has the crash log, I can't tell just by looking at it. I have since reverted back to 5.2.32 which seems to work without crashing when accessing shares on all the same host and guest combinations so it's not the host or guest OS problem.

Replying to socratis:

Replying to dmz73:

00:00:04.471633 AIOMgr: Endpoint for file 'C:\VirtualMachines\DevWin10\DevWin10-SysVol1-s257.vmdk' (flags 000c0723) created successfully

Are you sure you have enough VMDK chunks? I don't think I've ever seem a 258-chunk VM before... :D

virtualbox 6.0.12 upgraded from 6.0.10 with latest extension pack 6.0.12 and guest tools installed

00:00:02.392627 VirtualBox VM 6.0.10 r132072 win.amd64 (Jul 12 2019 09:34:54) release log
00:00:02.438210   Oracle VM VirtualBox Extension Pack (Version: 6.0.10 r132072; VRDE Module: VBoxVRDP)
00:00:11.321078 VMMDev: Guest Additions information report: Version 6.0.10 r132072 '6.0.10'

First of all, just so that we don't get lost with the improper terminology, there's no "guest tools", there's "Guest Additions".

And no, you do not have the latest VirtualBox, you haven't actually updated the ExtPack on your host, neither the GAs on your guest. Expect BSODs until you do...

[Socratis]

Replying to dmz73, from comment #86:

• The last/current log is the "VBox.log".
• The log from the previous "Start the VM"/"Stop the VM" cycle is "VBox.log.1".
• The log from the previous-previous "Start the VM"/"Stop the VM" cycle is "VBox.log.2".
• The log from the previous-previous-previous "Start the VM"/"Stop the VM" cycle is "VBox.log.3".

So, your .2 log isn't that helpful I'm afraid, it still shows the 6.0.10 GAs...

Again... download the latest test build, install the test build, update the GAs, shutdown the VM. Then try from a VM "cold-boot", i.e. not paused or saved-state.

PS. You don't really have to quote the whole message verbatim, edit it first and keep the relevant parts, if any. Otherwise it simply adds unnecessary length to the thread... ;)

[ccox]

Logs before and after upgrade crashed Windows 10

[ccox]

I am also seeing persistent crashes with Windows 10 VM on a MacOS host after upgrading from 6.0.10 to 6.0.12 and 6.0.13 (tested after advice above). Unfortunately this has brought a lot of my compiler testing to a halt.

I have not been able to update the GuestBoxAdditions because I cannot run the Windows 10 VM long enough to install the new ones.

I have attached a zip of log files for the Windows 10 VM from before and after upgrading to 6.0.12 and 6.0.13.

[paulson]

Replying to ccox:

I am also seeing persistent crashes with Windows 10 VM on a MacOS host after upgrading from 6.0.10 to 6.0.12 and 6.0.13 (tested after advice above). Unfortunately this has brought a lot of my compiler testing to a halt.

I have not been able to update the GuestBoxAdditions because I cannot run the Windows 10 VM long enough to install the new ones.

ccox: If you remove the configured shared folders from the VM via:

Settings -> Shared Folders

in the VirtualBox GUI before starting your Windows 10 VM does that allow the VM to boot? The fix would be in the Guest Additions (GAs) so you need to update the GAs to at least 6.0.12. The logs show the GAs still at 6.0.10.

[ccox]

Replying to paulson:

Yes, I tried those steps, but the 6.0.13 Guest Additions installer hits an error from VBoxDrvInst.exe and hangs the installer. I'll see if I can reinstalll 6.0.12 and try that. Nope, same bug in the 6.0.12 installer (starting to wonder who tests these builds). Uninstalling the guest extensions, rebooting the VM, then attempting to install the 6.0.12 guest extensions got the same installer error and hang. So now I'm kinda stuck being unable to test MSVC properly because someone failed to test VirtualBox properly.

Also, if the newer VirtualBox kills VMs because of an interaction with the shared drives - that is a major bug in VirtualBox that needs to be fixed ASAP (no, a multistep workaround is not acceptable - fix the bugs).

[maravento]

Solved! 6.0.14

[maravento]

Solved! v6.0.14 r133895. Close ticket

[maravento]

Solved! 6.0.14