How to Block an App’s Internet Access in Windows 10 and 11 Firewall and Verify It With Event 5157

TweakTown's Yasir Mahmood recently walked through using that rule to stop a hardware monitor from checking for updates. Below is the procedure, what it does and doesn't do, and how to confirm it works. The HWiNFO64 and Slack examples are the author's own experience. I haven't independently tested either app.

Why Settings and Windows Security can't do this​

Windows Security's Firewall & network protection page shows the Domain, Private and Public profiles with an on/off state. According to TweakTown, none of the links below them blocks a specific app.

The tempting option is "Allow an app through firewall". That list governs incoming connections. Unchecking an app there stops other devices from reaching it, but the app can still send data out. The Network & internet page in Settings only sets data limits for a whole connection.

The tool you need is behind the Advanced settings link on that same page. It opens Windows Defender Firewall with Advanced Security. You can also open it by pressing Win + R, typing wf.msc and pressing Enter. Microsoft's documentation confirms that route for a single device. Expect a UAC prompt, and you need administrator rights.

The author says the console's Overview pane showed the default on his laptop. Every profile read that outbound connections not matching a rule are allowed.

Step 1: Find the executable that actually connects​

A program rule only matches the exact executable you point it at. A Start menu shortcut may not show which file that is.

1. Launch the app.
2. Press Ctrl + Shift + Esc to open Task Manager and switch to the Details tab.
3. Right-click the app's process and choose Open file location.
4. Copy the full path from File Explorer's address bar.

In PowerShell you can also run Get-Process HWiNFO64 | Select-Object -ExpandProperty Path, substituting your app's process name. TweakTown says this prints the same path. I didn't separately check that command against documentation.

Watch for versioned paths. The author says Slack on his PC runs from a folder like AppData\Local\slack\app-4.51.180\slack.exe, and the version number changes with each update. A rule pointing at the old folder stops matching. Recheck the path after updates for any app installed in your user profile. This is one person's example, not a statement about every Slack installation.

Microsoft Store apps often run as protected packages instead of from a normal program path. TweakTown's approach is to start a Custom rule with All programs selected. Then open the rule's Properties, go to the Programs and Services tab, and pick the app under Application Packages. I haven't verified those menu labels against Microsoft documentation, so treat them as the author's instructions.

Step 2: Create the outbound block rule​

Graphical method

1. In the console, select Outbound Rules, then New Rule in the Actions pane.
2. Choose Program and click Next.
3. Select This program path, browse to the executable and click Next.
4. On the Action page, select Block the connection.
5. Leave Domain, Private and Public all checked.
6. Give the rule a name you'll recognize, such as "Block HWiNFO64", and click Finish.

Microsoft's own steps for an outbound program rule are close to this. It uses the Custom rule type, which exposes every wizard page. The docs note that Program or Port limit the number of pages presented by the wizard. Microsoft also says this type of rule prevents the program from sending any outbound network traffic on any port.

PowerShell method (run as administrator)

New-NetFirewallRule -DisplayName "Block HWiNFO64" -Direction Outbound -Program "C:\Program Files\HWiNFO64\HWiNFO64.EXE" -Action Block

Replace the path with the one you found. The example path is only illustrative. Microsoft's cmdlet reference confirms the cmdlet creates inbound or outbound rules and accepts -Program, -Direction and -Action. It also says the Profile parameter defaults to Any, which covers Domain, Private and Public.

Why leave all three profiles checked?​

Windows applies whichever profile matches how it classified the current network. Private is typically home, Public is cafés and airports, and Domain applies only to domain-joined PCs. Microsoft's reference says the rule is active only when the specified profile is currently active. If you uncheck Public, the app gets back online on any network Windows marks Public.

Step 3: Undo it​

In the console, right-click the rule and choose Disable Rule or Delete. In PowerShell, TweakTown gives Remove-NetFirewallRule -DisplayName "Block HWiNFO64". A separate guide I found shows Disable-NetFirewallRule and Remove-NetFirewallRule used the same way. Disabling is the safer first move if you aren't sure the app will still work.

Step 4: Check that the block actually holds​

The first sign is in the app itself: update checks fail, sign-in screens spin, and web-loaded content stays blank. That's encouraging but not proof.

Resource Monitor. Press Win + R, type resmon, and open the Network tab. Without the rule, the app may appear under TCP Connections. With the rule it should drop off. This only shows live connections, so a missing entry isn't proof of anything.

Event 5157. For evidence that names the program, use Windows auditing:

1. In an elevated terminal, run auditpol /get /subcategory:"Filtering Platform Connection" and note the current state.
2. Run auditpol /set /subcategory:"Filtering Platform Connection" /failure:enable.
3. Launch the app and retry its online feature.
4. Open Event Viewer and go to Windows Logs > Security, then look for Event 5157.

Microsoft documents Event 5157 as generated when the Windows Filtering Platform has blocked a connection. The event record includes the full path of the executable and the direction of the blocked connection. That makes it a good way to confirm the rule matched the right file.

If the original state was "No Auditing", TweakTown suggests running the set command again with /failure:disable afterward, because this audit fills the log quickly. Record your starting state first rather than assuming it was off.

Limits and gotchas​

• It blocks more than telemetry. A program rule doesn't separate a phone-home ping from an update check or a sign-in. Any online feature of that executable can break. Test what you need before relying on the rule.
• It isn't internet-only by default. The simple rule blocks the program's outbound traffic generally, which can include local-network devices. Microsoft's cmdlet reference lists -RemoteAddress keywords such as Internet, LocalSubnet and Intranet. If you want to block only certain destinations, you have to build a more granular rule.
• Helpers and updaters may be separate executables. If Event 5157 never appears after you retry the app's online features, it probably connects through another file. Give that file its own rule.
• Third-party security suites can take over. TweakTown advises checking which firewall provider Windows Security lists, since a suite like Norton may mean the Windows rule controls nothing. I couldn't verify that independently, so treat it as troubleshooting advice rather than a universal rule.
• Block rules beat allow rules. TweakTown says a block rule overrides any allow rule the app's installer added. A third-party guide I found makes the same point, though I didn't find Microsoft wording for it in this research.
• Encrypted DNS is a different tool. It hides your lookups from the network but won't stop an app from connecting.

Is this better than a third-party firewall?​

For a short list of apps that have no business being online, one rule each is cheap and needs no extra software. The trade-off is upkeep. Rules are tied to file paths, so apps that move folders on every update need rechecking. That's the case for anything installed under AppData. A third-party firewall can do per-app prompting, but it adds another component to maintain.

A sensible way to start is to use Resource Monitor's Network tab to list what is talking, pick one app, and build and verify a single rule. Then expand from there. Keep the rule names descriptive so you can find and disable them later.