We need to see a complete VBox.log, from a complete VM run, where the problem occurs:

Start the VM from cold-boot (not from a paused or saved state) / Observe problem / Shutdown the VM (force close it if you have to).

With the VM completely shut down (not paused or saved), right-click on the VM in the VirtualBox Manager and select "Show Log".

Save only the first "VBox.log", ZIP it and attach it to your response. See the "Upload attachment" tab below the reply form.

If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.

I removed additions completely - without additions guests works fine - i can shut it down without any issues.

Then I installed 6.0.6 additions and problem returns - on shutdown i have kernel panic and I am forced to manually power off virtual machine (looks like it hangs) with screen showing info you can see in my previous post.

I was poking around and I think I identified what is causing the issue. Guest system halts with kernel panic on reboot/shutdown when run with additions 6.0.6 and with added shared folders. When I remove shared folders everything works perfectly.

Please note that it was not the case with additions 6.0.4 where everything worked as expected

To rule out any quirky issues with my debian installation I tried it with fresh install (standard 64bits latest debian stretch) - and it behaves exactly the same. Latest additions make system to panic on reboot/shutdown if shared folders are present.

I can confirm this behaviour using my up-to-date Debian 9 guest on a macOS 10.14.3 host. I'll try one of the latest test builds of the GAs next to see if the devs have already found and fixed it. If not, I'll dig through the backtrace and see if I can see what is causing it.

Update: I have tried Guest Additions 6.0.7 r130061 and the problem persists.

-Andy.

My crystal ball is currently broken. If you want assistance you are going to have to give me all of the necessary information.Please don't ask me to do your homework for you, I have more than enough of my own things to do.

Thanks for checking. I am downgrading then to 6.0.4 because I noticed that panic at the shutdown causes sometimes disk data corruption - probably happens before all buffers are flushed to disks. Too risky to use it like that.

I, too, am seeing this exact problem. Guest Additions 6.0.6 with shared folders (not auto-mounted) on debian-stretch-netinst.Since its reported this showed up between Guest Additions 6.0.4 and 6.0.6, has any looked at the source diffs to see if anything obvious jumps out?

I have tried the latest build (VirtualBox-6.0.9-130662-OSX and Oracle_VM_VirtualBox_Extension_Pack-6.0.9-130662) and the issue is not fixed.

As long as my Debian clients use 6.0.4 extensions everything works regardless of VirtualBox version.

After upgrading extensions to anything above 6.0.4 and in case I have shared folders Debian hangs on shutdown/reboot. With 6.0.9 there is no kernel panic message - just black screen with virtual machine in status running.

As I use Debian extensively for multiple of projects I would like this issue to be fix. Is there any ticket raised? I am happy to raise ticket myself but no point if it is already done.

Thanks for the updates, I added the ticket information in the first post/thread title. I'm also going to move this to the "Linux Guests" area from the "OSX Hosts" one, because it's the guest that has the problem, not the host.

If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.

The developers have reproduced the issue, that's a GoodThing™. See comment #4 in ticket #18667 for more info.

If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.