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.
This wouldn't be a general 26200 issue nor related to drivers or any crash that's ever been reported. There's very limited possibility for initialization to abort at this stage, as it primarily consists of verifying that the correct Tribes2.exe build number is readable at the expected address, warming up the new memory manager before any allocations are attempted, making a few basic win32 calls, and as quickly as possible rewriting some early portions of the program to prepare running the full init later in the game's own startup process.
The long & short of it is that you're most likely forcing mandatory ASLR to rebase the Tribes2.exe image, or otherwise using a security setting that alters how the process memory can be accessed.
If lmDva 0x400000 in windbg doesn't bring up Tribes2.exe with the default start offset of 00400000, the patch simply isn't going to work.
The patch operates on the basis of modifying, interfacing with, and replacing large portions of the engine dynamically in memory, and does so using many many direct pointers to fixed, hardcoded known locations in the Tribes2.exe image loaded at its preferred base address of 0x400000. While obviously it'd be relatively trivial to detect a new base address to calculate a relative offset for every pointer access, this is largely an unnecessary overcomplication: it's a 25 year old legacy 32-bit Windows process, and more recent options like mandatory ASLR are opt-in, not the default behaviour for any standard Windows build (nor WINE). The module isn't going to be rebased except in very rare cases where the user or their administrator has changed certain settings.
On the off chance it is in fact in the correct virtual space, you can try to narrow down where the init is stopping by enabling full page heap verification in windbg with !gflag /p /enable Tribes2.exe /full
Regarding the render device selection on laptops, the standard game doesn't have any direct control over it, it's at the mercy of what their selection mechanisms decide. Using the DXGI interop option in the patch might push it over to the high-performance GPU based on the D3D device context creation (it's not currently explicitly filtering for a specific adapter), but the nvidia/amd switchable graphics hints would have to be exported in Tribes2.exe (requiring modifying it on disk, which this patch purposely avoids), and programmatic selection otherwise isn't particularly well supported for an application spinning up an oldschool OpenGL context. With a new engine build or at least a fully replaced renderer, it'd be straightforward to make it default to whatever's desired... but as it stands the choice for OpenGL is either letting the user set it in a profile, or hacking together something to indicate to their selection layer which to prioritize.
I'd want to see a demo or interior/map where this can be reproduced. The mission area border rendering doesn't touch the projection, and should be inheriting the same matrix applied to the rest of the exterior zone objects, so something rendering prior to the grid may not be restoring the state correctly.
Yeah the forcefields are rendering before the grid in the transparency sort order, and aren't properly resetting the viewport after they do. Easily slipped by a quick early optimization pass since the conditions to see it are a few transparent object types observed together in a specific order through a portal. Quirks of working with some of the old-school fixed function OpenGL stuff...
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.
This wouldn't be a general 26200 issue nor related to drivers or any crash that's ever been reported. There's very limited possibility for initialization to abort at this stage, as it primarily consists of verifying that the correct Tribes2.exe build number is readable at the expected address, warming up the new memory manager before any allocations are attempted, making a few basic win32 calls, and as quickly as possible rewriting some early portions of the program to prepare running the full init later in the game's own startup process.
The long & short of it is that you're most likely forcing mandatory ASLR to rebase the Tribes2.exe image, or otherwise using a security setting that alters how the process memory can be accessed.
If
lmDva 0x400000in windbg doesn't bring up Tribes2.exe with the default start offset of00400000, the patch simply isn't going to work.The patch operates on the basis of modifying, interfacing with, and replacing large portions of the engine dynamically in memory, and does so using many many direct pointers to fixed, hardcoded known locations in the Tribes2.exe image loaded at its preferred base address of
0x400000. While obviously it'd be relatively trivial to detect a new base address to calculate a relative offset for every pointer access, this is largely an unnecessary overcomplication: it's a 25 year old legacy 32-bit Windows process, and more recent options like mandatory ASLR are opt-in, not the default behaviour for any standard Windows build (nor WINE). The module isn't going to be rebased except in very rare cases where the user or their administrator has changed certain settings.On the off chance it is in fact in the correct virtual space, you can try to narrow down where the init is stopping by enabling full page heap verification in windbg with
!gflag /p /enable Tribes2.exe /fullRegarding the render device selection on laptops, the standard game doesn't have any direct control over it, it's at the mercy of what their selection mechanisms decide. Using the DXGI interop option in the patch might push it over to the high-performance GPU based on the D3D device context creation (it's not currently explicitly filtering for a specific adapter), but the nvidia/amd switchable graphics hints would have to be exported in Tribes2.exe (requiring modifying it on disk, which this patch purposely avoids), and programmatic selection otherwise isn't particularly well supported for an application spinning up an oldschool OpenGL context. With a new engine build or at least a fully replaced renderer, it'd be straightforward to make it default to whatever's desired... but as it stands the choice for OpenGL is either letting the user set it in a profile, or hacking together something to indicate to their selection layer which to prioritize.
Visual bug I noticed
https://youtu.be/Ltp16Pwl5vU
I'd want to see a demo or interior/map where this can be reproduced. The mission area border rendering doesn't touch the projection, and should be inheriting the same matrix applied to the rest of the exterior zone objects, so something rendering prior to the grid may not be restoring the state correctly.
Yes, it's a lakrabbit map that just so happens to have the buildings next to the border
https://github.com/ChocoTaco1/TacoMaps/blob/master/Lak/mini-sundried.vl2
Yeah the forcefields are rendering before the grid in the transparency sort order, and aren't properly resetting the viewport after they do. Easily slipped by a quick early optimization pass since the conditions to see it are a few transparent object types observed together in a specific order through a portal. Quirks of working with some of the old-school fixed function OpenGL stuff...