Constantly get VIDEO TDR FAILURE (VBoxWddm.sys failed)

[GottaGetem]

I'm running a Linux host with Windows Guest, using 3 monitors, running 1440p resolution.

The system will run fine for several hours, then suddenly and without changing anything in particular, all 3 monitors go BLACK, the windows jump around and flicker, and sometimes it will recover. However, usually, it will fail to a BLUE SCREEN OF DEATH and show this

Stop Code: VIDEO TDR FAILURE
What failed: VBoxWddm.sys

Screenshot attached. I have the video memory set to the max at 256mb.

This is really bumming me out because it is happening almost daily, and I need windows for work, but don't want it as my primary host.

I have Guest Additions installed.

Full log is attached from first vbox.log tab, zipped, after shutting down immediately following the blue screen.

Any help is greatly appreciated because virtualbox has been great otherwise.

[GottaGetem]

Did I post this in the wrong forum section? I was really hoping for some help with this issue.

[mpack]

Not every problem you encounter inside a VM is caused by the VM. In this case I suggest that you search the web for information on "VIDEO TDR FAILURE". The top hit is a YouTube video claiming to provide a fix, but I don't have the problem so I can't verify anything. I notice that the guys say the problem is with Intel graphics, but that has to be bs since the DLL mentioned is named nvxxxxxx, i.e. it's an NVidia DLL. His fix may still be valid even if his diagnosis is not.

FYI: when you enable 3D acceleration in a VM, the virtual GPU inside the VM sends your requests to the host graphics card using it's OpenGL API. That is why host graphics DLLs are relevent to the VM, and why it would show up as a crash in the VirtualBox graphics driver. The guest OS's crash handler certainly couldn't reference a process that runs on the host PC.

[erdeslawe]

TDR is the Timeout, Detection, and Recovery component in Windows. This type of crash usually occurs when the Graphics Display driver for the installed graphics card stops responding and can't be restarted by the OS. The most common reason for the problem is that the graphics device is being overloaded, i.e. used beyond its capabilities and occurs most often when playing graphic intensive games, but can also caused by any process that uses a large amount of graphic resources, such as when editing or creating videos.

The graphics card you are using in the VM is a relatively basic virtual device; and not the real one installed on the host machine. It might help if you described what you were doing when the Crash(es) occur as someone with a more in depth knowledge of VirtualBox might have more to offer. Do the crashes usually coincide with some graphics intensive activity/screen activity on multiple monitors? If so then you may need to lower your expectations of the power/capacity of a Virtual Machine.

[socratis]

00:00:01.738973 VirtualBox VM 6.0.4 r128413 linux.amd64 (Jan 25 2019 21:00:14) release log

VirtualBox 6.0.10 is out, consider upgrading the main program, the accompanying ExtPack and the Guest Additions (GAs) in your Win10 VM. That's the first thing that you got to do.

00:00:01.769527 crCtlSubmit failed (rc=VERR_NOT_SUPPORTED)

I see plenty of these (12 to be exact), and I have no clue what it means, but it definitely isn't something I've seen often, if at all...

What I do know is that the string "crCtlSubmit" shows up in the files: ConsoleVRDPServer.cpp, DevVGA_VDMA.cpp, DevVGA.cpp, DisplayImpl.cpp, DisplayImpl.h and pdmifs.h. All of them are display related...

00:00:01.791178 File system of '/media/smile4god/Data/HexaBrainX2-Windows/VirtualBox VMs/Win10 X64/Win10 X64.vdi' is fuse

What's the Data drive, an external USB, NTFS or exFAT?

00:00:01.892527 GUI: UIDesktopWidgetWatchdog::sltHandleHostScreenAvailableGeometryCalculated:
                Screen 0 work area is actually resized to: 1440x357 x 2560x1403
00:00:01.901545 GUI: UIDesktopWidgetWatchdog::sltHandleHostScreenAvailableGeometryCalculated:
                Screen 1 work area is actually resized to: 4000x0 x 1440x2533
00:00:01.931985 GUI: UIDesktopWidgetWatchdog::sltHandleHostScreenAvailableGeometryCalculated:
                Screen 2 work area is actually resized to: 0x0 x 1440x2533

Can you simplify your setup? Don't go for the whole kit and caboodle that includes the kitchen sink when you're reporting a problem. Unless the problem actually involves the kitchen sink...

Then, you have about a gazillion of these:

00:07:41.826031 VMMDev: Guest Log: OpenGL Warning: RegNames: requested to register a null name
00:07:41.826693 VMMDev: Guest Log: OpenGL Warning: SHCRGL_GUEST_FN_WRITE_READ (88) failed with ffffffea

half a gazillion of these:

00:07:48.767989 VMMDev: Guest Log: OpenGL Warning: crPixelCopy3D:  simply crMemcpy'ing from srcPtr to dstPtr

a couple of dozen of assertions in the OpenGL code:

00:07:46.936070 VMMDev: Guest Log: OpenGL Warning: Assertion failed: context->spuContext >= 0=0,
                file D:\tinderbox\add-6.0\src\VBox\Additions\common\crOpenGL\context.c, line 1257

and more OpenGL warnings that I'd care to list.


Conclusion? If upgrading to 6.0.10 doesn't get rid of those errors, update your NVidia drivers, and if that doesn't fix it then disable 3D in your guest. See what happens...


PS. The way that you get a proper log is to follow a "start the VM from cold-boot" (not saved-state) / "observe problem" / "shutdown the VM" cycle, completely shut down. Your VM started from a saved-state and I can't tell what version of Guest Additions you have installed...

[GottaGetem]

Thanks all for the replies.

Not every problem you encounter inside a VM is caused by the VM. In this case I suggest that you search the web for information on "VIDEO TDR FAILURE". The top hit is a YouTube video claiming to provide a fix, but I don't have the problem so I can't verify anything. I notice that the guys say the problem is with Intel graphics, but that has to be bs since the DLL mentioned is named nvxxxxxx, i.e. it's an NVidia DLL. His fix may still be valid even if his diagnosis is not.

FYI: when you enable 3D acceleration in a VM, the virtual GPU inside the VM sends your requests to the host graphics card using it's OpenGL API. That is why host graphics DLLs are relevent to the VM, and why it would show up as a crash in the VirtualBox graphics driver. The guest OS's crash handler certainly couldn't reference a process that runs on the host PC.

This is an interesting observation, however I'm using a Linux host and the error shown appears to be a windows specific driver. Linux has no DLLS to reference. So I think issue is something else.

TDR is the Timeout, Detection, and Recovery component in Windows. This type of crash usually occurs when the Graphics Display driver for the installed graphics card stops responding and can't be restarted by the OS. The most common reason for the problem is that the graphics device is being overloaded, i.e. used beyond its capabilities and occurs most often when playing graphic intensive games, but can also caused by any process that uses a large amount of graphic resources, such as when editing or creating videos.

The graphics card you are using in the VM is a relatively basic virtual device; and not the real one installed on the host machine. It might help if you described what you were doing when the Crash(es) occur as someone with a more in depth knowledge of VirtualBox might have more to offer. Do the crashes usually coincide with some graphics intensive activity/screen activity on multiple monitors? If so then you may need to lower your expectations of the power/capacity of a Virtual Machine.

I would agree with this analysis. Interestingly enough, I never do any graphics intensive activities at all. I open a code editor, chrome browser, and a few chat applications (Teams, Skype, Slack). Typically the error occurs when I go to select some text, bring another window to the forefront, or another basic and non-intensive user activity.

PS. The way that you get a proper log is to follow a "start the VM from cold-boot" (not saved-state) / "observe problem" / "shutdown the VM" cycle, completely shut down. Your VM started from a saved-state and I can't tell what version of Guest Additions you have installed...

Oops, I thought I did a start from clean but you're right, it was a saved state that now I recall. I'll try you answers and post again with a proper log. The drive you mentioned is an internal NVME formated to ExFat. P.S. Could you redact that part of your quote from the log which specified the username and change it to '/media/Data/VirtualBox VMs/Win10 X64/Win10 X64.vdi' - I didn't realize I was posting my user account info for the whole world to see on here.

I will update soon