-1073741819 error code after my c++ application is successfully exit with 0.

Thank you for reaching out.

-1073741819 is not a normal “return 0” from your program. It maps to 0xC0000005, which means the C++ process ended because of an access violation (crash). So Windows is reporting that the process crashed, and that is why your C# app sees this exit code.

From your latest update, the behavior happens only when your C++ code calls ShellExecuteEx. That is a strong sign the crash is happening in the ShellExecuteEx path, not in your normal output logic.

A key detail is that ShellExecuteEx can hand off work to Shell extensions and COM components. Microsoft notes that COM should be initialized before calling ShellExecuteEx, because some Shell extensions require it.

So, a practical suggestion is:

• Make sure COM is initialized in the thread before calling ShellExecuteEx (some Shell extension handlers depend on it).
• Check Windows Event Viewer > Application logs at the time it happens, because it usually shows the faulting module and confirms where the crash is coming from.

Also, since you are launching an executable, another safe option is to avoid Shell-based launching if you don’t need file association behavior. ShellExecuteEx is meant for “shell verbs / associations”, and it can involve extra shell components. If you only need to start an exe with arguments and wait for it, using a direct process creation approach (like CreateProcess) avoids shell extensions and can be more predictable. (This is a general recommendation based on how ShellExecuteEx works.)

References

• Exit code -1073741819 equals 0xC0000005

Please let us know if you require any further assistance, we’re happy to help. If you found this information useful, kindly mark this as "Accept Answer". So that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

Hi,

i noticed similar behaviour when starting a new Process of a .net application from another .net application.

The problem first occurred with Microsoft 365 Update 16.0.19628.20150 and is still present with 16.00.19725.20058.

With Native Debugging enabled I could track down the source of the Access Violation to Mso98win32client.dll

Here is probably the same error reported: https://developercommunity.visualstudio.com/t/Error-with-Mso98win32clientdll/11043824?pageSize=15&sort=active

Our Application ist using the Microsoft Access Driver to connect to a .mdb Database.

The wrong return code ist provided as soon as the Database Connection is opened.

After i narrow down the problem, if i call below statement, i am getting this error code to C# appliciation.

// Call the application with argument list.

bStatus = ShellExecuteEx( &sei );

There is no issue in my output, but only after my c++ application exited, i am getting this error code to C# application.

If i stop calling this ShellExecuteEx to launch an exe in C++ application, then i am not getting any error code.

This is how my code to launch an exe.

BOOL bStatus = FALSE;

CString csVerb = _T("open");

SHELLEXECUTEINFO sei = {0};

// Set up to launch the application.

sei.cbSize = sizeof( SHELLEXECUTEINFO );

sei.fMask = SEE_MASK_NOCLOSEPROCESS;

sei.lpVerb = _T("open");

sei.hwnd = hWndParent;

sei.lpFile = csFilename;

sei.lpParameters = csArguments;

// Set up show/hide state

if ( !bShowGUI )

{

// Indicate to the process to NOT display its GUI.

sei.fMask |= SEE_MASK_FLAG_NO_UI;

sei.nShow = SW_HIDE;

}

// Else:

else

{

// Indicate to the process to show its GUI.

sei.nShow = SW_SHOWMINNOACTIVE;

}

// Call the application with argument list.

bStatus = ShellExecuteEx( &sei );

// If unable to launch the executable:

if( !bStatus )

{

hErrorCode = sei.hInstApp;

return bStatus;

}

// If waiting for application to finish then capture the exit code

if ( bWaitForExit )

{

dwExitCode	= STILL_ACTIVE;

WaitForSingleObject( sei.hProcess, INFINITE );

GetExitCodeProcess( sei.hProcess, &dwExitCode );

// ShellExecute returns a value > 32 upon success.

if ( (LONG_PTR)( sei.hInstApp ) <= 32 )

{

	hErrorCode = sei.hInstApp;

}

}

return bStatus;

There is no information in the provided material that indicates a known Microsoft 365/Office 365 (64-bit) update that changes process exit behavior or causes a C++ process that returns 0 to be observed as exiting with -1073741819 when launched from a C# WPF application.

The only Office-related known issue in the context is specific to Microsoft 365 apps (Word, Excel, Outlook, etc.) crashing on Windows Server 2016 after updating to Version 2412 (Build 18324.20168 or 18324.20190), which is fixed in Version 2412 (Build 18324.20194). That issue is about Office apps themselves crashing and does not mention any impact on unrelated processes’ exit codes or on the Windows process model.

Similarly, the other referenced items concern:

• A race condition between ExitProcess() and ExitThread() on Windows 7 / Windows Server 2008 R2.
• General C/C++ application loading and side‑by‑side assembly issues.
• Application crashes in Visual C++ runtime DLLs.

None of these documents describe Office 365 (64‑bit) installing components that change exit codes of arbitrary processes or interfere with how Process.ExitCode is reported in .NET.

Based on the available information, there is no documented Microsoft 365/Office 365 issue matching the described behavior.

References:

• Classic Outlook and Microsoft 365 applications crashing on Windows Server 2016
• FIX: The ExitProcess() function may not return the correct value in Windows 7 or in Windows Server 2008 R2
• Troubleshooting C/C++ Isolated Applications and Side-by-side Assemblies
• Office 365 Winword.exe issue at startup Win11 Home 25H2 64 bits - Microsoft Q&A
• How can I get office 365 to work? - Microsoft Q&A
• How to fix the issue with MS Office asking you to log in every time you open an Office app - Microsoft Q&A
• MVC140.DLL Error after Windows OS Updates - Microsoft Q&A
• Application crashing faulting module MSVC100.DLL - Microsoft Q&A