No worries, you don't need to apologise, I appreciate that you were trying to help I just wish Microsoft would de-couple their browsers from the operating system a bit more - wasn't Edge supposed to be built as a UWP anyway?
I don't have a solution for Edge (I don't use it anyway). However, SRP also broke Windows Defender Updates for me. Adding an Unrestricted Path rule for C:\ProgramData\Microsoft\Windows Defender as suggested here seems to solve that problem.
If using AppLocker and you have created rules, run it as audit first so you know what works and what doesn't. If something doesn't work, you'll have to create a Path rule for it so it can run.
With SSRP, fix is simple. Just add the executable to the software.ini file, save it and allow the policy change to take effect. That should now allow a previously blocked executable to run.
The problem regarding Edge is not that its executable is blocked. The problem is that Edge is unusable if - and only if - SRP is applied to DLLs. Hence, I doubt that adding that executable to the SSRP ini file is the solution. To be more specific: I've seen error messages related to kernelbase.dll and emodel.dll. So far I haven't been able to fix the problem by adding path rules for them.
I've been using SRP in this way for years and it's the first time that this happened to me. Granted, Windows is only my secondary OS since I'm a Linux user - so full-time Windows users might have run into more problems.
Excluding DLL's from the policy will weaken SRP's defenses against malware that uses malicious DLL's to infect their targets. It's kind of a catch 22.
Agreed. Still DLLs need to run unrestricted for legitimate software to run. Its a tradeoff and I just set the policy like AppLocker does: deny everything but DLLs from running.
Same here, I've been running SRPs with DLL enforcement with no problems ever since I joined Wilders. Only ever had minor issues which were easily fixed with a path rule. As you pointed out earlier, path rules don't fix this issue because nothing seems to be blocked by SRP, as evidenced by the SRP logs. If Microsoft don't fix the Cast To DLNA Device functionality in Edge for me soon, then I'll be ditching it and happily going back to DLL enforcement.
Thought I'd experiment with a different software restriction method to see what the effect would be. After reading a heap of posts in the Other Anti-Malware Section I chose to use Bouncer by Excubits. It seems to perform a very similar function to Windows built-in SRP and also applies restrictions to DLLs. So I loaded it up with the same path rules I was using with SRP and guess what? MS Edge works without any issues. So further proof, if any was needed, that setting SRP to enforce DLL restrictions in Windows Creators Update breaks Edge - even though no DLLs are actually being restricted - go figure! Think I will stick with Bouncer from now on rather than opening holes in Window's SRP for no good reason.