Windows Firewall Control (WFC) by BiniSoft.org

Yes, of course it's fine. (paths, too! ).

Let me just mention a minor, and fairly old issue that still remains. Rules Panel: when trying to delete some, or all rules.

This is more evident when trying to delete many rules at once. Sometimes, I filter "User created rules", select them all and delete them. Approximately 4 out of 10 times, they will be "deleted" suspiciously quickly i.e. almost instantly. I say "suspiciously" because this operation usually requires 3-5 seconds to complete (depending on number of rules, and on PC specifications I guess)

When this "instant delete" occurs, they disappear from the Rules Panel UI but are not really deleted. A simple refresh brings them back. Attempting the delete a second time, almost always works and actually deletes them.

I think this also occurs when trying to delete just one or a few rules, but it's easier to "catch" when deleting a large number of rules.

 

I can't reproduce this but I will keep an eye on it.

Meanwhile, I received some reports over email that the export of the rules does not work. I did not receive any reply to my responses, just the initial complaint. Does anyone else have issues with exporting the rules from WFC?

 

Export works normally here.

 

Full and partial exportation works fine here.

 

Windows Firewall Control v.6.9.9.9

Change log:
- Fixed: Certain Windows Store firewall rules may show as invalid in Rules Panel when they are still valid.
- Improved: Notifications exceptions list is now sorted for uppercase entries first and then the others.

Download location: https://binisoft.org/download/wfc6setup.exe
SHA256: 1fb0168f191aed283022a4c6614f8f2ab2e3db087ae315c9083760638e8e530f
SHA512: 22c81ac0e6f1aacb5a2e5dda38e3667481a9da25d0f174130b7f4a51eb53650c2f851f8af21ee9ac3a5927658d3054dad733e4156f1e8ae31a94ce73577976a7

Thank you for your feedback and your support,
Alexandru Dicu

 

Thanks so much for this update! Seems there's a minor issue here, perhaps caused by that capital E, or the other capital letters?

 

Yes, I think it's something like that. I renamed svchost.exe to svchost.Exe, and it stayed correctly at the end of the list.

Renaming it to Svchost.exe however, brings it on the top list.

edit: sVchost.exe seems to cause something unpredictable. Looks like a good solution would be: either all capitals, or it goes in the standard, case-insensitive list.

 

Noted. It will be fixed in the next release.

 

Windows Firewall Control v.6.10.0.0

Change log:
- Improved: The export functionality was revised so that it does not stop if a certain rule can't be exported. It continues with the others.
- Fixed: Exporting of the rules fails if one of the rules has the Description property missing.
- Fixed: Sorting of notifications exceptions list does not always work.

Download location: https://binisoft.org/download/wfc6setup.exe
SHA256: b9bcb7981e7b408f416ef3b9e6bb7adb89ac1eb7b7ea93788f58b53bd515ccd2
SHA512: 4c682f3a05ff4211427fdd04c9e0fdd1273c9f6addbb6e98cafcd1bd0fe661f4cb61b69d04bb657488df584879118050bd6509c6692c015db577e227b90b418d

Thank you for your feedback and your support,
Alexandru Dicu

 

Many thanks for yet another excellent update!

Based on the change log ("The invalid rule will be skipped and the others will be exported"), I initially thought that all invalid rules would not be included any more in the exported file, but thankfully that's not the case. By 'invalid' you probably mean those type of rules that caused issues with the export process? Rules with an empty Description?

It'd be helpful to know exactly which Rules are now excluded from the exported file.

 

When I say invalid I mean broken rules. I asked one user with this problem to export the rules through netsh advfirewall export %USERPROFILE%\Desktop\export.wfw so that I can import and try the export on my side. This rule created problems also when imported with WFwAS:



However, it imported the inbound rule which created the trouble. The rule was named WS-Eventing TCP Port 5357 and the trouble with it is that its Description was null (missing). All rules should have a Description property, even if it is empty or null, but in this case the property itself was missing entirely, not its value. This is the only rule I ever saw with a missing Description property. Since I didn't have this rule in my rules set, I could not reproduce it. It is probably created by some Windows Features which I do no have enabled on my machines. I updated WFC code to handle this error so that a missing property will not break the XML export anymore. Currently, the export should work for any kind of rules. If there is still an error which can't be handled in WFC code, that specific rule will be skipped and an error will be logged. It will not break the entire export anymore.

 

First of all "thank you for the attention paid to the continuous adjustments".
Then I wanted to ask you if with the latest versions anything has changed in terms of importing rules via command line, because until recently, at the end of the installation - always via command line - I proceeded to import "my" rules with the command (line command in batch)

netsh advfirewall import "MyBase.wfw"

but it seems to me that now I can't anymore. Has something perhaps changed?

Thanks for your attention

 

You know that netsh.exe is a tool from Microsoft, right? This is unrelated to WFC.

However, you must get an error, like me below. In the first import attempt I used a broken file exported with that rule with the missing property. Second attempt uses another exported file without that broken rule. First one gives an error, second one works fine.



If you have a broken binary file with the extension wfw, there is nothing much you can do.

 

Forgive me if I wasn't clear enough...
My question was to "investigate" whether with these latest versions, perhaps, some retrosetting in WFC had changed...
Thanks and I will investigate the rules to import.

 

Fixed import of rules (*.wfw): an error on my part.
One last question which ALSO concerns WFC:
- can rules exported from WFC (<name>. wpw) be imported instead of WFC --> import from file, from command line? I don't think so with netsh...
Thank you

 

*.wfw is a binary format from Microsoft. You can use wf.msc or netsh.exe to export/import this format.
*.wpw is an XML file format used by WFC only. You can use WFC to export/import this format.

WFC was able to export/import files in wfw format until version 6.9.8.0 when I decided to remove the support for it. In fact, WFC used also netsh.exe to export/import the wfw files. Because of the import errors that I mentioned already, I decided to remove the support for this file format in WFC because any error related to this file format is out of WFC control.

There is no command line support to export/import the firewall rules from WFC.

 

Ok Tnx

 

@alexandrud

Thank you for the package name changes.

After a short test, I now think it works great! See my next posting ...

 

@alexandrud

Nope, it still has bug(s) with package names. The following are marked as invalid:



But these packages exist:

C:\ProgramData\Microsoft\Windows\AppRepository\Packages\Microsoft.Windows.ParentalControls_1000.19041.4239.0_neutral_neutral_cw5n1h2txyewy
C:\ProgramData\Microsoft\Windows\AppRepository\Packages\Microsoft.Windows.ShellExperienceHost_10.0.19041.4239_neutral_neutral_cw5n1h2txyewy

 

Some system apps are located under C:\Windows\SystemApps. If you open the subfolders from this location you will notice that they include DLL, XML and even EXE files.
The other location where Windows Store apps are installed is C:\Program Files\WindowsApps. The same, if you open subfolders from this location you will notice many binary files in there.

WFC checks these two locations when it decides if a package still exists on disk or not.

The location that you mentioned C:\ProgramData\Microsoft\Windows\AppRepository\Packages is used for other purposes and does not mean that those subfolders are coming from packages that really exist. Most of those subfolders are empty.

Do you have any subfolder for Microsoft.Windows.ParentalControls 1000.19041.4239.0 or Microsoft.Windows.ShellExperienceHost 10.0.19041.4239 under C:\Windows\SystemApps or C:\Program Files\WindowsApps ? If not, then those packages are not there and WFC reports them as invalid, correctly.

 

@alexandrud

Sorry, I shouldn't take the repository folders - I know the 2 correct folders too. However:

The c:\Windows\SystemApps\ParentalControls_cw5n1h2txyewy folder exists (with data (.exe, etc.)) (there is no version included (there are NEVER versions included in the folder name)).
The c:\Windows\SystemApps\c:\Windows\SystemApps\ShellExperienceHost_cw5n1h2txyewy folder exists (with data (.exe, etc.)) (there is no version included (there are NEVER versions included in the folder name)).

In case of c:\Program Files\WindowsApps\ ... THERE ARE package versions included in the subfolder names.

So in fact, I have totally 4 of the described rules (for 2 different users 2 each) and both packages are exist and are valid. These rules should NOT be marked as invalid!

 

That is unfortunate, many apps rely on invalid rules, like TOR, Icedrive or Tracksim.

 

Here WFC rules seem to be ok

 

It was clarified a few posts above that the meaning of that is for broken rules, not invalid in the usual WFC/WF sense. I'll agree that the wording there probably needs to change since it's causing confusion.

 

I see. Honestly I do not even know what broken rules are. Portable apps, like TOR or Icedrive create temporary paths, which are cleared once the app is ended.