Windows-KB890830-x64-V5.73 (current Windows malicious software removal tool) in the shared folder causes crush of the guest OS

[boxer01]

As I wrote, during the today’s Windows updates I downloaded the current version of t x64 MSRT and put it in the shared folder. As soon as I access the shared folder afterwards, the shared folder is shown empty. Shortly after that, the display (not the window) of the guest resizes to something very small like 640 × 480; couple of seconds later the BSOD happens and guest would be restarted.

I put my logs, directory listing of the shared folders and BSOD numbers in the archive. If something else is needed, just let me know. The logs clearly shows the detection of the critical condition. As soon as this file is removed from the shard folders, everything works as it should. This is Windows 10 1809 x64 guest and host combination.

[boxer01]

Logs and other information

[justinsteven]

Same for me.

• Host: Debian Linux running Virtualbox 6.0.10
• Guest: Windows 7 x64

My guest is snapshotted with Guest Additions 6.0.8. Only when I upgrade to Guest Additions 6.0.10 do the problems occur.

Worse still, for me, this seems to happen when you click on any directory in explorer.exe under \\vboxsvr\ if that directory contains a .exe file (or at least the ones I've tested)

I first noticed when I dropped a .exe installer in my shared directory and the Windows guest BSOD'd as soon as I went to \\vboxsvr\shared_directory

I've since taken the sysinternals suite, put it on my host at ~/shared_directory/sysinternals/ and split its contents into directories containing only 10 files each (with one of them actually only containing one file)

% tree
.                      
├── dir_001          
│   └── accesschk64.exe
├── dir_002            
│   ├── accesschk.exe
│   ├── AccessEnum.exe
│   ├── AdExplorer.chm 
│   ├── ADExplorer.exe
│   ├── ADInsight.chm 
│   ├── ADInsight.exe 
│   ├── adrestore.exe
│   ├── Autologon.exe
│   ├── Autoruns64.dll
│   └── Autoruns64.exe  
├── dir_003           
│   ├── autorunsc64.exe 
│   ├── autorunsc.exe
│   ├── autoruns.chm    
│   ├── Autoruns.exe    
│   ├── Bginfo64.exe
[... SNIP ...]

I've then exposed ~/shared_directory as a Shared Folder with the Windows 7 x64 guest running Guest Additions 6.0.10

When I open explorer.exe and go to \\vboxsvr everything is fine (there's a pdf, zip, and some directories)

Double-click on sysinternals and everything is fine

Single-click on any directory in there and I get a BSOD.

[Socratis]

@justinsteven

I think that you're not seeing this issue (#18704), but a new one with 6.0.10. See #18766, and also described in #18768 which is a duplicate of #18766.

[schlettydesign]

"Shortly after that, the display (not the window) of the guest resizes to something very small like 640 × 480"

This resizing of app window is happening to me, also, with VirtualBox-6.0.10-132072-OSX. Very frustrating. I can't work at this small display size. What was changed?

EDIT: I went into Settings and noticed a new control under Display called Scale Factor. I set it to 200% and now I am getting display sizing similar to v5. I subsequently found this thread: ​https://forums.virtualbox.org/viewtopic.php?f=8&t=90904

[Socratis]

@schlettydesign

Are you sure you posted in the correct ticket? Doesn't look like it...schlettydesign

[boxer01]

Replying to socratis:

I would like to report, that the newer version of the file (5.74) also causes this.

I think that this is different issue as in the two other tickets (#18766 and #18768). The first difference: I don’t have to and can’t access the executable in the shared folder. The BSOD happens already because I access the folder with the executable in it. I can’t see what in the folder, because BSOD happens as I choose the folder in Windows Explorer. But not every executable triggers this behavior, only the mentioned one.

Other difference is the code of the BSOD: in our case it’s 0x1e (KMODE_EXCEPTION_NOT_HANDLED) and not the IRQL_GT_ZERO_AT_SYSTEM_SERVICE.

@socratis: because of aforementioned differences, I think that @justinsteven also has this issue and not the other one. But in spite of the different causes the issue itself is the same in the end: something in file operations in the share folder cause the BSOD in the driver, which causes the guest display resolution reducing just before the crash.

I think that the idea in the other ticket (to publish the details of the affected and not affected systems) is very useful and do so for my systems here. Probably it would help to find the bug.

• Host: Windows 10 x64 1809 July 2019 Update (17763.615).
• Guest: Windows 10 x64 1809 July 2019 Update (17763.615).
• Share: Read-Write, NOT auto mounted.
• Result: CRASH

• Host: Windows 8.1 x64 July 2019 Update.
• Guest: Windows 7 SP1, build 7601, July 2019 Update, 32-bit.
• Share: Read-Write, NOT auto mounted.
• Result: NO CRASH

Also, probably important, because I already see how this causes some issues in other tickets: I have a NOD32 antivirus in the both guests (but please don’t start the discussion on pro and contra of such programs in the guest)

[Socratis]

Replying to boxer01:

I think that this is different issue as in the two other tickets (#18766 and #18768).

Of course! For you, even if the desktop background color is different, it's a new tikcet! :D

I think that the idea in the other ticket (to publish the details of the affected and not affected systems) is very useful and do so for my systems here. Probably it would help to find the bug

While I do honestly appreciate the report, it doesn't help if the reports are scattered across 5 different tickets and 4 different threads. The idea is to consolidate all of the reports, so that we can see easier what's common and eventually find the culprit.

So, please either post your details in #18766 or in the corresponding thread, ​https://forums.virtualbox.org/viewtopic.php?f=2&t=93359

[boxer01]

Replying to socratis:

Of course! For you, even if the desktop background color is different, it's a new tikcet! :D

Finally, somebody who understands me! :D

So, please either post your details in #18766 or in the corresponding thread, ​https://forums.virtualbox.org/viewtopic.php?f=2&t=93359

With all due socratiscasm :-) (and respect) this is different issue because it is triggered by different user operation (selecting the folder with the file and not the file itself) and causes the different BSOD number. I can’t tell, if the bug lies in the same line of code by the both of this issues, but first of all it looks slightly different to me. So this isn’t a duplicate, at least for me.

Never less, I posted my details in the linked thread in the forum.

[Socratis]

Thanks for your post in the forums. Here are a couple of things that I noticed:

• ​https://forums.virtualbox.org/viewtopic.php?f=2&t=93359#p449936 mentions KMODE_EXCEPTION_NOT_HANDLED. It also mentions 640x480 shortly before the crash, just like you.
• ​https://forums.virtualbox.org/viewtopic.php?f=2&t=93359#p449967 mentions simply accessing the shared folder, not the .exe file.

But let's continue the discussion in the forums... ;)

[maxchen]

crash and auto restart Host: linxmint 19.1 x64 gurest: windows 10 2019 ltsc x64

each time browse to a share folder: T:\2019\DL, freezed and in about 3-5 seconds the VB guest crash and restart. no crash for other folders

[boxer01]

Just tested with fresh guest additions, version 6.0.11-132500. My issue (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.

[justinsteven]

VBoxGuestAdditions_6.0.12-132672.iso fixes my instance of the issue (https://www.virtualbox.org/ticket/18704#comment:1)

I didn't try VBoxGuestAdditions_6.0.11

Thanks to all!

[Socratis]

Replying to justinsteven:

VBoxGuestAdditions_6.0.12-132672.iso fixes...
I didn't try VBoxGuestAdditions_6.0.11

Yes, you did try the 6.0.11 release. You couldn't have tried the 6.0.12 ones, because they don't exist, 6.0.12 has not been released yet. And anything between 6.0.10 and 6.0.12 (the official releases) is going to be 6.0.11.

But I'm really glad that two people reported this as working. I'm going to try and notify people in the forums...