Discussion in 'other firewalls' started by ultim, Oct 12, 2011.
Thank you for the quick fix. It appears to be OK now.
I have just noticed another problem. I have "Windows Defender" ticked on the Special Exceptions page but I am finding MsMpEng.exe is logged as blocked. This is currently in:
and has not recently updated. If I run:
it says it cannot communicate. httpcode=451.
Then you seem to be having a different problem. Windows Defender updates, both engine and signatures, are distributed over Windows Update. And I can verify and confirm that I am getting constant Defender updates on all machines where TinyWall is installed, even though the Windows Defender special exception is disabled (because the Windows Update exception is enabled). The special exception for Defender is only to enable cloud-based scanning and automatic file submission to Microsoft.
Also, I now tried MpCmdRun.exe -ValidateMapsConnection on my computer, and this truly fails, but it fails even if I disable TinyWall.
In other words, these things don't suggest to me that something would be wrong with TinyWall.
I am concerned that I get MsMpEng.exe blocked on port 443 in the TinyWall log. I believe this is the Windows Defender scanner engine.
Please send me both of the following two things in PM so that I can check:
1) Hover over the filename of MsMpEng.exe in the log, TinyWall will show the full path. What is the full path?
2) Open an administrative command prompt and issue "netsh wfp show filters". This will create an XML file, please send that to me.
I notice in the exported firewall rules the windows defender entries are unique in having a double backslash:
Could this be causing a problem?
The whole filters.xml file is very big and a don't know how to attach it to a message in this forum.
The path in the rule is correct otherwise and so is the path in the blocked log entry.
Could be, needs to be tested. If you remove the trailing backslash of the InstallLocation value in the HKLM\SOFTWARE\Microsoft\Windows Defender regkey and after that select TinyWall's Normal mode (even if it was already in Normal mode), does it work then?
After the experiment you should re-add the backslash 'coz I don't know if removing it causes problems elsewhere.
It won't let me edit the InstallLocation even as administrator. I don't want to be messing with permissions in case I mess it up. It does have a back slash on the end, but the BackupLocation does not. This might have changed.
@ultim I think I got the same problem like tcarrbrion. zip with pathname and .xml send to your pados.hu email.
Seemed to happen after an Defenderengine update since I haven't had blocks listed before.
Pathes of the old ones and the new ones. The newer ones were listed as blocked in the connection log.
WdNisSvc (C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.2109.6-0\NisSrv.exe)
WdNisSvc (C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.2110.6-0\NisSrv.exe)
WinDefend (C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.2109.6-0\MsMpEng.exe)
WinDefend (C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.2110.6-0\MsMpEng.exe)
I'll send you a test build in the next couple of days to try, to see if it solves the problem.
Please let me know if this test build solves your problem.
Thank you, that does appear to have solved the problem of logged entries. Also, it allows MpCmdRun.exe -ValidateMapsConnection to work.
@ultim Send you two e-mails since I find no opion to attach a zip here.
It seems the reason was the double-backslash in the path. Microsoft seems to have added a trailing backslash in newer Defender versions to the registry entry which caused this problem recently. TinyWall in the test build handles this more robustly by correctly forming the path both with and without the trailing directory separator. For now this is only implemented for Defender, in the public release this will be generalized for all built-in rules to make it future-proof for other programs too in case they make similar changes.
I also found out why MpCmdRun.exe -ValidateMapsConnection failed for me even with TinyWall disabled. It seems you cannot run this test if the corresponding features in Defender's settings are disabled. As soon as I enabled the features, the test succeeded for me. So now I can confirm that at least on my system and with the latest test build, there are no problems regarding Defender.
A public release with the fix will come somewhat later. We are still checking something with Freki123, but I'm also waiting for some other things.
My bad, forgot about this feature. But I assume it will then override TinyWall's own protection of the hosts file?
Well, it can be misleading to say "override". The hosts file is still protected against modifications by other programs, but TinyWall will not prevent its own self to install the blocklists, yes.
@ultim I did the reload rules with tinywall a few times.
For MsMpEng.exe it seems fixed for me. No blocks in the log.
For NisSrv.exe it is still listed as blocked in the log. But when I understood your wilders post right that was to be expected.
OK I see. I simply wondered if TW would perhaps block itself from modifying the hosts file, which wouldn't be logical, I agree.
To anyone following this forum thread that has the issue with Tinywall starting in Unknown Mode I think you should read this new thread: TinyWall Starts in Unknown Mode
You might manage to get a fix from there.
Upon upgrading to TinyWall 3.2.3, I received the following 3 warnings:
I think the update went OK, but I thought I would post the warnings just in case...
Any thoughts? Thanks in advance...
It's alright, these messages are harmless and you can ignore them.
Thanks for the confirmation, @ultim...Much appreciated
Separate names with a comma.