Thanks. I've decided to go with your recommended Sandboxie while waiting for somebody else to discover a solution to my problem. It seems to offer the same safety and protection as would Tinywall, but I'd love to have both if possible. There just isn't a more effective, yet simple firewall that I can trust and depend upon.
Got a bug to report in version 2.1.5 on Win 7 x64. Go to Manage, Application Exceptions Tab, click button to add Add Application, click button to Select a process, click cancel without selecting a process. This causes an unhandled exception. Code: See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box. ************** Exception Text ************** System.NullReferenceException: Object reference not set to an instance of an object. at PKSoft.ApplicationExceptionForm.btnProcess_Click(Object sender, EventArgs e) at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent) at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ButtonBase.WndProc(Message& m) at System.Windows.Forms.Button.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) ************** Loaded Assemblies ************** mscorlib Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.18444 built by: FX451RTMGDR CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/mscorlib.dll ---------------------------------------- TinyWall Assembly Version: 2.1.5.0 Win32 Version: 2.1.5 CodeBase: file:///C:/Program%20Files%20(x86)/TinyWall/TinyWall.exe ---------------------------------------- System Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.34238 built by: FX452RTMGDR CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll ---------------------------------------- System.Core Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.18408 built by: FX451RTMGREL CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll ---------------------------------------- System.Windows.Forms Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.18408 built by: FX451RTMGREL CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll ---------------------------------------- System.Drawing Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.18408 built by: FX451RTMGREL CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll ---------------------------------------- System.ServiceProcess Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.18408 built by: FX451RTMGREL CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.ServiceProcess/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.ServiceProcess.dll ---------------------------------------- System.Xml Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.34234 built by: FX452RTMGDR CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll ---------------------------------------- System.Configuration Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.18408 built by: FX451RTMGREL CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll ---------------------------------------- TinyWall.XmlSerializers Assembly Version: 2.1.5.0 Win32 Version: 2.1.5.0 CodeBase: file:///C:/Windows/assembly/GAC_MSIL/TinyWall.XmlSerializers/2.1.5.0__d9a8adbcd0c171b3/TinyWall.XmlSerializers.dll ---------------------------------------- System.Management Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.18408 built by: FX451RTMGREL CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Management/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Management.dll ---------------------------------------- Accessibility Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.18408 built by: FX451RTMGREL CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/Accessibility/v4.0_4.0.0.0__b03f5f7f11d50a3a/Accessibility.dll ---------------------------------------- ************** JIT Debugging ************** To enable just-in-time (JIT) debugging, the .config file for this application or computer (machine.config) must have the jitDebugging value set in the system.windows.forms section. The application must also be compiled with debugging enabled. For example: <configuration> <system.windows.forms jitDebugging="true" /> </configuration> When JIT debugging is enabled, any unhandled exception will be sent to the JIT debugger registered on the computer rather than be handled by this dialog box.
I recently got an HP network printer and had trouble getting it to work with Tinywall. Autolearn did not work. Adding exceptions for all of the related HP programs did not work. From the connections window I think I could see that it was blocking connections from system and svchost.exe, which I don't know how to add exceptions for. The only solution I could find was to enable the option "Unblock LAN traffic". This may be ok since the LAN is just in my home. If anyone has other suggestions please let me know. I'm not a firewall expert, so I didn't go into Windows Firewall directly and mess with the settings there. Thanks.
Happens also on my computer. Because I don't have network printer, you are on your own if checking Special Exceptions/Optional/File and Printer Sharing does not work. It is normal I think to see svchost.exe blocked and it not have anything to do with the printer or then it can. You need to have windows network discovery checked I think in special exceptions for the printer to work. I for example don't have it checked as I don't have a home LAN. And if I added a network printer I would be most likely in troubles if not knowing to check it. You should not be able to make changes that stay to Windows firewall directly, because TinyWall is controlling it.
The updated TinyWall system rules: http://www.saunalahti.fi/~jarmos3/TinyWall_rules_215.jpg I did not notice any changes to previous version except the added Windows update rule. You will notice I have put it in red color and the advises how to deal with it are in post #900. I would also imagine this new rule making TinyWall a bit more easier, it as a side effect might enable some services that would be blocked otherwise for more special cases, with the cost of weakened general protection. As I was moving that with the ftp program, I thought, why not move the Sygate Guide there too extinct as XP is, since TW does not work in that OS: http://www.saunalahti.fi/~jarmos3/SPF_eng/SPFGuide.html
Above post shows rules for TinyWall modes, 2 of the optional exceptions, tray icon option for unblocking LAN traffic and also some Avast AV rules. These are good to know in case something is not working, so the user knows what else needs be added if any. And also the firewall then being not a blackbox anymore. http://www.saunalahti.fi/~jarmos3/TinyWall_rules_215_2.jpg As an example: I have these Avast rules in my Application Exceptions: C:\Program Files\AVAST Software\Avast\AvastEmUpdate.exe, C:\Program Files\AVAST Software\Avast\AvastSvc.exe, C:\Program Files\AVAST Software\Avast\AvastUI.exe, C:\Program Files\AVAST Software\Avast\Setup\instup.exe, C:\Program Files\AVAST Software\Avast\ng\ngtool.exe allowed outgoing TCP and UDP traffic. The last executable is a new one and came when I installed today the 2015 version that the program was feeding me. Even if I am not absolutely sure all these need the internet for the AV to work, at some point I have whitelisted them. And I think the special exception provided is not enough anymore. More of the optional exception rules could have been added, but I leave that to interested readers to search, it being a kind of tiresome job to do and I am too lazy, at least for today. Way to check is: You export your rules for backup, delete all application rules, disconnect from internet if you are not behind a router firewall and anyways good to do. Leave TW to normal mode, not blocked mode. Now to find out rules for say Windows Remote Assistance is to check it and uncheck everything else. And then you go to Windows firewall advanced settings and look at those outgoing and incoming connection rules. You will notice that they are rules for svchost.exe and some services using it.
Very helpful, thank you very much for this! Little suggestion for ultim: adding an integrated hosts file editor to TinyWall would be nice.
Tinywall stopped my gf's net connectivity even though she didn't change any settings.. Had to un-install it
Hm, that's weird. Maybe the rules were lost for some reason? I had once all rules wiped out of Outpost firewall when my PC lost power suddenly.
Some additional help regarding that what I already posted. Start TinyWall Connections window before you start a program that needs to be whitelisted. To be able to unblock it from that window. There is I think a 2 minute time window frame so refresh the connections view after starting the program. If you want to try allow svchost.exe out without knowing what service might need using it, you can at least restrict it to local network. If you have a router, checking upnp option if it is disabled like in mine might help too.
I have a small number of reports from people who also report multiple controller instances being started, but I never got enough information to figure out how. I never reproduced the problem on my own computers, but since some multiple people reported this, I know this issue must be real. If anybody is seeing this with this prolem, I'd need an exact and complete listing of all TinyWall-relater autostart entries from the registry. For a list of all possibilities for autostart, see http://www.sevenforums.com/tutorials/1401-startup-programs-change.html . For TinyWall, only "Method Four" (registry method) is interesting, as the other ones are not used by TinyWall.
TinyWall's filtering is active as soon as Windows Firewall starts up during boot, which is very early, immediately after Windows initializes the network stack. So it provides secure boot. At a later stage during system boot, TinyWall's service will start, which provides additional tampering protection, and the ability to change the configuration over the GUI.
A symptom like this can indicate two things. 1) The cause of this symptom can be a badly behaving network app, constantly triggering TinyWall's tampering protection. In this case you need to find the offending app, and change its settings or remove it, and ideally file a bug report to its developers. 2) The service might have also gotten into a bootloop (the chances of which are greatly reduced with version 2.1.5), most probably due to a faulty rule entry. In this case you'd need to uninstall to clear the configuration and reinstall then reconfigure to get rid of the faulty configuration entries. While this did happen a rare few times in earlier versions due to bugs in the GUI, I have not received such reports for 2.1.5 yet. The service in 2.1.5 got explicitly hardened against such cases, in addition to known related GUI-bugs corrected too.
This rule got added because of Windows Update in Windows 8.1. I really hated to add this rule too, but I have not yet found any other acceptable alternative. I researched and experimented hard to find a stricter rule for Windows Update in 8.1, but literary nothing else worked. So with my current knowledge, the only way to make this somewhat better would be to use the old rule for all other Windows versions (non-8.1), but that would either require me breaking existing configurations, or starting to hardcode special cases for specific rules in code, both unacceptable for me. I am greatly annoyed by Windows 8.1 Update's behavior too, and rest assured, as soon as I know a way to better restrict traffic to it, I will release a new TinyWall update immediately to address this issue. So if any of you knows a solution, please don't hesitate to come forward. Sadly I have not yet found a way.
The only important thing is to open the connections window before the app in question tries to use the network. It does not have not be 2 minutes earlier. There is a 2 minutes time frame, but that is for a different thing, it is how long before TinyWall deactivates blocked apps listing, after the Connections window is closed.
I have windows 7, so I can't give any knowledge about that. Really good have you back after a few months! We are so used to not hearing from you Karoly At least with win7 and earlier we can disable the update rule and make our own: For svchost.exe, wauserv, allow only specified ports. I have out TCP * and since I have disabled dnscache service, also out UDP 53. But that latter sure is only for me.
Thanks for trying to help. I did already have Windows Network Discovery and File and Printer Sharing enabled in the "Special Exceptions" area, but that was not sufficient. I also had already added Applicaiton Exceptions for all the relevant HP executables. When I would start "HP Scan", it would tell me that the scanner was not available. The attached image shows the connections that were bring blocked. The solution was to add an exception for svchost.exe, allow outgoing TCP traffic, and restrict to local network. The blocked connections to "system" were apparently non-essential. Of course "Unblock LAN traffic" would also work, but adding the specific exception for svchost opens a smaller hole in the firewall. I do wish there was a way to restrict an exception to a specific IP address. If that was possible, then I would only allow svchost to access the IP address of my printer. Lastly, I also needed to add an exception for C:\Windows\System32\spoolsv.exe to get printing to work. Autolearn was able to catch this one. I'm satisfied with this setup. Note in the attached figure that 101 is my PC, and 109 is the printer.
Thanks for sharing your resolution. I will make sure to include spoolsv.exe in the future in the rule for File and Printer Sharing, restricted to the LAN.
Great, thanks! Just curious, is it intentional that Autolearn would not add an exception for svchost.exe?
