RunAsHighest: Compatibility Fix vs Compatibility Mode

[UCyborg]

Looks like this bug exists since at least Windows 7. While Windows 7 doesn't have compatibility entry for Mass Effect, it exists for another program (Internet Everywhere) and contains RunAsHighest shim. so the inability to disable its entry (at least RunAsHighest part) in compatibility database can be re-produced with it.

I changed the binary name and modified manifest accordingly to be picked up by the Compatibility Engine. In the ZIP file you'll find test binaries and registry files to toggle the compatibility entry on and off. Extract all files in the same location and run AutoRunCardDetector.exe.

Here's the interesting part, the reason I was unable to reproduce the bug with Quake IV is that it uses RunAsHighest COMPATIBILITY MODE rather than COMPATIBILITY FIX.

[mirh]

Thank you. I could never have been bothered to counter-check in previous versions.
Seems like a deeper fuckup than I had imagined.
Can you at least eradicate the goddamn compatibility engine in W7 though?

[UCyborg]

There's a group policy setting. If you have gpedit.msc, the path is Computer Configuration\Windows Components\Application Compatibility\Turn off Application Compatibility Engine. Works on Windows 7, but not on 8.1/10. Don't have Windows 8 to test.

Edit: Never mind, still have a snapshot of Windows 8 install without any updates, Compatibility Engine can be disabled on it with group policy.

[mirh]

Interesting. So we have like possibly two problems to tackle (even though bisection shouldn't be that hard for the second)
Also, I wonder if bringing in Vista in the contest might or might not help.

EDIT: reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\AppCompat /v DisableEngine /t REG_DWORD /d 1 and you should be good to go after a reboot (even without policy editor)

[UCyborg]

Just tried Vista, same story as with 7. Whether you're dealing with a system or user created database, disabling specific entry keeps RunAsHighest shim active if present, while other shims appear to be disabled as expected (hopefully, who call tell if there aren't more exceptions).

[mirh]

https://pcgamingwiki.com/wiki/Mass_Effect#Game_always_asks_for_admin_permissions
Set __COMPAT_LAYER=RunAsInvoker makes the thing works finally.

I'd still love to deepen which windows 8 update introduced second problem.
EDIT: update to 8.1 precisely, no ifs or buts

[UCyborg]

Looks like RunAsInvoker trick also works for executables detected as installers which have GenericInstaller shim applied. Not all such executables are installers, some games have separate executables for configuring certain options.

[mirh]

Ok so, I can confirm your 8.1 findings.
So, long story short, there are 3 problems morons at microsoft should understand:

• RunAsHighest is broken (Vista+)
• Mass Effect fix is bad and wrong (8.1+)
• Application Compatibility Engine is always on (8.1+)

Speaking of the latter, I wonder if "Domain Policy" might not play a role?

[UCyborg]

There are couple of other games with wrong fixes that I'm aware of: Interstate '82, Drakan, GTA III, GTA: Vice City

Interstate '82: EmulateHeap crashes it, HeapValidateFrees is the correct one. One of those games with buggy memory management...
Drakan: IgnoreLoadLibrary - no idea how to check which library it even ignores, it's supposed to make LoadLibrary call fail for certain DLL(s). There's also IgnoreAltTab; AFAIK there are no issues critical enough to warrant it, maybe some ancient drivers from XP era caused a blue screen?

The GTA games are interesting, DXMaximizedWindowedMode is applied for the sole purpose of fixing black screen with intro videos, some compatibility issue between DirectDraw and DWM. What also works is DXPrimaryEmulation shim with -RedirectPrimarySurfBlts parameter. Now here's something even more curious; GTA: San Andreas has the same issue, but the latter fix doesn't work for it.

Regarding domain policy, this would be relevant only to domain joined computers, in which case the setting would have to be altered on the domain controller, if it was overridden there in the first place. Been a while since I messed with Windows Server.

There was a time when a policy for disabling lockscreen was ineffective on Windows 10 and then some update fixed it.

[mirh]

Yes, but I meant, nonetheless the fact that you aren't part of a domain - it could be that some alleged "higher level" setting is overriding the other choice (instead of the simpler to imagine "they just fucked up the engine").

Then, yes, I guess it's no surprise that in a sea of thousands of fixes, some others aren't really for the best. Though having to figure out what is the right Heap problem, or what other magic goes on under the hood of games, is something much harder (that I can very much more forgive) imo than the retarded thing they did with ME, that seemed just copy-pasted blindly from a random forum.

Anyway, discussion for those single cases should go on PCGW I guess. Perhaps also asking what should be the best actual shimming practice (I mean, I very very much love one liners to use from command line.. But I can see how not all games have a "parsable" path-to-executable) - maybe a single unified .sdb per-Windows-version could be the bestest of all? Idk.

I'd like to keep this just about Windows-own bugs instead (rather than the databases)

p.s. San Andreas is really a mess but iirc we had made it on gtaforums

[UCyborg]

I just mentioned few other examples because you brought up Mass Effect. Interstate '82 is quite obvious, crashes out-of-the box on XP as well and renaming executable magically fixes it. Though the HeapValidateFrees is only needed on newer versions, haven't checked which version exactly, but definitely on 8.1 and 10.

Those fixes for San Andreas are actually already part of system databases, at least they're effective for version 1.0 EXE, I was merely looking for a better fix than the atrocious fake windowed mode, which can cause other problems. More for curiosity sake than anything else.

Anyway, back on topic at hand, the option for disabling compatibility engine was intentionally removed and there is no "higher level" setting. A workaround that works on Windows 8.1:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SafeBoot\Option]
"OptionValue"=dword:00000001

Import this into registry, log off and back on and the compatibility engine will be disabled, only Compatibility tab will remain in EXE properties. This is the special setting for activating safe mode, so it mustn't be present during boot sequence or must be set to 0.

The problem is in BaseIsAppcompatInfrastructureDisabled/BaseIsAppcompatInfrastructureDisabledWorker functions in kernel32.dll. They're not implemented like they were on Windows 8 and below, the registry setting check for disabling the engine has been removed. They always return 0 on Windows 10 and Windows 8.1 version only reads the safe mode setting to determine what to return. Also, they must return 0 under specific circumstances even if the user doesn't want Compatibility Engine. Making them always return 1 will BSOD OS during boot sequence.

[mirh]

Oh god, then it was intentional and all.
So without further ado, I guess like I can call this a day, thank you.