Procmon.exe. Give me 2 minutes. You make it sound like it's such a difficult thing to do. It literally will not take me more than 2 minutes to tell you exactly where the permission issue is and how to fix it.

Procmon won't show you every type of resource access. Even when it does, it won't tell you which entity in the resource chain caused the issue.

And then you get security product who have the fun idea of removing privileges when a program creates a handle (I'm not joking, that's a thing some products do). So when you open a file with write access, and then try to write to the file, you end up with permission errors durig the write (and not the open) and end up debugging for hours on end only to discover that some shitty security product is doing stupid stuff...

Granted, thats not related to ACLs. But for every OK idea microsoft had, they have dozen of terrible ideas that make the whole system horrible.

Especially when the permission issue is up the chain from the application. Sure it is allowed to access that subkey, but not the great great grandparent key.

Shitty security products being inscrutable isn't limited to Windows. "Disable SELinux" anyone?

While that's true, linux _tends_ to follow the rules a bit better, and not change how APIs work from under your feets. For instance on Linux, permission checks are done when you open a handle. An LSM like SELinux can only allow or deny your rights to open the handle at the permission level you requested, that's it. It cannot allow the handle to be opened, but with less privileges than requested, nor can it do permission check at operation time. So once your open is successful, you can be pretty sure that you've cleared the permission checks bar, and are good to go.

This makes writing robust code under those systems a lot easier, which in turns makes debugging things when it goes wrong nicer. Now, I'm not going to say debugging those systems is great - SELinux errors are still an inscrutable mess and writing SELinux policy is fairly painful.

But there is real value in limiting where errors can crop up, and how they can happen.

Of course, there is stuff like FUSE that can throw a wrench into this: instead of an LSM, a linux security product could write their own FS overlay to do these kind of shenanigans. But those seem to be extremely rare on Linux, whereas they're very commonplace on Windows - mostly because MS doesn't provide the necessary tools to properly write security modules, so everyone's just winging it.

Is this a trick question, because you run it as administrator in a sandboxed account.

and why is it not on the vendor of the critical application?

Because they aren't allowed on the system where it is installed, and also they don't deal with hardened systems.