official client (netc.dll) self-terminates on launch with 0xC0000409

[MortimerSapkowski]

Describe the bug

MTADiag report: https://pastebin.multitheftauto.com/1846091870

---

Summary

The official stable MTA:SA 1.6 client refuses to start. Multi Theft Auto.exe runs for ~16 seconds, then silently self-terminates with exit code 0xC0000409 (STATUS_STACK_BUFFER_OVERRUN / __fastfail). There is no crash dialog, no MTA crash dump, and no Windows Error Reporting / Event Log entry — i.e. the process is terminated deliberately (via __fastfail/NtTerminateProcess), not by a normal exception. gta_sa.exe is never launched; the process dies during the loader phase, before the main menu.

Key fact

A self-compiled build from source (VERSION_TYPE_CUSTOM) works perfectly on the same machine. Only the official/protected build fails. This rules out hardware/OS/GTA issues and points at the production netc.dll anti-cheat/protection layer.

Technical detail

• Faulting path: loader!DoWinMain -> ... -> netc!CheckService (+0x718) -> protected blob inside netc.dll.
• The main thread spins in a tight ~20-byte loop (a single jne) at 100% of one CPU core for ~16 s, then calls __fastfail (0xC0000409).
• Worker threads are idle (NtWaitForWorkViaWorkerFactory) during the spin; the process opens no outbound TCP connections during this time.
• Under a live debugger (cdb) the module hangs indefinitely instead of terminating (anti-debug behaviour). A non-invasive attach reproduces the spin and the stack above.
• netc.dll loads WINTRUST, CRYPT32, MSASN1, bcrypt (signature verification) — but all CA OCSP/CRL endpoints (Certum, SSL.com) are reachable (~200 ms), so it is not a revocation-check timeout.

Environment (all verified clean / ruled out)

• OS: Windows 11 Pro 25H2, build 26200.8655, Russian locale.
• CPU: AMD Ryzen 9 7950X (32 threads). RAM 64 GB. GPU: RTX 4070 Ti.
• Board: Gigabyte B650 GAMING X AX, BIOS F5a (RDRAND verified working).
• MTA: 1.6.0.24123, netc.dll 7,699,280 bytes; all MTA module Authenticode signatures Valid (Certum "Open Source Developer").
• gta_sa.exe MD5 170b3a9108687b26da2d8901c6948a18 (clean 1.0 US).
• Ruled out: Hyper-V/VBS (disabled, HypervisorPresent=False); not a VM; VPN/TAP/Wintun drivers removed; Winsock LSP catalog clean (Microsoft only); Windows Defender (tested with real-time protection OFF); no ASR rules / no system Exploit Protection mitigations; CPU affinity reduced to 2 cores (no change); no third-party/injected DLLs in the process (only MTA + system modules); VC++ 2005-2022 + DirectX present; MTA servers reachable.

Expected

Client reaches the main menu (the self-compiled CUSTOM build does).

Deeper analysis

• The termination mechanism is a clean NtTerminateProcess(0xC0000409) (not a __fastfail/exception): with WER LocalDumps and an AeDebug post-mortem debugger configured, neither is triggered, and no dump is produced. (netc.dll exports its own NtTerminateProcess wrapper.)
• The ~16 s spin is VMProtect-virtualized code in netc!CheckService busy-waiting on a shared queue-like structure:

mov edx,[obj+4]      ; e.g. write/tail index
cmp edx,[obj+8]      ; vs read/head index
jne <loop>           ; spin while not equal

i.e. the main thread waits for a result/message from another AC thread/component that never arrives on this system, then a watchdog kills the process. Surrounding code shows VMProtect handler stubs (int3-padded micro-routines), so the human-readable condition cannot be extracted.

Steps to reproduce

1. Install official MTA:SA 1.6 on Windows 11 25H2 (Ryzen 9 7950X).
2. Launch Multi Theft Auto.exe.
3. Observe ~16 s of 100% single-core CPU, then silent exit 0xC0000409; main menu never appears.

Version

1.6.0.24123 or any other

Additional context

No response

Relevant log output

Security Policy

• I have read and understood the Security Policy and this issue is not security related.

[emeya-star]

Confirming I'm hit by this exact issue on a separate machine, second data point with a reproduced exit code.

Symptom: Official MTA:SA 1.6 client self-terminates on launch. Multi Theft Auto.exe runs, no window appears, and after ~15 seconds the process dies on its own. gta_sa.exe is never spawned. No crash dialog, no minidump, nothing in the Application event log.

Captured exit code: 0xC0000409 (decimal -1073740791) = STATUS_STACK_BUFFER_OVERRUN / __fastfail. Measured survival time: 15.3 s before the watchdog kill. Identical to OP.

report.log shows the launcher reaching the launch sequence and then dying with no further entry, every attempt:

Launcher Main: Launch: 'C:\Program Files (x86)\MTA San Andreas 1.6', MTA: '...\mta'
CInstallManager::RestoreSequencerState
(nothing after, process terminated, gta_sa.exe never launched)

System:

CPU: AMD Ryzen 7 7800X3D
GPU: NVIDIA RTX 5080 (+ Ryzen iGPU)
RAM: 32 GB
OS: Windows 11 Pro 25H2, build 26200.8655
Client: 1.6.0 (mtasa-1.6-rc-24124), netc.dll present with valid Authenticode signature

Overlap with OP worth noting: AMD Ryzen + Windows 11 25H2 (build 26200).

Ruled out: multiple clean reinstalls; MTADiag (cleared compat flags, installed code-signing certs, DirectX confirmed current); no third-party AV (Defender real-time on, MTA folder excluded); valid GTA:SA path; no injected d3d9/ASI wrappers; mods removed; VC++ runtimes present.

Older client builds launch fine on this machine, only current builds self-terminate. Can't use an older or self-compiled build because my server enforces anti-cheat.

MTADiag logs:

https://pastebin.mtasa.com/3357219291 and https://pastebin.mtasa.com/8402560609

Happy to attach a debugger or capture traces to help repro.

[bum8hj]

Someone in the MTA Discord server noticed that Virtual Desktop is present in many of the pastebins of users having this issue.
As a temporary workaround, uninstalling Virtual Desktop will likely fix the issue as it did for me.

[emeya-star]

Someone in the MTA Discord server noticed that Virtual Desktop is present in many of the pastebins of users having this issue. As a temporary workaround, uninstalling Virtual Desktop will likely fix the issue as it did for me.

You are a GOD!! this worked! Omg thank you! :)! I can finally go back to my low effort game haha.

[HeresHavi]

Having the same issue. I did thorough tests. I went as far as installing a completely fresh Windows machine with nothing else installed with just GTA San Andreas from Rockstar Games Launcher and MTA 1.6 and 1.7.

This is an issue that the MTA Team has to fix since it lives under netc.dll which is not open source.

MTA clients 1.6.0-24124 and 1.7.0-26679 both silently terminate on Windows 11 Pro 26H1 / build 28000.x before gta_sa.exe is created.

The exit code is 0xC0000409 / -1073740791.

This appears to happen inside protected netc.dll during the early CheckService path. The public launcher source shows loader-proxy loads MTA\netc.dll, resolves InitNetRev and CheckService, then calls CheckService(7 /* CHECK_SERVICE_POST_CREATE */) before loading core.dll.

On my machine:

• MTA 1.6 netc.dll: version 1.6.0.24124
• SHA256: F11DF94A0994B1C0A7E7564A517B6876B01B99BB80D54BF1A2493FD7E2C4E71E
• MTA 1.7 netc.dll: version 1.7.0.26679
• SHA256: 0BCEB3D3766D259A7BF73F9DD2B80AB8822F89E276EB903CFE032831663F8068

Dumps shows:

• For 1.6, the main thread enters netc.dll early and is already in a fatal wait/spin path by ~50 ms.

• Later 1.6 captures sit around netc.dll+0x2baca7.

• Representative 1.6 chain includes:
  netc.dll+0x2cf078
  netc.dll+0x29e720
  netc.dll+0x30490f
  netc.dll+0x395a3f
  then loader / LoadLibraryW(netc.dll) frames.

• For 1.7, dumps captured in C:\Dumps\MTA\mta17_micro32 show netc.dll loaded at 0x56ad0000.

• The main thread sits around netc.dll+0x2ad6cc / nearby addresses across the capture.

• Other threads are parked in ntdll.

• Representative 1.7 chain from MTA_0263ms_889136.dmp:
  netc.dll+0x2c08cc
  netc.dll+0x2920ed
  netc.dll+0x2f6e6f
  netc.dll+0x390317
  netc.dll+0x3903fc
  ntdll loader frames
  KERNELBASE.dll
  loader.dll+0x40d99

No gta_sa.exe process is created. The ProgramData report.log only shows early launcher startup lines and then stops.

[HeresHavi]

Did some more digging, looks like modern versions of MTA does not work. Here is what I've tested on my machine:

Works:
MTA 1.6.0 r23409 / netc.dll 1.6.0.23409

Fails:
MTA 1.6.0 r24121 / netc.dll 1.6.0.24121
MTA 1.6.0 r24122 / netc.dll 1.6.0.24122
MTA 1.6.0 r24123 / netc.dll 1.6.0.24123
MTA 1.6.0 r24124 / netc.dll 1.6.0.24124
MTA 1.7.0 r26679 / netc.dll 1.7.0.26679

[Lpsd]

That's not entirely accurate, considering others are using the latest 1.7 versions just fine

[HeresHavi]

That's not entirely accurate, considering others are using the latest 1.7 versions just fine

That's fair, but they must be on a different Windows build, unless there's proof that someone is on OS Build Windows 11 26H1 - 28000.2340.

The weirdest thing is that the game works fine on an older version of MTA but not on any of the recent ones.
Which makes me think that MTA's anti-cheat may be blocking something that's coming from Windows itself.

I've tested all this on a completely fresh installment of Windows, with the disk wiped too, so there's no bloat or potential conflicting applications. Virtualization is completely disabled as well through the BIOS (SVM Mode - using AMD)

[21440]

Found a concrete trigger and a working fix for this on my machine.

Trigger: Virtual Desktop (the VR "Virtual Desktop Streamer") being installed. Uninstalling it makes the official r24124 client launch and connect normally.

Repro / bisect on one machine, Windows 11 25H2 build 26200.8655, Ryzen 5 5600X, RTX 4060 Ti:

• Virtual Desktop Streamer installed -> Multi Theft Auto.exe (r24124) spins one core ~100% for ~9-15s, then self-terminates with 0xC0000409. No window, no gta_sa.exe, no crash dump, no WER. Exactly as described in this issue.
• Uninstall Virtual Desktop -> r24124 launches straight to the main menu and connects to servers (including one enforcing a mandatory update to the latest build). Fixed, on the latest official build.

Important narrowing so nobody wastes time on the wrong thing:

• It is Virtual Desktop's service/driver stack, not its virtual display device. Merely disabling the "Virtual Desktop Monitor" display adapter in Device Manager did not help; only a full uninstall (which removes its service and drivers) did.
• Not virtual displays in general. A "Meta Virtual Monitor" display adapter is still installed and r24124 works fine with it present.
• Parsec ruled out. Parsec's virtual display adapter was installed during the failure and its removal was not required for the fix.

Extra confirmation this is a regression, not "all 1.6 builds":

• r24124 (files 1.6.0.24124): fails while VD is installed.
• r23409 (files 1.6.0.23409, official signed build): launches fine on the same machine regardless of VD. So the netc/loader change that made it sensitive to Virtual Desktop landed after r23409.

Matches the mechanism described here (main thread spinning waiting on a message that never arrives, watchdog fires): the fail-fast is fully suppressed while a debugger is attached (attach at start or late at ~8s, it runs indefinitely; exits 0xC0000409 only after detach). Consistent with a timing-dependent wait that Virtual Desktop's driver/service perturbs on 25H2.

Build correlation across reports points at recent Windows, not hardware:

• This machine + OP: 25H2 / 26200.
• Forum thread, same "opens then vanishes" symptom, reporter also on 26200: https://forum.multitheftauto.com/topic/148075-problem-mta
• Application crashes without error or popup message #4159 (closed), loader crash with no popup on 24H2 / 26100, different GPU: Application crashes without error or popup message #4159
• Fits the documented 24H2 low-level memory-behavior changes that resurfaced latent GTA:SA bugs: https://silentsblog.com/2025/04/23/gta-san-andreas-win11-24h2-bug/

Everything else ruled out on my end (each tested): Windows Defender fully disabled + exclusions; no foreign DLLs injected into the launcher; competing kernel anti-cheats (BattlEye/EAC/EA/Denuvo) all stopped; fresh Windows user profile; stripped environment; elevation; compatibility shims (Win8/7/Vista/XP) do nothing, so it is not a spoofable GetVersion check; genuine GTA:SA v1.0 US gta_sa.exe; HVCI off / DEP standard / VBS idle.

Suggested repro for a maintainer: on Windows 11 24H2/25H2, install the free Virtual Desktop Streamer, launch the current official client -> should fail-fast with 0xC0000409 before the menu. Uninstall Virtual Desktop -> launches normally. (Installing the Streamer does not require a VR headset.)

Happy to grab more diagnostics, test specific builds between r23409 and r24124 if downloadable full installers exist, or capture whatever the #4995 loader logging would surface.

[HeresHavi]

I've been digging more into why MTA refuses to launch on my Windows installation. I think I've managed to narrow it down to a specific check in netc.dll, and I was also able to prove it with a small local patch.

The short version is that netc.dll scans the code inside ntdll!LdrRegisterDllNotification and tries to locate Windows' internal DLL-notification list from an instruction pattern. That pattern is no longer reliable on Windows 11 26H1.

MTA picks the wrong internal address, treats unrelated memory as a linked list, follows an invalid pointer, and then intentionally closes itself with 0xC0000409.

After changing only the two bytes responsible for recognizing this instruction pattern, MTA got past CheckService and loaded core.dll four times in a row.

My setup

• Windows 11 Pro 26H1, build 28000.2340
• SysWOW64\ntdll.dll version 10.0.28000.2113
• ntdll.dll SHA-256: 95CA6B25FF65B89192F5CD52F9B4ED9F98A9DB5B9EF21EE89D0EC5F52EF07D8C
• Multi Theft Auto.exe version 1.26696.0.0
• Multi Theft Auto.exe SHA-256: D0198FC0B0DD502AAAEF376E34E53622620A8F511DFC11CA36E0E48F339D7393
• netc.dll version 1.7.0.26700
• netc.dll SHA-256: 3F32049A9EE7D88CEDB4B8A651FD78BD84E799B7528F29374EC3D0DA1B04543D

All of the original MTA files had valid signatures. The netc.dll RVAs below are for the exact hash listed above.

What happens when I launch it

The normal, unmodified version does this every time:

1. Multi Theft Auto.exe starts.
2. It loads loader.dll, netc.dll, and pthread.dll.
3. File and registry activity stops after roughly 100 ms.
4. The main thread uses CPU for about 10 seconds.
5. It enters another polling/watchdog phase for about five seconds.
6. It exits with 0xC0000409.
7. core.dll is never loaded.

The public loader source calls CheckService(7 /* CHECK_SERVICE_POST_CREATE */) before loading core.dll, so the fact that core.dll never appears means it is getting stuck inside that call.

The loader code is here:
https://github.com/multitheftauto/mtasa-blue/blob/master/Client/loader-proxy/main.cpp

I also checked the registry theory. The ACCESS DENIED entries I originally saw were attempts against the 64-bit registry view. MTA then successfully accessed the correct WOW6432Node branch. Creating the requested Settings\general key didn't change the behavior either.

What the CPU trace showed

I captured an elevated WPR CPU trace with 10,150 samples from the failing process.

• 9,241 samples were at netc+0x2AE41C.
• 9,993 samples had the same main stack.

netc+0x2AE41C
netc+0x2C162C
netc+0x292E5D
netc+0x2F7E6F
netc+0x391337
netc+0x39141C
loader+0x40D99
loader+0x8B94B
loader+0x128D3
loader+0x11F73
loader+0x429A1

The loop at netc+0x2AE41C reads the monotonic clock from KUSER_SHARED_DATA and compares the elapsed value with 0x05F5E100. That works out to exactly 10 seconds.

After that it reaches a watchdog at netc+0x2DFFB0, waits another 5,000 ms, and executes fast-fail code 7. That accounts for the full 15-second delay and the final 0xC0000409 exit.

Right before the wait, it logs internal event 0x527 with this 14-byte payload:

01 44 02 20 4C 64 72 70 57 4E 20 01 44 17

The check that seems to be broken

The stable caller at netc+0x2C162C led me to a function beginning at RVA 0x2C1230.

This function resolves ntdll!LdrRegisterDllNotification, scans its first 0x100 bytes, and looks for a few hard-coded instruction forms. It then treats the address from the first match as Windows' internal DLL-notification list and walks it.

The disassembly looks roughly equivalent to this:

for (int offset = 0; offset < 0x100; ++offset)
{
    const std::uint8_t* p = function + offset;

    if ((p[0] == 0xB9 || p[0] == 0xBF || p[0] == 0xBE) &&
        p[5] == 0xE8)
    {
        listHead = *reinterpret_cast<const void* const*>(p + 1);
        break;
    }

    if (p[0] == 0x68 && p[5] == 0xE8)
    {
        listHead = *reinterpret_cast<const void* const*>(p + 1);
        break;
    }

    if (p[0] == 0x8B && p[1] == 0x0D)
    {
        listHead = *reinterpret_cast<const void* const*>(p + 2);
        break;
    }
}

The problem is the last part. It accepts the first 8B 0D (mov ecx, [absolute-address]) without checking what that address is actually being used for.

What changed in Windows 26H1

On my 32-bit ntdll.dll, LdrRegisterDllNotification is at RVA 0x298A0.

These are the important instructions:

+0x1C  mov edx,[ntdll+0x135358]
+0x22  mov ecx,[ntdll+0x1353F8]  <-- netc selects this one
+0x28  push 0x10
+0x2A  lea edx,[edx+0x40000]
+0x30  call <internal helper>
...
+0x4F  mov eax,[ntdll+0x134388]
+0x54  mov ecx,ntdll+0x134384     <-- this is the actual list head
+0x59  cmp [eax],ecx
+0x5B  jne <fast-fail>
+0x5D  mov [esi],ecx
+0x5F  mov [esi+4],eax
+0x62  mov [eax],esi
+0x65  mov [ntdll+0x134388],esi

The 8B 0D at +0x22 is setup for the helper called at +0x30. It isn't the notification-list head.

The real list insertion happens later. The tail is loaded at +0x4F, the list-head address is moved into ecx at +0x54, and the following instructions link the new entry into that list.

What was saved in the memory dump

The full dump from the original, unmodified process confirms what happens next.

MTA selected ntdll+0x1353F8. In that process, the value stored there was 0x01730000.

The first fields at that address were:

[0x01730000 + 0x00] = 0x7ADC40FA
[0x01730000 + 0x04] = 0x01002C95
[0x01730000 + 0x08] = 0xFFEEFFEE
[0x01730000 + 0x0C] = 0x00000002

MTA treated 0xFFEEFFEE as a callback address. It couldn't associate that address with a loaded module, then followed 0x7ADC40FA as if it were the next list entry. That address wasn't readable process memory.

The protected handler catches this bad walk, logs event 0x527, waits 10 seconds, runs the five-second watchdog, and closes the process with 0xC0000409.

I also made a small read-only probe that repeated the same instruction scan in a fresh 32-bit process. It selected ntdll+0x1353F8 again, but the value was 0x03430000 that time. The fact that it points to a different allocation each run is another sign that this isn't the static list head the check expects.

How I tested the theory

I altered a local copy of netc.dll for this test. I kept the original installation untouched.

I changed exactly two bytes in the altered DLL:

netc.dll RVA	File offset	Original	Changed	Reason
0x2C138D	0x2C078D	E8	39	Accept the 26H1 mov ecx, listHead form when it is followed by cmp
0x2C13AE	0x2C07AE	0D	0C	Stop the earlier unrelated 8B 0D from matching

Original netc.dll SHA-256:

3F32049A9EE7D88CEDB4B8A651FD78BD84E799B7528F29374EC3D0DA1B04543D

Changed test DLL SHA-256:

AECC9FEF4180643E6F706976414B5352B1068E1F244BD953F0DE22191F4CFE20

Here are the results:

Run	netc.dll seen	core.dll seen	Result
Original	Loaded	Never	Exited 0xC0000409 after about 15 seconds
Changed copy 1	200 ms	514 ms	Got past the original failure
Changed copy 2	76 ms	154 ms	Got past the original failure
Changed copy 3	37 ms	132 ms	Got past the original failure
Changed copy 4	35 ms	160 ms	Got past the original failure

All four runs loaded netc.dll and core.dll from the separate test folder. I stopped each process as soon as core.dll appeared.

I then tried launching the changed copy normally. It got further but showed:

MTA:SA client integrity violation. [CL29]

That part makes sense because changing the DLL breaks its signature/hash. The important difference is that this happens after the point where the original version fails. The changed DLL had already returned from the failing check and allowed core.dll to load.

Why I think this confirms it

This doesn't just hide the final fast fail or skip the whole service check.

The only changes were to the two instruction recognition assumptions. Once the scanner ignored the wrong address and accepted the actual 26H1 list-head instruction, CheckService returned and core.dll loaded every time.

As far as I can tell, this rules out the registry, the missing serial value, an injected DLL, and the NtQuerySystemInformation hook theory. I checked the live NtQuerySystemInformation stub too, and it matched the signed Windows DLL after normal relocation.

Possible fix

The safest fix would be to avoid finding a private Windows loader list by disassembling LdrRegisterDllNotification. The instruction order inside this function isn't a public API and clearly changed with the new Windows core.

If this check needs to stay, I think the following would make it safer:

1. Don't accept the first 8B 0D without validating what it points to.

2. Match the actual list-insertion sequence instead of one instruction. On this build it looks like:

   A1 <tail-address>
   B9 <list-head-address>
   39 08
   75 ...
   89 0E
   89 46 04
   89 30
   

3. Validate the list before walking it:

   • Make sure the head, Flink, and Blink are aligned and readable.
   • Check that Flink->Blink and Blink->Flink point back to the current entry.
   • Use an iteration limit and stop on malformed entries.
   • Make sure callback addresses point to executable mapped memory.
   • Reject a bad candidate safely instead of relying on an exception after dereferencing it.

4. Add a regression test using the 32-bit ntdll.dll versions from Windows 11 25H2 and 26H1.

The current source should be findable by searching for the code that resolves the string LdrRegisterDllNotification, scans 0x100 bytes, and checks for the opcodes 0xB9, 0xBF, 0xBE, 0x68, and 0x8B 0x0D.

If someone can provide a signed netc.dll with the equivalent fix, I can test the complete launch path on build 28000.2340 without triggering CL29.

Follow Up

I did another comparison and managed to narrow the build boundary much further.

I downloaded the untouched official r24109 release and tested it on the same Windows 11 26H1 installation:

• netc.dll version: 1.6.0.24109
• SHA-256: 3794944BA9C6B3BF5A29713DE797453513EF7C63629A701BD956C40290E2C7AB
• Signature: valid
• netc.dll loaded at 214 ms
• core.dll loaded successfully at 542 ms

I stopped the process as soon as core.dll appeared.

Static comparison:

• r23409 working: no LdrRegisterDllNotification string/scanner
• r24109 working: no LdrRegisterDllNotification string/scanner
• r24121 failing: first failing build I previously tested
• r26700 failing: scanner present and confirmed as the cause

This narrows the likely introduction to r24110–r24121.

The official r24110 build note looks particularly relevant:

Force rebuild - Carries fix for integrity failures caused by 3rd party AV (suspending game threads), etc.

r24110 corresponds to commit/build record bd257a28940c06bb55eefc58d91d9c892058ba55 from 27 May 2026.

[Lpsd]

r26702 should resolve these issues, please let us know: https://nightly.mtasa.com/mtasa-1.7-untested-26702-20260711.exe

note: this is a development build, 1.7 is not officially released yet - so there are barely any populated servers. we plan to release very soon

[HeresHavi]

r26702 should resolve these issues, please let us know: https://nightly.mtasa.com/mtasa-1.7-untested-26702-20260711.exe

note: this is a development build, 1.7 is not officially released yet - so there are barely any populated servers. we plan to release very soon

Good news, the issue has been resolved. Thank you very much! It was a nasty one