Windows Firewall fails to launch, error 5 - like KB943996, but fix not working

Question

Environment

Windows 7 Professional SP1 PL, domain-joined.

Problem

Since 2014-06-12, several of our computers (but definitely not all, not yet at least) embraced a problem with printer sharing, which was quickly explained as Windows Firewall service being offline.

Attempts to start Windows Firewall service ends with failure and error no. 5 ("Access denied") returned by the service.

Windows EventLog shows that the issue began at the above date and is recurring every morning at startup - or at any manual service launch attempt.

Diagnostics

By courtesy of Google, we quickly identified the problem has something to do with accessing subkeys of following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\SharedAccess

There are several websites that suggest the problem is caused by insufficient access to some significant subkeys of this key for NT Service\MpsSvc. Most authoritative source seems to be the Microsoft Knowledge Base article KB943996. While this article is about Windows Vista, it provides link to a more general website with Firewall FixIt Tool.

We have tried to apply the suggestions found in the knowledge base and came up with following results:

• We were able to verify that only \Epoch subkey was missing the advised ACL set.
• We were unable to add NT Service\MpsSvc manually, as Windows was not able to find such user. We did check proper search scope (local computer) and did enable all object types. We have estabilished, that this account can be properly found and used on healthy machines.
• The FixIt tool did properly assign the rights to \Epoch subkey for NT Service\MpsSvc (!), but it did not solve the problem, which was admitted even by Fixit tool itself in the post-run test.

We have verified that the above registry key is the key to our issue. We did it by assigning inheritable Full Access rights to Everyone - with these rights, Windows Firewall service did start properly. This however doesn't solve our problem due to obvious security issues. What we need is to fix it correctly.

During our further investigation, we've attempted to monitor the above key using Sysinternals Process Monitor. We have established, that the Windows Firewall service fails after ACCESS DENIED upon \Epoch2 subkey, which we did not know of.

While running regedit.exe with account that has Local Administrator privileges, we were unable to see that subkey. Yet that key was clearly visible:

• on healthy machines, using same privileges,
• on affected machines, running regedit.exe as SYSTEM user (psExec -s -i regedit.exe)

The accounts enlisted in ACL on Epoch2 subkey are also missing NT Service\MpsSvc entry. On affected machine, these are:

• CREATOR OWNER
• SYSTEM
• Administrators
• Users
• LOCAL SERVICE

On healthy/unaffected machine the entries properly run as follows:

• CREATOR OWNER
• SYSTEM
• Administrators
• Users
• MpsSvc

Since we're unable to manually assign these permissions, we're kind of lost at what we can do next.

Range and significance

The issue has been reported in few areas only, but affects circa 50% of computers in the first area we were able to verify in detail.

The issue may likely affect other areas too. Since it requires user to interact with affected Windows features (printing on printer shared by affected computer), user reports will likely be rare when compared to the possible extent of the issue.

While shared printers are not common by now, that feature is not a real issue. But the downed firewall is definitely a problem that needs to be solved.

Result

One: we have no idea on what could have possibly caused such issue.

All computers (both affected and healthy) are run within controlled software installation environment. Users have no administrative privileges, software is automatically deployed via Wpkg. All above computers have identical software profile - which means that same software products have been installed. These computers are even identical in hardware terms, all have been acquired in a single batch and have consecutive serial numbers.

Our primary suspicion, related to common time of issue occurence, is some selective issue with one of the recent 2014-06-10 Windows Updates. We were unfortunately totally unable to reproduce this issue in our time-snapshotted virtual test machines, so that suspicion is kind of thin.

Finding source is important though, both for fixing it and avoiding it in future.

Two: we have no satisfactory idea how to fix the problem. We're thinking about:

• adding rights for MpsSvc user through some commandline ACL tool, though this would take a lot of time and manforce, were the problem begin to spread;
• perhaps to deploy these rights via GPO (GPO would accept any user here), but we would first have to correctly establish that the \Epoch2 rights are the only ones missing.

Before attempting anything drastic domain-wide, we'd be grateful to hear some comments. Most of all, previous experiences, ideas for solution and ideas on the possible source of the issue.

Perhaps someone else had that issue recently?

Answer 1

I have been battling the same problem for a couple days, and I too was unable to see the NT Service\MpsSvc account when checking registry key permissions. Apparently this is by design(?) and the NT Service\MpsSvc account is available, but hidden; you just have to enter it manually in the [Add...] dialog. After doing this, and giving the account Full Control on the Shared Access key, Windows Firewall now starts as it should.

I can only note that Linux with iptables is a marvel of simplicity in comparison.

Answer 2

This just happened to me this week, only obvious changes were the two security patches for Nov 2017 (KB4047206, KB4048960).

I can confirm that deleting and re-adding the specified registry keys as instructed in KB943996 fixed this for me. One additional thing I did was grant my domain user account full permissions to the Epoch, Epoch2 and FirewallPolicy keys and subkeys as well as NT Service\MpsSvc.