When a process terminates itself the TerminateProcess call is not supposed to return. Doing so is illogical and pointless and generally a bad idea. Microsoft's own source code shows that they do not expect this function to return when called to terminate the calling process. I have looked in the source code samples which Microsoft ships in Visual Studio and in the Windows 10 SDK. These include:

Professional\VC\Tools\MSVC\14.13.26128\atlmfc\include\atldef.h(607):  #define _ATL_FATAL_SHUTDOWN do { ::TerminateProcess(::GetCurrentProcess(), 0); } __pragma(warning(suppress:4127)) while (0)
Professional\VC\Tools\MSVC\14.13.26128\crt\src\vcruntime\gs_report.c(160):        TerminateProcess(GetCurrentProcess(), STATUS_SECURITY_CHECK_FAILURE);
Professional\VC\Tools\MSVC\14.13.26128\crt\src\vcruntime\throw_bad_alloc.cpp(21):        TerminateProcess(GetCurrentProcess(), 3);
Professional\VC\Tools\MSVC\14.13.26128\crt\src\vcruntime\throw_bad_alloc.cpp(26):        TerminateProcess(GetCurrentProcess(), 3);

Windows Kits\10\Source\10.0.16299.0\ucrt\misc\dbgrpt.cpp(427):        TerminateProcess(GetCurrentProcess(), 3);
Windows Kits\10\Source\10.0.16299.0\ucrt\misc\invalid_parameter.cpp(233):        TerminateProcess(GetCurrentProcess(), STATUS_INVALID_CRUNTIME_PARAMETER);
Windows Kits\10\Source\10.0.16299.0\ucrt\startup\exit.cpp(46):    TerminateProcess(GetCurrentProcess(), return_code);
Windows Kits\10\Source\10.0.16299.0\ucrt\startup\exit.cpp(136):        TerminateProcess(GetCurrentProcess(), return_code);

In all of these cases Microsoft calls TerminateProcess(GetCurrentProcess(), exit_code); and clearly assumes that the process will stop at that point. In addition there is this comment from Windows Kits\10\Source\10.0.16299.0\ucrt\startup\exit.cpp:

// For Windows Store apps, starting in Windows 10, we use TerminateProcess
// instead of ExitProcess.  ExitProcess will allow threads to run during
// termination in an unordered fashion. This has lead to problems in various
// apps.  TerminateProcess does not allow threads to run while the process is
// being torn down.  See also CoreApplication::Run, which does the same.

So, it seems clear to me that TerminateProcess of self is not *supposed* to return.

On the other hand, it is equally clear that on some machines it *does*. A CHECK(false) added in this change:

https://chromium-review.googlesource.com/c/chromium/src/+/791826

is being hit by some small number of Chrome users. It is not known why or how, but it is known that most of the machines hitting this issue have one of two third-party DLLs in the process:

- 92% of the crashes show akinsofthook64.dll in the process
- 6% of the remaining crashes show Graphics64.dll in the process

Correlation is not causation, but it is a pretty good hint.

I'm interested in ideas about what to do in this situation. WaitForSingleObject(GetCurrentProcess(), INFINITE) has been suggested but since it means "don't run code in this process until this process dies" it doesn't really make sense. A Sleep(1000) loop would avoid the crash but might just turn it into a hang. My belief is that a crash is actually the least-bad way to deal with this situation.

This is a publicly visible version of crbug.com/793277, created to document this odd behavior in the hopes that a solution can be found (maybe the authors of these DLLs can explain what is happening or can fix their code, or maybe Microsoft can do something?) or that others can be made aware that this can happen to their software also.

Some discussion of this issue can also be found here:
https://stackoverflow.com/questions/40427263/is-waiting-needed-after-terminateprocessgetcurrentprocess-exit-code