Hi all,
I spent some time today trying to figure out why the d3d8:device tests are timing out (it's the #1 bug on Jeremy's list [1]). The timeout occurs within test_lost_device, which changes the foreground window to the desktop, then changes it back to the controlling window of the D3D device. Usually that's not a problem, but this particular machine is so traumatized by the experience that it locks up when you try to reset or release the device afterwards.
The exact hangup occurs in d3d8/tests/device.c:7721.[2] By the way, despite the comments in this function, the test machine does return D3DERR_DEVICELOST. Also, the Windows 8 d3d8:device failures are a completely unrelated crash that happens intermittently on Windows 10 as well.
I regret that I was only able to narrow down the problem and could not come up with a good solution. Hopefully another one of you will know how to fix this.
-Alex
[1] https://www.winehq.org/~jwhite/320152b06de1.html [2] https://source.winehq.org/git/wine.git/blob/320152b06de1d08f6f13b9edeca467f6...
On 15 January 2018 at 05:30, Alex Henrie alexhenrie24@gmail.com wrote:
I spent some time today trying to figure out why the d3d8:device tests are timing out (it's the #1 bug on Jeremy's list [1]). The timeout occurs within test_lost_device, which changes the foreground window to the desktop, then changes it back to the controlling window of the D3D device. Usually that's not a problem, but this particular machine is so traumatized by the experience that it locks up when you try to reset or release the device afterwards.
Perhaps you've already tried this, but make sure test_lost_device() causes the hang on its own as well. It's happened on occasion that a preceding test caused the driver to e.g. corrupt its internal memory.
2018-01-15 5:39 GMT-07:00 Henri Verbeet hverbeet@gmail.com:
On 15 January 2018 at 05:30, Alex Henrie alexhenrie24@gmail.com wrote:
I spent some time today trying to figure out why the d3d8:device tests are timing out (it's the #1 bug on Jeremy's list [1]). The timeout occurs within test_lost_device, which changes the foreground window to the desktop, then changes it back to the controlling window of the D3D device. Usually that's not a problem, but this particular machine is so traumatized by the experience that it locks up when you try to reset or release the device afterwards.
Perhaps you've already tried this, but make sure test_lost_device() causes the hang on its own as well. It's happened on occasion that a preceding test caused the driver to e.g. corrupt its internal memory.
I just tried it and yes, test_lost_device still hangs even with all of the other tests commented out.
-Alex
-
Alex Henrie -
Henri Verbeet