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.
Possibly related but distinct; I'm experiencing a deterministic IFC22.dll load failure on Win11 26200
Flagging this here since it also involves IFC22.dll, but I think it's a different failure from mistcane's and wanted to give a clean data point rather than muddy that one. Theirs is an intermittent in-game CTD where the handler aborts mid-crash; mine never launches at all.
Mine is a 100% reproducible failure to launch: every start throws 0xc0000142 (STATUS_DLL_INIT_FAILED), no window, no CRASHLOG.txt; it dies during DLL init before the handler is up.
Environment: fresh GSI v25034 + the official signed 20250922 preview (also repro'd via the PlayT2 AIO). Windows 11 build 26200 (Insider/Dev, newer than the 24H2 others here are running). Laptop with hybrid graphics: NVIDIA GeForce RTX 3060 Laptop GPU (6 GB) + Intel UHD, NVIDIA driver 32.0.15.9597 (2026-03-17). Worth noting the game auto-selected the Intel UHD as the renderer, not the NVIDIA.
Trace: under WinDbg with _NO_DEBUG_HEAP=1 and loader snaps (!gflag +sls), every image loads SUCCESS, and the last LdrpCallInitRoutine before NtRaiseHardError (c0000142) is IFC22.dll (base 0x53f60000); so its DllMain is failing initialization. Notably, under the default debug heap (process launched by a debugger) init succeeds and the game runs, pointing at something heap/timing-sensitive in IFC22's init on this Windows build.
Stock unpatched Tribes2.exe runs perfectly on 26200, so it's isolated to the patch's init path. I got playing by falling back to RC2a (which itself needed Mandatory ASLR turned On to stop its injected code being relocated to a bad address. Could possibly be an unrelated 26200 quirk, but mentioning in case relocation sensitivity is a common thread).
Happy to run any test build, capture a full loader-snap log, or provide a dump - just let me know what'd be useful.
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.
Possibly related but distinct; I'm experiencing a deterministic
IFC22.dllload failure on Win11 26200Flagging this here since it also involves
IFC22.dll, but I think it's a different failure from mistcane's and wanted to give a clean data point rather than muddy that one. Theirs is an intermittent in-game CTD where the handler aborts mid-crash; mine never launches at all.Mine is a 100% reproducible failure to launch: every start throws
0xc0000142(STATUS_DLL_INIT_FAILED), no window, no CRASHLOG.txt; it dies during DLL init before the handler is up.Environment: fresh GSI v25034 + the official signed 20250922 preview (also repro'd via the PlayT2 AIO). Windows 11 build 26200 (Insider/Dev, newer than the 24H2 others here are running). Laptop with hybrid graphics: NVIDIA GeForce RTX 3060 Laptop GPU (6 GB) + Intel UHD, NVIDIA driver 32.0.15.9597 (2026-03-17). Worth noting the game auto-selected the Intel UHD as the renderer, not the NVIDIA.
Trace: under WinDbg with
_NO_DEBUG_HEAP=1and loader snaps (!gflag +sls), every image loads SUCCESS, and the lastLdrpCallInitRoutinebeforeNtRaiseHardError(c0000142) isIFC22.dll(base0x53f60000); so itsDllMainis failing initialization. Notably, under the default debug heap (process launched by a debugger) init succeeds and the game runs, pointing at something heap/timing-sensitive in IFC22's init on this Windows build.Stock unpatched
Tribes2.exeruns perfectly on 26200, so it's isolated to the patch's init path. I got playing by falling back to RC2a (which itself needed Mandatory ASLR turned On to stop its injected code being relocated to a bad address. Could possibly be an unrelated 26200 quirk, but mentioning in case relocation sensitivity is a common thread).Happy to run any test build, capture a full loader-snap log, or provide a dump - just let me know what'd be useful.