Occasional start-up crash when using DirectDraw on Windows 11
MJohnson20 opened this issue · comments
I'm running VizDoom on Windows 11, Nvidia 3070Ti and I'm seeing an occasional crash when attempting to blt the backbuffer using the directdraw renderer, which obviously can be a bit annoying when training. This generally happens just after initialization.
The crash is specifically here in fb_ddraw.cpp
if (FAILED (hr = PrimarySurf->Blt (&rect, BackSurf, NULL, DDBLT_WAIT|DDBLT_ASYNC, NULL))) // Crash is here. {
In the DDrawFB::PaintToWindow function. It looks like some kind of internal crash in directdraw so It might be down to how it's being emulated on Windows 11.
Crash is:
Exception thrown at 0x00007FFB19AE1F30 (ddraw.dll) in vizdoomrd.exe: 0xC0000005: Access violation reading location 0x0000000000000014.
Hi @MJohnson20, thank you very much for reporting the problem! We probably won't investigate it in the near future as the Windows version is not a priority for us. If you have an idea how to fix it, we will gladly accept a PR.
If you plan on running some serious experiments on your machine, I highly recommend using Windows Subsystem for Linux and installing ViZDoom on it, or using Linux-based docker, as there is another issue with slowdowns on Windows 11 (#504).
I've spent some time investigating and I'm pretty sure it's something in the internals of DirectDraw which is causing the exception, which I'm not surprised by given how the API has been deprecated for quite some time now. The solution would be replacing the DirectDraw code with something else on Windows, but I understand that's not likely at this point.
I'll investigate using WSL or Docker, thanks.
Thank you for your investigation @MJohnson20. It works perfectly fine on my Windows 10 machine, so I was not able to investigate on my own so far, but I'm not surprised that some issue is present on the next iteration of the OS. The best solution would be to drop the DirectDraw backend and just replace it with SDL2 backend that is used on Linux and Mac. Unfortunately, it is also intertwined with some posix-specific code, so it isn't a drop-in replacement for Windows and would require some more work. I have plans (for a few years now...) to do it but so far no luck with finding enough time. Maybe someday it will happen, but it is unlikely in the near future.
As a follow-up, I've gone ahead and ported the Win32 version to using SDL. It's a bit of a mess at the moment but it's functional. I'll get it cleaned up and submit a PR if you're interested.
It should be noted that it's probably got a few issues as there's quite a lot of code that's been ripped out, so it'll take some time to get into a mergable state but we could get that ball rolling.