This project has moved. For the latest updates, please go here.
1

Closed

[Bug] Alle Connections Blocked no Notification

description

Hi,

I tried to use Version WFN 1.9.2.9 but it blocks all connections and does not notify me if a programm tries to get access to the internet.
Using the same settings for WFN 1.8.0 works totally fine (thanks for that really nice programm).

My ErrorLog (Windows 7):
2014.12.23 00:20:01 - SYSTEM - [INIT] - OS: Microsoft Windows NT 6.1.7601 Service Pack 1 (64bit) / .Net CLR: 4.0.30319.18444 / Path: C:\Program Files\Windows Firewall Notifier\Notifier.exe / Version: 1.9.2.9
2014.12.23 00:20:01 - SYSTEM - [DEBUG] - GetService found the following services: Nicht zutreffend
2014.12.23 00:20:01 - SYSTEM - [ERROR] - Unable to retrieve the service name, falling back to previous method.
Closed May 20 at 9:09 AM by DanielPharos
Assumed fixed; no response from user.

comments

jkardias wrote Jan 22, 2015 at 4:43 PM

I have the same issue on Windows 7 64bit
Program loads and blocks all connections but no notifications ever appear, and it eventually crashes

2015/01/22 12:33:37 - SYSTEM - [INIT] - OS: Microsoft Windows NT 6.1.7601 Service Pack 1 (64bit) / .Net CLR: 4.0.30319.34209 / Path: C:\Program Files (x86)\Windows Firewall Notifier\Notifier.exe / Version: 1.9.2.9
2015/01/22 12:33:37 - SYSTEM - [ERROR] - Unable to initialize WFN
This single-instance application could not connect to the original instance.
at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run(String[] commandLine)
at WindowsFirewallNotifier.Program.Main(String[] argv)

Qelix wrote Jun 20, 2015 at 7:51 PM

And still the same problem. Yet again Windows 7 64-bit. Though nothing that crashes. Only hangups off tasks.
I set up WFN1.9.2.9. Then I took a look your schedultask "WindowsFirewallNotifierTask" and copied your triggerevent into a new task I created. Its action was to let powershell make a beep-sound "powershell -c echo `a". It did when tried to access my mails. A beep each time.
However my event ran under the permissionlevel/in the enviorment of my useraccount "MY-PC\MYLOGIN". When I changed it to run under the permissionlevel of SYSTEM ("NT AUTHORITY\SYSTEM". I'm using the german Version, so it's "NT-AUTHORITÄT\SYSTEM" here), like it's the case in "WindowsFirewallNotifierTask", it failed. Both tasks failed in the same way, when I triggered them manually. (I changed your task to let me do so.) The status "Bereit" ("Ready") changed into "Wird ausgeführt..." ("Running...") ... aaand that was that. Nothing happend beyond this point.

Some guy claims here, (Translated via google|Yeah, it's horrible butchered), that SYSTEM hasn't got the environmental mapping to some sort of interfact to the display, as normal usersaccount do have, and therefore is unable to create anything visual, like a window for example. Hence the taskaction couldn't create a black powershell window and no "Notifier.exe" window either, instead it hung well... "hung in there" like a kitty in a motivational poster and that's that.

Though WFN_1.8.0 on the other hand works like a charm. LOVIN'IT.

Qelix wrote Jul 14, 2015 at 8:08 PM

That guy in that before mentioned german threat said, that programs, that are started by SYSTEM and are trying to open a window, are getting into trouble, because they need a referrence (something that links them) to the current users desktop (Yes, "desktop" is the actual term for the "environmental mapping to some sort of interfact to the display"). As from the programs point of view the SYSTEM-account is the current user, tries to do something on its desktop and (as SYSTEM doesn't have a desktop) game over.

I gave WFN1.9.2.9 another shot. WORKAROUND: When I opened the WFN console (console.exe) and looked into the settings and noticed how under "Enable the notifications" the option "For everyone on this computer" has been selected. I changed it to "For me" and now it works (so far).

Why didn't WFN work with the "For everyone on this computer" option? A bug? A mistake on my side?

NotDifficult wrote Nov 22, 2015 at 11:46 AM

It is a translation bug. Wfn considers "Nicht zutreffend" the name of a service. I will submit a fix ASAP.

wrote Feb 23, 2016 at 9:32 AM

wrote Mar 19, 2016 at 8:45 PM

DanielPharos wrote Dec 24, 2016 at 12:35 PM

Recent versions of WFN contain fixes for this. Is this still happening?

wrote May 20 at 9:09 AM