Release 1703 (and 1709) Edge browser opens and self closes with Software Restriction Policies enabled RRS feed

  • Question

  • First off, I'm a security nut. Even at home I use a Pro edition of Windows 10, and I use a non-admin user account with Software Restriction Policies enabled so I can prevent zero-day malware. If it isn't installed in Program Files, Program Files (x86), or the OS folder, it doesn't run.

    I have a web series based on that so you can see what I do here. Notably with SRP, I have a Disallowed rule set by default, I apply the rules to all users except local admins (elevated applications still work from any location), I apply the rule to all executables including DLLs, and I have Unrestricted settings for both Program Files folders and the OS folder. This is how I do it:

    This broke Windows 10's Windows Defender automatic updates until I learned that WD works from a folder in ProgramData or %allusersprofile%. I had to add that folder to the Unrestricted list, and then automatic updates worked again.

    Now in Release 1703 (and as of today, Release 1709), the Edge browser stops working with these settings. The new Edge browser is trying to execute something in the current user's profile folder, which I think is from its new support for user-installed plugins from the Windows Store. Other Store applications still seem to work.

    [edit] At one point I thought adding an Unrestricted rule to C:\Users made it work, but it doesn't. It appears Edge will fail even with a default Unrestricted rule and no Disallowed rules present.

    [edit] If I turn off DLL checks, Edge works again. But this means some user can fall prey to a link that executes "rundll32.exe evilmalwareinhomefolder.dll" and again defeat the purpose of SRP.

    What is Edge looking for? Is there a specific folder in the current user's profile that Edge needs to execute program code from?

    • Edited by Gordon Fecyk Friday, October 20, 2017 5:25 PM Fails even with default Unrestricted rules and DLL checks turned on
    Monday, October 16, 2017 3:32 PM

All replies

  • >>The new Edge browser is trying to execute something in the current user's profile folder

    You have found out the cause of current situation, Edge serves as a Store app which is located in C:\Windows\SystemApps\Microsoft.MicrosoftEdge_8wekyb3d8bbwe, like other Store apps.

    However, it is a little special, Edge has some user configurations(such as Favorites) that store in path C:\Users\v-liutan\AppData\Local\MicrosoftEdge, yes, it needs to visit user profile. So you need to add an Unrestricted rule to C:\Users\username.


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Tuesday, October 17, 2017 2:08 AM
  • However, it is a little special, Edge has some user configurations(such as Favorites) that store in path C:\Users\v-liutan\AppData\Local\MicrosoftEdge, yes, it needs to visit user profile. So you need to add an Unrestricted rule to C:\Users\username.

    I tried this at one point. If an application recognizes environment variables, I can use %userprofile%\[path] as a rule and it will work. I found that some Store apps didn't like it though, so I had to replace the default rules such as %systemroot% with hard coded path rules like C:\Windows.

    I don't believe Edge recognizes %userprofile%. Maybe it would recognize C:\Users\%username%\AppData\Local\MicrosoftEdge? I'll try some tests.

    What has me confused is I didn't need to do this in Release 1607, but I might need to do it in Release 1703, even if I don't have any user-installed plugins. Favorites and other user data aren't program code though, so why would I need to add an SRP rule for user data? Unless Edge in 1703 stores Favorites in a DLL or OCX-like construct, maybe. In which case, watch out for poisoned favorites doing code injection.

    I can't mark it as an answer yet as I haven't tested it, but it's a good suggestion to start with.
    Tuesday, October 17, 2017 1:23 PM
  • I've picked through my test PC and, even with an Unrestricted rule for C:\ (seriously?), Edge opens and self-closes with SRP DLL enforcement enabled. The former test for C:\Users isn't working anymore, and neither is adding C:\ProgramData, or even the whole system drive.

    Could this be a restriction in something that isn't a file system object? The last time I ran into this sort of problem, I tried using environment variables in SRP paths, and that broke some store apps like the new Minesweeper.

    What could Edge be trying to load as a DLL that isn't a file system object?

    I'm going to have to take this to the Insider Program forums again. They told me to come here, but this is an odd bug and I don't believe there's general knowledge enough to fix it.

    Tuesday, October 17, 2017 2:48 PM
  • Apparently, this problem is more generic than just with Edge, and I'll have to re-post this to another Windows 10 forum.

    It turns out just having SRP DLL checks turned on breaks Edge. I could have a default Unrestricted rule, not have any Disallowed rules at all, and Edge will still choke and close its own window. Edge will work with SRP if, and only if, DLL checks are turned off.

    I've only seen one other instance of this sort of behavior, here:

    According to this user, just having SRP enabled will break their application, even with all rules set to Unrestricted.

    Friday, October 20, 2017 5:05 PM
  • Hi Gordon,

    I had similar issue but I am not sure it was SRP specific issue.

    I resolved it using:

    More specifically adding a registry entry per user as follows:

    reg add "HKCU\Software\Microsoft\Internet Explorer\Spartan" /v RAC_LaunchFlags /t REG_DWORD /d 1 /f

    Monday, November 13, 2017 9:05 PM
  • I am having a similar SRP issue that does not let me type anything at the start menu/edge unless I login as administrator. Have you come across this issue?

    I have identical SRP policies as you do.

    • Edited by Multra Monday, November 13, 2017 9:07 PM
    Monday, November 13, 2017 9:07 PM
  • This isn't making a difference. The key didn't exist, and adding it along with the value RAC_LaunchFlags made no difference.

    And why would adding a setting for IE make a difference in Edge?

    Now on Build 17035 / 171103-1616 and am getting the same result with DLL enforcement enabled.

    Tuesday, November 14, 2017 9:36 PM
  • I agree that it does not make any sense. I am trying to wrap my head around this myself. In fact, the solution I liked above is not acceptable, though it works for me, so I am back to square one.

    Opened my own thread also: Here

    I am trying to trace it down using ProcMon and whitelist the "Access Denied" entities but so far it makes no difference.

    When opening Edge, ProcMon shows MicrosoftEdge.ex having difficult time accessing: 

    • C:\Windows\SystemApps\Microsoft.MicrosoftEdge_8wekyb3d8bbwe
    • C:\users\myuser\AppData\Local\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe

    Both of which I tried whitelisting with no result.

    There are also frequent "Access Denied" references to:

    • %HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\Properties%
    • %HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization%

    which come up when launching Edge but i am not sure are relevant. Whitelisting those makes no difference either.

    Funny enough, Edge isn't working for me as domain administrator either, its not only specific to a normal user. It did work just fine without SRP applied.

    • Edited by Multra Wednesday, November 15, 2017 12:07 AM
    Tuesday, November 14, 2017 11:39 PM
  • Multra, have you tried without DLL enforcement turned on? That is, have "All program files, except libraries" turned on instead of "All program files?" If Edge works after doing that, then you're running into the same problem I am.
    Thursday, November 16, 2017 2:38 PM
  • I have tried that and Edge and other issue work fine after allowing DLLs.

    In fact, I even removed all of my whitelisted paths since I started troubleshooting the issue and no issues with DLLs allowed.

    To me it is not an acceptable workaround as it is equivalent to not having SRP at all.

    I since switch enforcement back to "All software files" and I enabled the advanced SRP logging on my W10 station. Interestingly enough, ALL DLLs are allowed, nothing is blocked! That is why Event Viewer is silent.

    I am a bit perplexed as to where to even look if even advanced logging doesnt capture blocking that SRP is doing.

    • Edited by Multra Friday, November 17, 2017 5:09 PM
    Friday, November 17, 2017 5:00 PM