This Event Viewer entry proves that TCC successfully starts tse.exe, but TSE 4.50.28 then crashes during its own startup.
The decisive fields are:
ExceptionCode: c0000005
ModuleName: tse.exe
FaultingOffset: 00047305
0xC0000005 is an access violation: the program tried to read, write, or execute an invalid memory address. It is not the STATUS_DATATYPE_MISALIGNMENT exception predicted by the stack-alignment theory; that would be 0x80000002. Microsoft’s exception documentation confirms these meanings.
The faulting offset is an RVA within tse.exe:
RVA 0x00047305
Semware can locate the responsible instruction and source function using the exact 4.50.28 executable plus its linker map or debug symbols. Because the faulting module is tse.exe itself, the crash occurs in TSE-generated code—not directly inside tcc.exe or a Windows DLL. However, TCC’s launch method evidently creates the condition that exposes the bug.
Revised technical conclusion
The evidence now supports this sequence:
TCC successfully creates the TSE process.
The Windows loader successfully loads the executable and required DLLs.
Execution reaches TSE’s own program code.
TSE accesses an invalid address at RVA 0x47305.
Windows terminates the process.
TCC returns to its prompt, making it appear that nothing happened.
This rules out:
TCC refusing the PE file;
an unrecognized executable header;
a missing imported DLL;
command alias resolution;
failure to create the process;
STATUS_DATATYPE_MISALIGNMENT.
It instead indicates a startup bug in the new compiler/runtime build, probably dependent on the process startup information supplied by TCC.
Possible causes include:
assuming a startup handle or pointer is always valid;
using an inherited standard handle without validating it;
calling-convention damage;
incorrect runtime initialization;
stack corruption;
a compiler-dependent structure layout;
incorrect assumptions about STARTUPINFO;
undefined behaviour exposed by Clang;
an ASLR-sensitive invalid pointer.
ASLR and DEP could still influence the crash, but the PE flags themselves are not being rejected.
Best information to send Semware
Event Viewer confirms that tse.exe is actually created by TCC and then crashes inside its own module:
Application: tse.exe 4.50.28
Exception code: 0xC0000005
Faulting module: tse.exe
Faulting offset: 0x00047305
Therefore this is not a failure by TCC or Windows to recognize or load the executable. It is an access violation in TSE startup code. It is also not the proposed STATUS_DATATYPE_MISALIGNMENT exception, which would be 0x80000002.
Please resolve RVA 0x47305 using the exact 4.50.28 linker map or debug symbols. That should identify the failing function and source line. Since launching through cmd.exe works, please inspect code that handles STARTUPINFO, inherited standard handles, console information, environment data and command-line initialization.
A build with debugging symbols—or a MAP file containing public symbols—would make this immediately traceable. Separate builds with ASLR disabled and with four-byte stack alignment would still be useful experiments, but the access violation location should be investigated first.
Capturing the missing crash details
Event Viewer does not state:
whether the invalid operation was a read, write, or execute;
the invalid target address;
register contents;
the call stack.
A full crash dump supplies these. Windows Error Reporting can collect one specifically for tse.exe. Run these from an elevated command prompt on the affected computer:
mkdir C:\CrashDumps
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\tse.exe" /v DumpFolder /t REG_EXPAND_SZ /d C:\CrashDumps /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\tse.exe" /v DumpType /t REG_DWORD /d 2 /f
Then reproduce the crash from TCC. Windows should create a .dmp file under:
C:\CrashDumps
Microsoft documents DumpType=2 as a full user-mode dump and supports per-application settings under LocalDumps\<application.exe>. Microsoft: Collecting User-Mode Dumps
That dump, together with Semware’s exact executable and symbols, should reveal the defective instruction, invalid address and call stack. The Event Viewer result is the strongest evidence obtained so far: this is a real startup access violation in the newly compiled TSE executable.
