Solved BuildGraphicsSettings crash when entering setup UI page on our server
-
I fly with FFW36 and we use a VPS to host the game.
Everything works fine, except that we cannot access the Setup pages in the 2D UI.
BMS crashes whenever doing that. I have a debug trace/stack that I can share with someone from the dev team if useful ?
Apparently, the crash occurs in the following method :
0000000004B1D37E Falcon BMS.exe, BuildGraphicsSettings()+1646 byte(s), E:\WIP\BMS\SVN\Code-4.36\UI\SRC\setup\GraphicsTab.cpp, line 1506Based on the hex later in the trace, it looks like the application is attempting to enumerate supported resolutions and/or displays.
Some say that this is because there is no real graphical card on the server, but we would like to be sure of that. Because apart from this crash, the game is able to render 3D (using software renderer I presume).
I am wondering if this could be due to missing DirectX components, or something related to virtualization (no physical display/monitor for instance).
Has anybody else had this problem ? Is this a known limitation ? Would it be possible to access the non-graphics tabs of the Setup UI without triggering the code related to graphical options ?
Thanks for your help or advice with regards to recommended hosting specs for instance.
-
Please add a virtual audio card (virtual cbales for example)
and use for DX:
-
-
Thanks MaxWaldorf (and UOAF too).
-
Thanks indeed ! Will test this soon.
-
Unfortunately, it does not solve the problem on that server. I do have the popup window displayed when starting BMS, and make sur ‘Auto’ is selected. But it still crashes when entering Setup.
(As for the audio, Virtual Cables was already installed on the server)
On a parallel track, I tried with another server, hosted by a different provider and with a more recent OS (Windows Datacenter 2022). There it is working without even adding the wrapper.
I am not sure why. Is it because the virtualization stack is different ? Or the OS ? Or the devices installed by default ? Quite a mystery at this point
-
@pyhg yes … what is your server OS? and what is your virtualization environment.
(run DxDiag.exe … what does it say about the display and sound adapters)
-
@airtex2019
Non working server is Windows Server 2012 R2, and dxdiag shows a RDPUDD graphical device, without much info :Working server is Windows Datacenter 2022, dxdiag shows much more info :
If I am correct, both are virtual cards for RDP, but the later one looks more like a proper device than the first one (e.g. memory and display have values).
In terms of virtualization, I suspect the former one is HyperV (I can see an hyperv ethernet adapter), whereas the later one could be RedHat (again, RedHat VirtIO ethernet adapter). But this is really a guess
Edit : the top part of dxdiag in the 2022 server is missing :
-
Do you have other means to connect to it like VNC or similar?
You definitely don’t have a GFX card on the server…
-
@pyhg Did the older 2012 server run 4.35 ok?
I’m not an expert in Windows virtualization… at a high level, I know there’s a “fake” graphics adapter that sends pixels over the RDP network connection. But I don’t know what changed, between 2012 and 2022.
Perhaps forcing use of WARP (the built-in software 3D rasterizer) for BMS process, may be a workaround? (In theory, the RDP fake adapters would use WARP, under the hood… but for apps and games that try to query DX caps, maybe it helps to force it.)
See my post here…
https://forum.falcon-bms.com/topic/22498/graphics-card-for-server/3 -
I spent a little time testing BMS 4.36 in a virt.
Seemed to work ok, with/without the WARP override. And both in RDP sessions (with rdpidd.dll virtual graphics adapter) and direct sessions (with hypervideo.sys virtual graphics adapter).
But it did crash upon entering 3D, when the virt didn’t have enough RAM. 8GB was not enough, 16GB seemed to be sufficient… at least for a simple TE.
This was 1920x1080 desktop resolution, btw.
I noticed the total commit-charge for the virt was near 15GB … so if you had browser and any other apps running, it might be too much, without disk thrashing.
I don’t remember how this compares to 4.35…
-
@airtex2019 and so the wrapper did not help?
-
@MaxWaldorf I didn’t try the DX wrapper. Was just trying to repro the BuildGraphicsSettings() crash on the 2D Setup page.
So far I’m unable … may be something about the older OS environment. But I don’t have that handy to test. I’m just running Win10 21H2.
-
@MaxWaldorf
I just installed TightVNCServer and opened a session : I can open the Setup pages
But 3d crashes in VNC.
We could still use VNC just to set-up options, and stay with RDP to host and start the game afterwards. At least this gives us a workaround.Still, I am going to continue reading the other messages and links received.
I have tried another wrapper, but if I am correct, the wrapper is mainly to handle 3d calls, it does not really intercept anything in 2D. On our server, 3d has always been working. It is just the 2D UI setup menu that does not work. That is a bit weird … because that menu requires probably less resources than the 3d rendering.
-
@pyhg maybe the direct x 2D rendering is having issues with the RDP implementation…
I really can’t say…
Maybe there is someone willing to try implementing a wrapper that emulates a virtual gfx card?
So the uoaf wrapper by @BibleClinger didn’t work?
-
@airtex2019
Nope, we also had this setup problem in 4.35. This is not new with 4.36.I am trying the ‘warp’ use based on the info you provided, but I cannot get the d3dconfig.exe tool on this OS apparently.
-
@MaxWaldorf
Yes, I did try with that wrapper too.I think we need to choose between :
- either using VPN from time to time whenever we need to change setup options, and remain with RDP the rest of the time
- migrating to a more recent server (like the one I used in the comparison test) … which would not necessarily be a bad thing considering that Windows Server 2012 R2 is probably EOL already for quite some time …
But this is not my call, we need to talk about this internally, as there is other important stuff installed on the server besides BMS that would need to be migrated as well.
In any case, thanks a lot for your time and help looking at this
-
Funny, the readout of dxdiag is quite different when connected in VNC :
-
FYI, in the VNC the crash in 3d shows the following trace. But not sure it is realistic to run 3d in VNC anyway…
0000000004A01A77 Falcon BMS.exe, SetupDIDevice()+103 byte(s), E:\WIP\BMS\SVN\Code-4.36\SIM\SIMINPUT\sidevice.cpp, line 141+4 byte(s)
Call Stack:
0033:0000000004A01A77 Falcon BMS.exe, SetupDIDevice()+103 byte(s), E:\WIP\BMS\SVN\Code-4.36\SIM\SIMINPUT\sidevice.cpp, line 141+4 byte(s), Parameters(0x00000000003A02C8 0x000000003068F360 0x000000000E787218 0x000000000E787218)
0033:00000000048FD8DB Falcon BMS.exe, OTWDriverClass::Enter()+15579 byte(s), E:\WIP\BMS\SVN\Code-4.36\SIM\OTWDRIVE\Otwdrive.cpp, line 2994+152 byte(s), Parameters(0x000000000E77C880 0x000000002F8E2140 0x00000000FE92E750 0x00000000000000F0)
0033:0000000004A1B496 Falcon BMS.exe, SimulationLoopControl::StartLoop()+1078 byte(s), E:\WIP\BMS\SVN\Code-4.36\SIM\SimLoop\Simloop.cpp, line 823, Parameters(0x0000000000000000 0x0000000000000000 0x000000002F8E90C0 0x0000000004A1B060)
0033:00000000045113DD Falcon BMS.exe, ThreadUnhandledExceptionWrapper()+109 byte(s), E:\WIP\BMS\SVN\Code-4.36\FALCLIB\ehandler.cpp, line 1588+5 byte(s), Parameters(0x0000000000000000 0x000000002F8E90C0 0x0000000000000000 0x0000000000000000)
0033:0000000004E2BA19 Falcon BMS.exe, thread_start<unsigned int (__cdecl*)(void * __ptr64)>()+93 byte(s), d:\th\minkernel\crts\ucrt\src\appcrt\startup\thread.cpp, line 115+5 byte(s), Parameters(0x0000000004E2B9BC 0x0000000000000000 0x0000000000000000 0x0000000000000000)
0033:00000000293B13D2 KERNEL32.DLL, BaseThreadInitThunk()+34 byte(s), Parameters(0x00000000293B13B0 0x0000000000000000 0x0000000000000000 0x0000000000000000)
0033:000000002B0E54F4 ntdll.dll, RtlUserThreadStart()+52 byte(s), Parameters(0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000)