ForceTermination?

[Hexaae]

No documentation for this and other shims...
Wondering if this could help fixing those games causing annoying silent crash on quit (typically 0xc0000005, or 0xc0000374...). Even recent games like Ori and the Will of the Wisps (x64) cause this problem (0xc0000374) or older games like Prince of Persia: The Forgotten Sands (0xc0000005), ENSLAVED™: Odyssey to the West (0xc0000409) and more usually related to generic "ntdll.dll"...
These games won't crash while running but on quit when they return to desktop (no pop-up warning requester or whatsoever), a crash log is simply generated in Event Viewer and Reliability Monitor.

Using MS-ACT with shims like "EmulateHeap" or "HeapValidateFrees" and "IgnoreCRTExit" (x32 only) usually is not enough.

[elishacloud]

ForceTermination just checks for when the game has only a single thread left or when the game no longer has any GUI objects in the process. It will not solve crashing issues. However, you could try using the HandleExceptions. That helps in some cases.

[Hexaae]

Thanks for quick response.
Since this is becoming a common problem (search on Steam "crash on quit/exit" for many games, even recent ones...) do you think would be possible to implement a sort of patch to force-close clean "any" game, hooking common Windows APIs for that?
Sigh... it's getting annoying finding Event Viewer full of these useless crash reports... :(

[mirh]

AFAIU the Ori and the Will of the Wisps issue was introduced in patch 3, which kinda suggests it's something very wrong with the game (even though you'd wonder how the absent devs didn't notice..)
I don't know about PoP but AFAICT 0xc0000005 is usually due to something interfering (AV or an overlay)
And ntdll.dll seems really the kind of idiot ball that ACT is for (there should be more than just those three btw, e.g. "FaultTolerantHeap")

Anyway, putting aside that "understanding of them" could all benefit from checking with older versions of software and OS (and boy couldn't even slightly different vcredist revisions matter), if everything you care is the WER nags, you can just disable it from
HKEY_CURRENT_USER\Software\Microsoft\Windows\Windows Error Reporting\ExcludedApplications.

[Hexaae]

Yes, all those problems are cause by the game themselves and well known on any cfg (HW/SW)...
Unfortunately MS-ACT's FaultTolerantHeap and other shims are not available for crashous x64 games on exit (can be enabled only for x32 tasks).

Yep, I'm considering just excluding them... sigh. In case the task has the name in common with others, can I use absolute paths in that registry key? F.e. "Prince of Persia.exe" is used for 2 different games...
I'd like to hide any crash report for those few games, in Event Viewer, Reliability Monitor etc. but it doesn't seem to work: I can still see their crashes in the above mentioned system tools.

[mirh]

Yes, all those problems are cause by the game themselves and well known on any cfg (HW/SW)...

I really don't think so.
Like, a last patch not getting the testing it deserved is conceivable (but even then I'd have my reserves for something this apparent), but a game releasing with a broken exit out of the box seems too big.
For this reason my expectation would be that it should work somewhere (presumably on an age-appropriate combination of software and perhaps even hardware).

Unfortunately MS-ACT's FaultTolerantHeap and other shims are not available for crashous x64 games on exit (can be enabled only for x32 tasks).

Because in the case of x86, it was microsoft to be breaking pre-existing (if unfortunate) conventions that had already been established. Also, I suppose memory segmentation is a legit can of worms.
Conversely, even the original windows xp x64 shouldn't be all that much different from w10.

In case the task has the name in common with others, can I use absolute paths in that registry key?

I'm afraid not, even though you can always try.. but at worst perhaps you could just rename the exes.

I can still see their crashes in the above mentioned system tools.

Uh, damn. I suppose ExcludedApplications just shuts up the popup, not detection
...or are you even sure they are still events by WER, and not just the normal "Application Error"? (what happens if you disable its service and whatnot?)