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

Failed to write to log file.

description

When I get a bunch of alerts at once, I get the following error:

Failed to write to log file.
Please make sure the log file is not in use by another program.

I'm guessing prompts need to be taught to wait for the lock file release?

comments

DanielPharos wrote Oct 30, 2016 at 7:16 PM

That's the fun part: it's already done that. It's already retried 5 times, waiting 200ms in between. At some point I will drill down into the bowels of Windows to find the culprit, and take it out behind the shed, but right now this is "as good as it gets". Luckily, the impact is minor: a small user annoyance, and a missing line in the log, but no spectacular crash-fests anymore. :P

CitricBase wrote Nov 27, 2016 at 10:50 PM

Since a few days after installing WFN, I was getting this error at random times throughout the day, maybe twice an hour. (This is as opposed to OP, who was only getting it along with alerts.) Because the error message steals focus even from full-screen programs, it pretty much rendered my video games unplayable. (Losing a rank every other match in Rocket League or Overwatch because this WFN error kept popping up was unsustainable.) Here's what I've figured out.

Something was delaying WF for at least a second, according to what DanielPharos said above. I think what exacerbated the issue were a lot of simultaneous connection attempts (not just alerts), all of which WF needed to verify. I've got a fast computer, how long can one verification take? A while, it turns out, in my case.

See, when WFN catches a connection attempt and displays an "Allow" or "Block" prompt, the "Allow" option defaults to make a rule to allow that program to connect to one certain location through one particular local port. So the user clicks "Allow" to let their trusted program through, creating that rule.

Then the program wants to to connect to a different host, or through a different port. The user clicks "Allow" again. After about a week of this, the user might get annoyed enough with clicking "Allow" over and over to look a little deeper into the WFN options and discover the two switches that need to be toggled off before clicking "allow" in order to tell WFN that yes, you really, truly do trust this particular program. However, it's too late, and the damage has been done: the firewall is now parsing thousands of custom rules for every connection attempt. This is what causes that rank-destroying notification to appear.

Some of Windows' own system processes are the worst offenders, connecting all over the place through tons of different local ports, all at once, every twenty minutes or so. WFN's rule list isn't very practical for getting rid of those extraneous rules, because you can only delete one rule at a time, and it reloads the entire list after every operation.

Fix for users like me:
  • Click the "Adv. Console" button above WFN rule list, this will bring up the native Windows Firewall rule manager.
  • Click "Outbound Rules" in the sidebar on the left.
  • All WFN-created rules are suffixed by "Custom Rule -" in the name. Delete every "Custom Rule" entry that doesn't say "Any" in the "Local Port" and "Remote Port" columns.
  • In the future, every time WFN prompts you to allow a program to connect, click the little arrow next to "Advanced" and disable all of the six switches before clicking "Allow" and creating the rule. This will create a general rule to always trust that program, no matter where it's connecting to.
Now, Windows Firewall will only need to parse a hundred or so rules with each connection instead of thousands. I haven't had the error pop up since I did this and rebooted.

What I think the WFN devs can do to mitigate this issue:
  • Use a regular WFN prompt instead of an evil focus-stealing error notification. Closing out my game and causing my entire team to lose is not a "minor annoyance."
  • Set the default "Allow/Block" prompt to not have any further restrictions. As a user, I either trust the program or I don't; port restriction per program rules aren't really helpful in most cases, and certainly shouldn't be default. (Better yet, allow the user to choose their own defaults.)
  • Give the system a little bit longer than just one second to get its act together before giving up, although perhaps give the user a little toast letting them know that something is slowing down the firewall.
  • In the notification, let the user know that having too many rules is one possible reason their firewall could be slowing down.
  • In the WFN rule list, allow the selection and deletion of multiple rules at once.
As always, thanks for your work, and thanks for keeping this program up to date. Have a nice day!

wrote Nov 27, 2016 at 11:33 PM

clyfton wrote Nov 28, 2016 at 4:42 AM

CitricBase, I think you are onto something.
I tried creating rules like you suggested.
I turned off all 6 options under ADVANCED. But now I get THE CORRESPONDING RULE HAS NOT BEEN CREATED for every rule.

CitricBase wrote Nov 29, 2016 at 12:55 AM

I turned off all 6 options under ADVANCED. But now I get THE CORRESPONDING RULE HAS NOT BEEN CREATED for every rule.
It sounds like it isn't getting the administrator privilege to create the rule, maybe? Windows should give you a User Account Control popup when you click "Allow" to create the rule. If you're not getting the popup, perhaps it has to do with your account privileges?

wrote Mar 15 at 3:53 PM

rotorb wrote Mar 15 at 3:56 PM

I have the same issue "failed to write to log file" in 2.0.6280.24566.

Also more than 100 Wokhan.WindowsFirewallNotifier.Notifier processes running.

wrote Mar 20 at 11:14 PM

DanielPharos wrote May 20 at 8:59 AM

I've just release a new version of WFN, which includes additional fixes for the log file error. See: https://wfn.codeplex.com/releases/view/631360