You blocked something, and now an app is dead. Before you start deleting rules at random, let the Connections Log tell you exactly what the firewall did — it keeps the receipts.
It happens to everyone who uses outbound control: a prompt appears at a busy moment, a button gets clicked, and ten minutes later a needed program cannot connect. The good news is that this tool was designed for exactly this moment. The Connections Log records the blocked attempts, so the repair is an investigation with evidence, not a guessing game.
An app that broke right after a firewall decision almost always leaves evidence. Open the Connections Log in Windows Firewall Control and look at the blocked entries from the last few minutes. If your app's name is sitting there in a neat row of blocked attempts, you have found your culprit with proof, not vibes.
It is rarely malice and often a helper: you blocked the main program, or a prompt appeared while you were busy and got a reflex block, or the app updated itself and its new executable no longer matches the allow rule written for the old path. All three show up in the log the same way — a known program, blocked, repeatedly.
The clean repair is to create the correct rule from the evidence: in the log or the Rules panel, allow that exact program path for outbound connections. Then test the app immediately. If it works, you are done — and the rule you wrote is narrow, tied to one program, not a hole punched for everything.
If the log has no blocked entry for your app, the firewall probably did not do it — an honest negative result is valuable. Check then whether the app fails on a different network too, and whether its problem started with its own update rather than your block. Deleting random rules at this point only makes the real diagnosis harder.
Two habits stop this whole class of problem. First, when a prompt surprises you, choose block once instead of block always — nothing permanent exists to hunt down later. Second, after any big program update, expect one fresh prompt: the new version's path or signature changed, and the tool is doing its job by asking again.
One last trap: you fixed the outbound rule, the app connects — and one feature still fails. Some programs need an inbound rule too (local network discovery, receiving files, hosting a small local service), and inbound attempts do not produce the friendly prompts; they are blocked quietly. If the main connection works but a sharing or discovery feature does not, check the Rules panel for that program's inbound side as well before concluding the repair failed.
Profiles, prompts and rules — the whole Firewall Control walkthrough is in the video.
▶️ Watch Full VideoIn Windows Firewall itself — the tool writes ordinary firewall rules. Open the Rules panel in Windows Firewall Control, sort by program, and you can edit, disable or delete the block rule you created.
Treat the firewall as cleared of suspicion. The Connections Log only shows what the firewall handled; an empty log at the right time points you at the app itself, its update, or the network — not at a hidden firewall block.
Allow rules are tied to the program's file. A major update can replace or relocate that file, so the old rule no longer matches and Medium Filtering blocks the new file until you allow it. One fresh prompt and a new rule is the normal, correct outcome.