Crashing without generating a crashlog would typically indicate either the process being terminated due to a driver error/reset or stack corruption (less likely without some particularly outfield mempatches). Possibly when exceeding memory limits in certain cases since there's poor handling for failed allocations, but you'd usually still expect to get an error in the console and/or a little error dialog. In some worst case crashes I've intentionally caused for testing, it'd fail to write anything useful to the log sometimes, but the exception handler isn't usually entirely bypassed by the OS.
Windows should still log basic info on why the process is being closed, which could narrow it down. You might be able to find it by opening up "event viewer" in the start menu (or hitting Win+R and running eventvwr.msc), then under the Windows Logs category on the left view the "Application" log and select "Filter current log..." in the right panel. In the filter dialog, check the "error" box and hit OK.
Unfortunately it doesn't contain the root cause: the location it stopped at is internal to the exception handler, meaning it was already dealing with a relatively normal crash and had to abort for some reason prior to finishing gathering all the diagnostic data. This could be because some of the code running immediately before the crash was no longer accessible, e.g. due to an unloaded driver or a bit of memory corruption. Before the patch you'd have seen the UE popup here because the original handler wouldn't have tried to access that memory to prevent certain types of crashes or collect any further info for debugging.
If this happened when changing maps or leaving the server, it's likely related to a minor memory management bug where there was no safe accounting for the fact that the game sometimes tries to access objects immediately after they've been deleted. I believe this was quickly mitigated in one of the public builds, though.
Comments
Crashing without generating a crashlog would typically indicate either the process being terminated due to a driver error/reset or stack corruption (less likely without some particularly outfield mempatches). Possibly when exceeding memory limits in certain cases since there's poor handling for failed allocations, but you'd usually still expect to get an error in the console and/or a little error dialog. In some worst case crashes I've intentionally caused for testing, it'd fail to write anything useful to the log sometimes, but the exception handler isn't usually entirely bypassed by the OS.
Windows should still log basic info on why the process is being closed, which could narrow it down. You might be able to find it by opening up "event viewer" in the start menu (or hitting Win+R and running
eventvwr.msc), then under the Windows Logs category on the left view the "Application" log and select "Filter current log..." in the right panel. In the filter dialog, check the "error" box and hit OK.It looks like it did log to the Event Viewer.
"Faulting application name: Tribes2.exe, version: 0.25034.0.0, time stamp: 0x3dc05b85
Faulting module name: IFC22.dll, version: 2025.9.1.1, time stamp: 0x68b55a84
Exception code: 0xc0000005
Fault offset: 0x000f8d77
Faulting process id: 0xA54
Faulting application start time: 0x1DCFB9D53B725C6
Faulting application path: E:\Dynamix\Tribes2\GameData\Tribes2.exe
Faulting module path: E:\Dynamix\Tribes2\GameData\IFC22.dll
Report Id: 3a79cb4f-0f18-4309-b015-ab2498859c30
Faulting package full name:
Faulting package-relative application ID:"
I'm not sure if that information helps at all, but it's just strange I hadn't ever had a crash like these before the patch.
Unfortunately it doesn't contain the root cause: the location it stopped at is internal to the exception handler, meaning it was already dealing with a relatively normal crash and had to abort for some reason prior to finishing gathering all the diagnostic data. This could be because some of the code running immediately before the crash was no longer accessible, e.g. due to an unloaded driver or a bit of memory corruption. Before the patch you'd have seen the UE popup here because the original handler wouldn't have tried to access that memory to prevent certain types of crashes or collect any further info for debugging.
If this happened when changing maps or leaving the server, it's likely related to a minor memory management bug where there was no safe accounting for the fact that the game sometimes tries to access objects immediately after they've been deleted. I believe this was quickly mitigated in one of the public builds, though.