Windows 10: SrpUxSnapIn.dll Error when trying to Add New AppLocker rule for user

Hi,

I'm setting up a reference machine and want to disable access to the Windows Store App for a specific user through Applocker in the Local Security Policy application. This is one of the last things I need to complete before I am ready to capture and deploy my image. I've learned that Windows 10 Pro no longer has the ability to block access to the Store App through Group Policy, so I decided to make a rule using App Locker. Unfortunately, whenever I try add a rule, I receive a SrpUxSnapIn.dll error that states:

This error occurs immediately after clicking the select button when attempting to browse for the Store app via the Use an installed packaged app as a reference option.

I have tried running sfc /scannow, but it didn't find any errors. I also did some reading on Google and saw that some people recommended having legacy versions of the .Net Framework installed, but all those articles are Windows 7 related. I did go ahead and add .Net legacy support through the Add/Remove Windows features app. Doesn't seem to resolve my issue.

Does anyone know what I can do to resolve this issue?

:)

 

AppLocker Blocks Windows Store Apps Downloads

For those of you who are suffering from the AppLocker issue...

First, to set context. AppLocker is a built in security mechanism that allows you to control (Block or Allow) "stuff" from running on your computer. In the context of Modern Apps and the Store, it does not prohibit the use of the store, rather the download,
installation, and launch of Modern\Universal Applications.

At our company we have a good number of Windows 8.1 machines in the environment. We use AppLocker to restrict the use of all unknown "Modern Apps" by creating a global Deny rule. In order for all of the "built-in" Windows apps to load correctly (at fist
login and on update), we had to configure the global deny rule with a wildcard(*) exceptions (you do this that have a values of "*" in the scope of the ). This is similar to a typical firewall configuration where you block everything then make your exceptions
of stuff you want to allow. Once you have allowed exceptions, you need to have "allow" rules to pass through the global "deny" rule. That means that you have to create specific allow rules for the apps you want users to be able to download, install, and
launch.

We also have an allow rule for a specific user group that has '*' as the scope. This rule is necessary if you want to give certain users, such as your Desktop Admins, the ability to download, install, and run all modern apps. This was also an important piece
for Developers trying to debug a modern app that they are developing. Without this rule developer will not be able to run their modern apps in Visual Studio. This all worked beautifully with Windows 8.1...along comes Windows 10...

When we first starting building Windows 10 computers, at the time it was 1511, we added new rules to allow all of the new built-in apps. Life was good...or so it seemed. What we found was that any time a modern (or universal app) was trying to update,
that the updates were being blocked with an 0x80073CF9 error in the store. There was also a corresponding event in the AppLocker logs about the blocked attempt.

When 1607 came out we tested the issue again hoping that we'd find that it was magically resolved. As we starting re-testing this AppLocker issue when we found that users who were in the "Allow All Apps" group were getting denied the right to "install"
software by Applocker (I put "install" in quotes intentionally. After doing some troubleshooting and testing on both 1511 and 1607, I found that on both versions the steps to install a modern app are slightly different than they were in Windows 8.1 and that
AppLocker does not like the changes. In W10 and W8.1 when the apps from the store are first downloaded before they are installed. In Windows 8.1, the app is download under the logged in users context. In Windows 10, the download occurs under local SYSTEM
and is then passed over to the user context to perform the install. I figured this my looking closely at the user whom the AppLocker log was written for.

Since "SYSTEM" is not a member of the group that is allowed to use the app (download, install, and run), the action is not allowed to pass through the deny rule exception and AppLocker stops the download process resulting in the 0x80073CF9 error. Just to
prove my theory I added a test rule to allow "NT AUTHORITY\SYSTEM" and everything stared working as they did in Windows 8.1. I was able to update installed apps and new apps from the store.

Additionally, we happen to have a Microsoft consultant onsite so I had him run the same exact tests in his lab. He had the same exact issue. This was not a problem caused by a configuration or policy in our environment.

The bottom line is that Microsoft changed the behavior of how apps are downloaded and installed from the Windows Store. This change broke the way AppLocker works. I REALLY hop that Microsoft fixes this. What I have mentioned in this post is not an acceptable
workaround...I did this as a test.

For security reasons, I HIGHLY DISCOURAGE anyone from giving "NT AUTHORITY\SYSTEM" permissions to install ANYTHING from the store.

 

gpedit crashes with error "found an error in a snap-in" SrpUxSnapin.dll issues

We are running Windows 10 Enterprise v.1607. We need to be able to work with applocker.

Scenario: gpedit.msc >Local Computer Policy>Windows Settings>Security Settings>Application Control Policies>App Locker>Packaged app Rules>Create New Rule>Permissions
[I select Deny and a User on my machine]>Condition [Publisher]

I then select "Use an installed packaged app as a reference" and press the "Select..." button. That's where the problem occurs:

1) The entire "Create Packaged app Rules" window disappears and

2) a "SrpUxSnapIn.dll" dialog box appears that indicates, "MMC has detected an error in a snap-in and will unload it."

3) I'm given two choices, "Report this error to Microsoft, and then shut down MMC." or "Unload snap-in and continue running".

4) Either choice, when selected, leads to an error message that MMC has stopped working, and gpedit closes.

I see a final dialog, "Unhandled Exception in Managed Code Snap-in", which reads:

FX:{8A1A4AD2-7F9F-492c-9E1D-F725E3CBF2F0}

Exception has been thrown by the target of an invocation

Exception Type: System.Reflection.TargetInvocationException



at Microsoft.ManagementConsole.Internal.SnapInMessagePumpProxy.OnThreadException(Object sender, ThreadExceptionEventArgs e)

at System.Windows.Forms.Application.ThreadContext.OnThreadException(Exception t)

at System.Windows.Forms.Control.WndProcException(Exception e)

at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)

at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason,
Int32 pvLoopData)

at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)

at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)

at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)

at Microsoft.Security.Srp.Ux.SrpUxRuleListView.CreateManualRule(RuleType ruleType)

at Microsoft.ManagementConsole.View.DoAction(Int32 actionId, Boolean selectionDependent, Int32 selectionId, IRequestStatus requestStatus)

at Microsoft.ManagementConsole.View.ProcessRequest(Request request)

at Microsoft.ManagementConsole.ViewMessageClient.ProcessRequest(Request request)

at Microsoft.ManagementConsole.Internal.IMessageClient.ProcessRequest(Request request)

at Microsoft.ManagementConsole.Executive.RequestStatus.BeginRequest(IMessageClient messageClient, RequestInfo requestInfo)

at Microsoft.ManagementConsole.Executive.SnapInRequestOperation.ProcessRequest()

at Microsoft.ManagementConsole.Executive.Operation.OnThreadTransfer(SimpleOperationCallback callback)

C:\Windows\System32

We have done the following without any luck in fixing the issue:

SFC /scannow ->finds nothing

Clean boot -> issue persists

regsvr32 SrpUxSnapIn.dll -> cannot find module



DISM /Online /Cleanup-Image /ScanHealth -> issue persists

We believe we have a GPMC bug as it's consistently reproducible. We need to load a new SrpUxSnapin.dll and link it to the correct directories. Question is how we do this? I cannot
find the .dll nor any instruction from MS how to reinstall it.

Please help

.

 

@ahelton, this forum is for BSOD problems obly, as stated in the forum header and the top of all threads:



Please do not post anything other than Windows 10 Blue Screen Of Death problems in this section.

I suggest posting this in the General Support | Windows 10 Forums

 

Ah. Sorry. My mistake. Is there a way to move it to general support?

 

I'll see if I can get someone to move it.

Thanks @Brink

 

Sadly, the only solution is to change to Windows 10 Enterprise edition.

I wanted to lock down the computer I got for my mother (so my nephew would not wreck it too much). I found many references to Applocker, which I tried. I got the same error message (snap in error, SrpUxSnapIn.dll, {8A1A4AD2-7F9F-492c-9E1D-F725E3CBF2F0}), except it would occur when I would change the user/group to which the rule would apply for.

I went to Microsoft store, and they (in their own words) would only know "easy" stuff, not policies. I rang Microsoft, and their "technical" support replied that AppLocker was a "third-party program". Then I gave up.

I decided then to investigate if updates could have ruined AppLocker.

Investigation process:
1 on a brand new machine, install Windows 10 v1607. do not update, not even bother activating, no internet connection whatsoever.
2 run secpol, applocker, new rule, next:



3 now select the applicable group:



great, this is the objective. that looks promising!


4 now, brand new machine again, install Windows 10 v1703.
5 follow the same procedure as before.

you get the same mmc error snap-in error.


After further research on the net, I stumbled (I did not find) on this:
https://www.microsoft.com/en-au/wind...siness/compare

which clearly mentions AppLocker as being a feature for Enterprise edition, not Pro.

For those lost souls still trying to get AppLocker to work on Windows 10 Pro after v1607, forget it. It no longer works. I do not know if it ever did, since I never tried before, but now, on v1703, it certainly does not, and it seems to be a feature removed from the Pro edition, for good.

And thus, after seeing George Orwell's cautionary tale from the inside, NSA ties to companies, and how blatantly Micro$oft is grabbing and using our information, I got myself thinking again that I should speed up my transition to Linux. When Windows 7 dies, I am not moving to 10, I will go Linux.