Open maxvollmer opened 5 years ago
It's crashing adding -dev output to the console, in the crash you attached specifically it was running the 'exec config.cfg' that happens at startup and was adding that text to the console through DPrintf.
Try running without -dev for a bit and see if you still see crashes like this. Also, keep track of where the crashes are happening if you haven't been already and see if they all occur in GameUI.dll like this one does.
@mikela-valve Thank you so much for looking into this and your quick response! So far all crashes occurred in GameUI.dll. I will let you know if I encounter a crash that happens elsewhere.
I will remove -dev and see how it goes. Will get back to you as soon as I launched the mod often enough to be able to make any assessments :)
Were you able to determine if this is caused by my mod, or if it is a bug in HL?
Geckon from the SC team just told me that they had a similar issue when using -condebug (which I am also using). Apparently sometimes the engine fails to open the log file. Could this be the issue?
I will also try running the mod without -condebug, to see if this is indeed the same issue.
Gettinf some of 0005c errors now too, but in ucrtbased.dll hl.exe.
This issue happened for me with my mod, removing -condebug
from launch options seemed to fix it.
It's important to note that Con_DPrintf
does not check if the console is initialized before it prints something, unlike Con_Printf
which does check that. This behavior differs from Quake where Con_DPrintf
is just a wrapper around Con_Printf
that checks the developer
cvar before printing.
Adding the same checks would break a ton of debug output so that's not a solution. It might be worth looking into edge cases where the console isn't fully initialized and a call could access a null pointer somewhere down the line.
Also i doubt qconsole.log
has anything to do with it. If you set it to read only or make it a directory then open
returns -1, and it works fine even in that case. -condebug
probably only exposes the problem, it doesn't cause it.
For the last couple of days I've been getting regular crashes due to an access violation in GameUI.dll when starting hl.exe with the Half-Life: VR mod I am developing.
The crash happens fairly early, right before the Half-Life menu would show. It happens about 10% of the times I start the game.
Some of my testers have started reporting the same issue around the same time I noticed it. I am unable to produce the error in vanilla Half-Life, so I first suspected I messed something up in my mod's code. However, I don't get any stacktrace and after a full day of debugging (yay bank holidays) I still have no clue what might be the cause. I also tried an old version of my mod from 6 months ago, which definitely didn't have this bug back then, but now crashes with the same error message as well.
I have the feeling that this error might be caused by some kind of race condition or weird timing issue, since the game needs a good bunch of seconds to load with my mod. I am worried that "fixing" this by delaying my initializer code will just hide the underlying issue which might manifest again at any time or on other users systems.
So I hope someone from Valve can figure out what's going on.
Maybe relevant: I am loading openvr_api.dll, and my mod is heavily interacting with SteamVR. I initialize everything, including OpenVR, in R_StudioInit(). If you like I can give you access to my mod's private repo, in case you want to reproduce the crash on your systems. I have attached the crash dump generated by Steam.
Relevant debugger output:
Crash dump: crash_hl.exe_20190531114354_1.dmp.zip
Complete output: