Win7 -64 guest cannot use smp with 3D and aero ==> Fixed in SVN

[Perry G]

Running a Windows 7 64-bit guest with 3D and smp enabled results in an abort of the machine after a short time. Running with a single processor or without 3D enabled the guest works as designed.

In other words I can run 2 processors and no 3D or I can run 3D but only with a single processor.

I have been batteling this for a while now and can not find out why.

Attaching a guest log in a little while.

[Perry G]

I need to amend the ticket a little. The system used to abort the guest, but now it hangs with 100% - 98% of CPU if I assign 2 processors and try to use 3D (aero). Sending the shutdown signal does work but reports a BSOD on error reporting when resumed.

[Perry G]

minidump attached.

[misha]

We've fixed some concurrency issues that could cause the crash you observed on SMP guest.
Here is a test build of VBox Guest Additions with the fix: ​http://www.virtualbox.org/download/testcase/VBoxGuestAdditions_4.1.9-76698.iso

Please give it a try and let me know how it goes.

[Perry G]

Hi misha,

I gave it a try and it does close to the same thing. Instead of aborting now it freezes. Selecting pause and resume brings up a black screen in 640x480. First time I saw a BSOD when I paused and resumed so I entered the

VBoxManage setextradata "VM name" "VBoxInternal/PDM/HaltOnReset" 1

to see if I could capture it but that does not bring up the BSOD when going paused resume with that since I assume the freeze is stopping it. I can send another log file is you want. It sure looks like driver issues to me.

[Danial]

update your display driver, there were multithreaded opengl bugs that caused Vbox to freeze/crash on both windows and linux with R280.

[Perry G]

Replying to Squall Leonhart:

update your display driver, there were multithreaded opengl bugs that caused Vbox to freeze/crash on both windows and linux with R280.

I updated to the latest certified driver 295.20. and issue is actually the same.

[Perry G]

Also Windows 8 does not have this issue. Installed the guest additions and verified that Windows 8 was using the VirtualBox WDDM drivers in the device manager.

VBox= 4.1.51 (4.2) svn r40394 and GA= 4.1.9-76698 on Vista & Win7. GA= 4.1.8 on Win8

[misha]

Replying to Perryg: Could you please post me the updated minidump file for 4.1.10 of for this recent test build additions: ​http://www.virtualbox.org/download/testcase/VBoxGuestAdditions_4.1.11-76937.iso .

[Perry G]

Sure thing. It still fails but now it is listed as a BSOD and specifies X64_0xD1_CODE_AV_BAD_IP_VBoxVideoWddm+2f08

[misha]

Unfortunately we're unable to reproduce the issue here, and the minidump does not explain the crash.
Could you please try enabling the driver verifier to see if verifier complains on anything.

To do that run "verifier" from elevated console inside the guest, choose "Create Custom settings (for code developers)" -> "Select Individual settings from full list" -> Check everything except "Low resource simulation" and "Force Pending I/O requests" -> "Select driver names from a list" -> and select VBoxVideoWddm.sys, dxgkrnl.sys and dxgmms1.sys -> press Finish and reboot the guest.

In case verifier finds something it should BSOD with some verifier bugcheck. In that case please post a minidump for that crash here.
Please let me know how it goes with verifier enabled.

NOTE: don't forget to disable the verifier once you're done with testing, run "verifier" again, select "Delete existing settings" -> press Finish and reboot the guest.

[Perry G]

Sure thing. Here is the latest. I will leave the verifier on for now since I use this mainly for testing.

[misha]

Replying to Perryg: Thanks a lot. Unfortunately it's not yet clear what have caused this misbehave from the latest minidump.
Could you please upload a full memory dump to the anonymous FTP server ​ftp://ftp.oracle.com:/appsdev/incoming ?
To enable full dump generation, go to My Computer -> Properties -> Advanced System Settings -> "Settings" button under "Startup and Recovery" and select "Full memory dump" if available or "Kernel Memory dump" otherwise.
The "Dump file" edit box specifies the dump file location, which is %SystemRoot%\MEMORY.DMP by default.

Once you uploaded the dump, please post me it's name either here or at mikhail dot sennikovsky at oracle dot com so that I can pick it up.

Besides that, could you specify what steps do you do to make the system crash? Are you starting/running some apps, or just logging in, etc.?

[Perry G]

I'll do that today. Is this test done with the verifier still on, off, or does it matter?

[misha]

Replying to Perryg:

I'll do that today. Is this test done with the verifier still on, off, or does it matter?

Please do it with verifier on. Thanks a lot!

[Perry G]

HaHa well it will be later today. Windows finally got tired of it and no way will it boot now. It now bsod's on ntfs. I need to restore from backup and then make sure all updates and the like are installed.

[Jeffska]

I'm having this same issue and do have a full dump file from the last time it happened (with standard 4.1.10). I didn't have the driver verifier on though. Let me know if you want the dump.

[Perry G]

It's MEMORY.DMP.tar.gz and uploading now.

I used my restore backup which is the default install with nothing installed, not even the GAs. Installed the test GAs you had me use and did the system updates.

As for when it freezes, or reboots. It does both but all I need to do is log in and wait for Windows to settle down. First indication is a freeze. If I wait it will reboot itself. Then I have to set the processor count to 1 or disable the 3D accel. to be able to boot back in.

[misha]

Sorry for delay and thanks a lot for the dump. Using it I was able to find the issue and will provide you with a fixed test build shortly.

[misha]

Here it is: ​http://www.virtualbox.org/download/testcase/VBoxGuestAdditions_4.1.13-77291.iso please give it a try.

[Perry G]

Much better thank you. I was able to boot up and reset the verifier, dump settings, and tweak the aero settings. Looks like you found the nemesis my friend. Can you elaborate a little on what it was?

[misha]

Replying to Perryg:

.. Can you elaborate a little on what it was?

In two words, when handling a VBOXVDMACMD_TYPE_DMA_PRESENT_FLIP command in DxgkDdiSubmitCommand the driver scheduled a DPC to notify the dxgkrnl runtime about the dma command completion and do some command post-processing (see vboxVdmaGgCmdDmaNotifyCompleted), the DPC then referenced the memory buffer representing that command and did some op on it (see vboxVdmaDdiCmdHandleCompletedList).
Besides that the driver also posted additional work item to a worker thread, which did some op on the same memory buffer and then destroyed it (see vboxVdmaPipeCltCmdPut in vboxVdmaGgCmdSubmit).
Thus on SMP systems it could happen that the worker thread could process & destroy the buffer before the DPC.
Pretty silly bug, and I'm recalling now that I added that code as a temporary measure to quickly test & solve some other bigger problem we had here, but given there is no more permanent than a temporary this bug stayed for so long.. sorry about that and really glad it should be fixed now!
Once again thanks a lot for helping with hunting this bug.

[Perry G]

Thank you misha,

Now it all makes sense and spot on to what I was seeing here. Glad to help and even more glad that this ticket can be marked as solved. ;)

[misha]

Cool, thanks again :)

[Frank Mehnert]

Fix included in VBox 4.1.14.