Controller is painfully slow to use

[DigitalNaut]

I've had the issue that whenever I try to right-click or even just click the tray icon, the controller will take an unreasonable amount of time to show the context menu. Sometimes even the UI will freeze completely on me unable to control it at all. This has been going on for as long as I can remember having the app and I'm just so tired of it. This also happens on fresh Windows installs.

Is there a fix? many thanks

Windows 10 Home 64 bit v19045.4291

Here's a sample of the app that just froze on me for no reason:

[pylorak]

Cannot reproduce. Best guess is there is some other software on the computer that is interfering with the communication between the GUI and the service processes of TinyWall, Most probably some security software, or maybe something with shell integration. Can you tell me more about what is installed?

[9ao9ai9ar]

I can confirm this has been a long-standing issue. For security software I only use the builtin Windows Security. I do use a number of shell integrations, but they're mostly Microsoft products or well trusted/behaved ones. Is this related to how sometimes the TinyWall Controller icon in the notifications area would vanish (I assume the program just quit)?

[pylorak]

I can confirm this has been a long-standing issue. For security software I only use the builtin Windows Security. I do use a number of shell integrations, but they're mostly Microsoft products or well trusted/behaved ones. Is this related to how sometimes the TinyWall Controller icon in the notifications area would vanish (I assume the program just quit)? Sorry for asking another question, but upon reopening it, what is the difference in functionality if I don't "Elevate"?

I am not aware of the notification icon sometimes vanishing, but I do know of an issue where on some systems the notification icon is not shown on a fresh boot even though the GUI process is running. That is related to the process loading too early before the desktop is shown.

As for the current issue of slow GUI, does that mean that you are also experiencing it?

[9ao9ai9ar]

Yes, I do experience this issue occasionally, and the last time I experienced it, the GUI became totally unresponsive indefinitely and I had to kill the process. It happened when I opened the connections panel while running a badly-optimized, emulated video game. But I think that is an outlier: usually the unresponsiveness lasts only a few seconds.

[pylorak]

Yes, I do experience this issue occasionally, and the last time I experienced it, the GUI became totally unresponsive indefinitely and I had to kill the process. It happened when I opened the connections panel while running a badly-optimized, emulated video game. But I think that is an outlier: usually the unresponsiveness lasts only a few seconds.

I know this is a tall ask, but if you manage to somehow reproduce it relatively reliably, I'd be happy to investigate and if possible find a solution with your help. If there is a way to mitigate in TinyWall, I'd publish a fix.

[9ao9ai9ar]

@pylorak Indeed it is a bit of a tall ask for me as I don't know how to reproduce it. However, I suspect it might be related to resource shortage or contention, specifically the RAM or GC. I don't seem to observe this issue in my beefier (but iGPU only) PC, though I haven't used it enough to be sure. Is there any way for me to dig deeper into this issue as a user, for example by inspecting the Windows Event Viewer or the coredumps?

I am interested in helping maintaining this project, but only if Microsoft doesn't continue to fuck over its Windows users. If they decide to make Windows unusable without a Microsoft account, or ship the Recall feature, even if opt-in (because they'll just turn it on from time to time and feign innocence and treat it as just a "bug" or a UI glitch; they have already done it by "misremembering" the Edge settings), I will ditch Windows and .NET, and by extension all local apps built on either of these, for good.

[pylorak]

I fully understand you. Thankfully I am not affected by Recall because my machines are not Copilot+ certified, so I should be safe for the time being ;)

It is very hard to diagnose an issue that nobody can reproduce reliably. As for me, I've never yet seen this happen on any on my devices. So this will take time to track down.

As for the actual cause of the slowdown, I think I can categorize the problem into one of 3 possible categories:

1. The GUI process is asking the service process for data, and the service takes too long to respond.
2. Or, there is a temporary problem with the communication between the service and the GUI. This could be caused by another security software on the machine.
3. Or, the GUI process itself is slowed down or is experiencing some kind of timeout while loading file metadata for rules. This could be caused by a faulty shell extension on the machine, or an unexpected network connection that times out.

To rule out number 1) from above, please create an empty file "enable-timings" under C:\ProgramData\TinyWall and restart the machine. This will record time measurements for various actions running in the service process. Then, if you experience the problem again, please send me the log files created in the same folder.

[pylorak]

However, I suspect it might be related to resource shortage or contention, specifically the RAM or GC.

TinyWall really doesn't require much RAM or CPU power to run. What is your PC specs? And what memory consumption does Task Manager report for the two TinyWall processes? Note there will be two of them, one running under the local user (the GUI process), and one running as a SYSTEM (the service process).

[9ao9ai9ar]

TinyWall really doesn't require much RAM or CPU power to run. What is your PC specs? And what memory consumption does Task Manager report for the two TinyWall processes? Note there will be two of them, one running under the local user (the GUI process), and one running as a SYSTEM (the service process).

One has 8 GB RAM, the other 16 GB, both with 6+ Intel i5 CPU cores. I often have two of a web browser, a video game, or an IDE open at the same time, and if I am not careful, the applications will bug out due to not enough RAM.

[DigitalNaut]

My machine is similar with 8GB of RAM and an i5 CPU. I also usually have a web browser, an IDE/Git Kraken, and Spotify/Explorer open. Sometimes it'll take up to a minute to open the right-click menu and display the options.

[pylorak]

My machine is similar with 8GB of RAM and an i5 CPU. I also usually have a web browser, an IDE/Git Kraken, and Spotify/Explorer open. Sometimes it'll take up to a minute to open the right-click menu and display the options.

One thing is for sure: we can rule out the machine performance being a problem. Could you try measuring the service process timings as described at the end of the post above?

[9ao9ai9ar]

I am not aware of the notification icon sometimes vanishing, but I do know of an issue where on some systems the notification icon is not shown on a fresh boot even though the GUI process is running. That is related to the process loading too early before the desktop is shown.

TinyWall really doesn't require much RAM or CPU power to run. What is your PC specs? And what memory consumption does Task Manager report for the two TinyWall processes? Note there will be two of them, one running under the local user (the GUI process), and one running as a SYSTEM (the service process).

The TinyWall icon in the notification area is missing upon restart after today's Windows update. I don't remember if it has ever gone missing after being present on login, so let's assume this is the known issue you talked about. The memory usage of TinyWall is very modest as can be seen in the above screenshot.

To rule out number 1) from above, please create an empty file "enable-timings" under C:\ProgramData\TinyWall and restart the machine. This will record time measurements for various actions running in the service process. Then, if you experience the problem again, please send me the log files created in the same folder.

I can't yet experience a very serious windows freeze, and the log seems to be very long, so I'll paste what I have now and what I think is the relevant parts:

...
        Message DISPLAY_POWER_EVENT:
            InstallFirewallRules():
                AssembleActiveRules(): 54 ms
                WFP transaction acquire: 1 ms
                WFP preparation:
                    DeleteWfpObjects(): 107 ms
                    Total: 108 ms
                Installing rules: 40 ms
                WFP transaction commit: 377 ms
                Total: 580 ms
            Total: 580 ms
...
    TinyWallService.Dispose(): 298 ms
    NIC enumeration: 151 ms
    Service Run():
        Message wait: 1 ms
        Message REINIT:
            InitFirewall():
                LoadDatabase(): 475 ms
                ReapplySettings(): 14 ms
                InstallFirewallRules():
                    AssembleActiveRules(): 121 ms
                    WFP transaction acquire: 1 ms
                    WFP preparation:
                        DeleteWfpObjects(): 33 ms
                        Total: 42 ms
                    Installing rules: 49 ms
                    WFP transaction commit: 681 ms
                    Total: 917 ms
                Total: 1493 ms
            Total: 1500 ms
...
    TinyWallService.Dispose(): 297 ms
    NIC enumeration: 85 ms
    Service Run():
        Message wait: 3 ms
        Message REINIT:
            InitFirewall():
                LoadDatabase(): 582 ms
                ReapplySettings(): 24 ms
                InstallFirewallRules():
                    AssembleActiveRules(): 275 ms
                    WFP transaction acquire: 1 ms
                    WFP preparation:
                        DeleteWfpObjects(): 110 ms
                        Total: 119 ms
                    Installing rules: 68 ms
                    WFP transaction commit: 138 ms
                    Total: 614 ms
                Total: 1349 ms
            Total: 1357 ms
...

[pylorak]

When this happens, is the GUI slow every time you try to open the Manage window, or only the first time (until restart of the process/computer)?

[9ao9ai9ar]

When this happens, is the GUI slow every time you try to open the Manage window, or only the first time (until restart of the process/computer)?

Can't say for sure, but I think it only happens once in a period of time, so not on consecutive opens. And there was once when I think the manage window showed up a bit late (like 1~1.5 seconds), but nothing in the log indicated any group of actions taking longer than 500 ms.

I've only gotten the project to compile on VS2022 and not read the source code, so apologies if these are naive and wrong guesses, but I notice the GUI is written in WinForms. Could it be due to one of these reasons?

[pylorak]

The logs only measure executions times and delays in the service process. It is entirely possible that the cause of the delay is not there but in the GUI process. But as the two processes must communicate, a delay in the service process would also show up in the GUI.

A 1-2 second delay when opening the window the first time (and not afterwards) is completely expected. This is due to the process being JIT-compiled by the .Net Framework. Delays larger than that or delays that occur every time you open the window are the abnormal ones. None of my computers or virtual machines show such abnormal behavior, which is why currently the best I can do is make guesses, until I can debug an affected machine.

The first two links (both basically describe the same thing) could very well be the reason, but these have nothing to do with WinForms. These would be true for any other GUI framework on Windows (and actually even for Linux or Mac). It is a known phenomenon that happens when a long operation blocks a message-loop that is responsible for interactivity.

The real question is, what takes so long in TinyWall's GUI process (but only on some machines)? My current best guess is the extraction of application icons for the list of exceptions, but it would be nice to verify this on an affected machine.

[9ao9ai9ar]

The real question is, what takes so long in TinyWall's GUI process (but only on some machines)? My current best guess is the extraction of application icons for the list of exceptions, but it would be nice to verify this on an affected machine.

I just added a bunch of executables with embedded icons from my slow HDD to the exceptions list (block all traffic), one of them being 300+ MB. No observable difference, except the modify rules window for the large program opens up slower, presumably due to checksumming. Something else is making the controller GUI non-responsive.

Just shooting some targets at random, but this is a benchmark of my data drive:

My systems drive is an SSD with about 10x the score, except the sequential writes, which are only 3x higher in score.

I also have Mandatory ASLR, memory integrity (under core isolation), and DEP for all programs and services turned on.