(In reply to Nathan Froyd [:froydnj] from comment #7)
(In reply to Doug Thayer [:dthayer] (he/him) from comment #1)
I'm not sure if there's much we can or want to do about this. It's also not very critical at all. Crashing basically accomplishes exactly what we were hoping for: terminating the process, albeit with the side effect of creating a crash report. I'm not sure how this is failing: if somehow process doesn't have the TERMINATE_PROCESS access right for itself, then I suppose we would hit this.
I think before this we were just calling
_exit(0);; can we go back to doing that? One would think from reading the documentation on
TerminateProcess that terminating yourself should just work, but that is apparently not the case.
Alternatively, windows experts say that
!gle in windbg will (ideally) tell us why
TerminateProcess is failing, so maybe we could attempt to fix that instead.
There were two locations which were doing similar things, which we merged into one. One of them was calling
_exit(0), and the other was calling
TerminateProcess. The problem with calling
_exit(0) is that it calls
DllMain on any loaded assemblies with a
DLL_PROCESS_DETACH argument. This can cause Bad Things to happen, because it immediately terminates any threads running, which could for instance be locking on a mutex which the
DllMain for the loaded assembly may want to try to lock, thus inducing a deadlock. So if we're going to forcefully terminate things, we need to ensure we're forcefully terminating everything.
I suppose we could annotate the crash with the result of
::GetLastError() though? I don't see why we need to / how we could involve windbg without being able to reproduce this locally. I have a suspicion that it will return
ERROR_ACCESS_DENIED, and it will turn out that some third-party software has for some reason revoked our
PROCESS_TERMINATE access right.