PostgreSQL 17 Service Running but Not Listening on Network Port on Windows

*Subject: PostgreSQL 17 Service Running but Not Listening on Network Port
on Windows*

*Environment:*

- *Operating System:* Windows 10/11
- *PostgreSQL Version:* 17 (Fresh Installation)
- *Testing Tools:* Windows Services (services.msc), Command Prompt (
netstat), DBeaver

*Problem Description:* A fresh installation of PostgreSQL 17 on a Windows
machine starts successfully according to the Windows Services Manager, but
the process fails to open its configured network port (5432). This makes it
impossible for any application to connect. The issue persists even after a
complete and clean reinstallation.

*Key Symptoms:*

- The postgresql-x64-17 service shows a status of *"Running"* in
services.msc.
- The postgresql.conf file is correctly configured with listen_addresses
= '*' and port = 5432.
- The command netstat -aon | findstr "LISTEN" | findstr "postgres"
returns *no output*, proving the process is not listening on any port.
- The command netstat -aon | findstr ":5432" also returns *no output*,
proving no other application is conflicting on that port.

*Troubleshooting Steps Performed:*

1. Verified the PostgreSQL service is "Running" after every
configuration change.
2. Verified the postgresql.conf settings (listen_addresses and port).
3. Confirmed no other application is using port 5432 via netstat.
4. Created a specific *port-based* inbound rule in Windows Defender
Firewall to allow all TCP connections on port 5432.
5. Created a more robust *program-based* inbound rule in Windows
Defender Firewall for the postgres.exe executable (C:\Program
Files\PostgreSQL\17\bin\postgres.exe).
6. Restarted the PostgreSQL service after every configuration change.
7. Performed a full uninstall, manual folder deletion, reboot, and clean
reinstallation of PostgreSQL 17. (Note: The same issue was observed when
testing with PostgreSQL 16).
8. Considered and ruled out third-party antivirus as the user has none.

*Conclusion:* The evidence strongly suggests the issue is not with the
PostgreSQL configuration but with a low-level environmental factor on this
specific Windows machine (e.g., a hidden security policy, a third-party
security application that is not Windows Defender, or a corrupted Windows
networking stack) that is preventing the postgres.exe process from
successfully binding to a TCP socket.

*Given that the PostgreSQL configuration is correct and standard firewall
troubleshooting has been performed, the root cause appears to be an
environmental issue on my Windows machine that is blocking the postgres.exe
process from binding to its network port.*

*My question is: What other, less common Windows-level factors could cause
this specific behavior?*

*For example, could this be related to:*

- *Specific Group Policies (secpol.msc)?*
- *Permissions issues tied to the 'Network Service' account that
PostgreSQL runs under?*
- *Conflicts with specific VPN software, virtualization software (like
Hyper-V), or other low-level network drivers?*
- *A known bug with the Windows networking stack itself?*

*Any suggestions for deeper diagnostic steps or potential hidden conflicts
on Windows would be greatly appreciated."*