The design is slightly evil in that any unauthorized change of the registry keys doesn't just fail but instead invalidates a hash and makes windows revert to the default.

There is no API difference between registry changes made by nonsanboxed user installed and built-in windows executables.

I don't know exactly how it's implemented, and feel free to tell us, but wongarsu is absolutely correct about the behavior. For a while, whenever I hit the button in firefox to change default browser, suddenly my default browser was edge. Not the old setting, not the attempted new setting. It was very clearly not designed with 'protection' in mind.

There's a hash of the registry key stored "securely" somewhere. Only the API the control panel default apps UI uses changes this registry key and updates the hash. When the application key is called to run and doesn't match the hash it's reset to the value from "C:\Windows\System32\OEMDefaultAssociations.xml"

It's terrible behavior.

What sorts of locks/permissions does this file have?

Maybe you could make a tool that lets you make changes, schedules a modification of this file on next restart, and after the restart it propagates the changes in the registry too.

Yes, "please reboot to apply your new mouse position^W^W^Wfile association changes", yay, but that'd work.

Although I'd definitely hate it.

Does direct editing via regedit work as expected or does it also reset?

It will trigger a reset because you haven't updated the hash...

Which is bizarre if you consider that the original purpose of the registry (which appeared in Windows 3.1, I believe) was only to store file associations.