Network Discovery Explained — Why PCs Disappear From Your Network
Computers that were visible in your Network folder yesterday are gone today. This explainer covers exactly how Windows network discovery works and why it fails.
The Problem Stated Precisely
You open File Explorer and click Network in the left sidebar. One of three things happens:
- All your office PCs appear — the good day
- Some appear and some do not — the frustrating day
- Nothing appears except your own machine — the lost afternoon
The computers have not gone anywhere. You can still reach them by typing their address directly. The discovery system that should show them automatically has failed.
This article explains exactly why this happens.
How Windows Network Discovery Actually Works
When Windows needs to populate the Network folder, it does not broadcast "who is out there?" and wait for responses in a simple way. It uses a layered system involving multiple services, protocols, and dependencies.
Layer 1 — WS-Discovery (Web Services for Devices) Windows machines announce their presence on the network using WS-Discovery, a protocol that sends XML-based announcements via UDP multicast. When a machine starts, it sends a "Hello" announcement. When it shuts down, it sends a "Bye." Other machines listen for these and update their record of who is present.
Layer 2 — SSDP (Simple Service Discovery Protocol) SSDP is used for UPnP device discovery — the same protocol used to find smart TVs, media servers, and other non-Windows devices. Windows uses it as a supplementary discovery layer.
Layer 3 — Function Discovery Windows' Function Discovery framework aggregates discovery results from WS-Discovery, SSDP, and other sources into the unified list that appears in the Network folder.
Layer 4 — The Network Location Windows will only participate in network discovery on networks classified as "Private." On networks classified as "Public," all discovery is blocked as a security measure.
All four layers must be working simultaneously for computers to appear in the Network folder.
The Four Services That Must Be Running
For WS-Discovery and SSDP to work, four Windows services must be running:
- Function Discovery Resource Publication (FDResPub) — publishes your machine to others
- SSDP Discovery (SSDPSRV) — handles SSDP announcements
- UPnP Device Host (upnphost) — hosts UPnP services
- DNS Client (Dnscache) — required for mDNS and LLMNR name resolution
Check their status: Press Win+R → services.msc → find each service → confirm they are Running with Startup Type = Automatic.
If any shows Stopped or Manual, that is your problem.
Quick fix via PowerShell (run as Administrator):
Set-Service FDResPub -StartupType Automatic
Set-Service SSDPSRV -StartupType Automatic
Set-Service upnphost -StartupType Automatic
Start-Service FDResPub, SSDPSRV, upnphost
Why These Services Keep Breaking
Windows Updates. This is the root cause for most sudden discovery failures.
Cumulative updates occasionally reset service startup types. A service set to Automatic gets changed to Manual. At next reboot, the service does not start. The Network folder empties. The update does not announce this in any visible way.
This is not a rare edge case — it is a documented pattern that small office users experience after major Windows Updates.
Why the Network Profile Breaks Discovery
When you connect to a network for the first time, Windows asks whether the connection is Private or Public. If you pick Public (or if Windows auto-assigns Public for a work network), discovery is disabled.
This often happens when:
- A new network card is installed
- The office router is replaced
- WiFi and ethernet are both connected and Windows picks the wrong profile for the primary connection
- A corporate VPN changes the network classification
Check and fix the network profile: Settings → Network and Internet → click your connected network → Network Profile → select Private.
Why Computers Appear Intermittently
If computers appear sometimes but disappear at others, the cause is usually one of:
1 — Discovery announcements expiring WS-Discovery announcements have a TTL (time to live). If the service is running but intermittently slow, other machines' records of your machine expire before the next announcement arrives.
2 — The host machine went to sleep A machine in sleep mode stops sending WS-Discovery announcements. Other machines eventually remove it from their network browser. When the sleeping machine wakes up, it sends a new Hello announcement and reappears — but there can be a 60–90 second delay.
3 — Network switch flooding Unmanaged switches flood multicast traffic to all ports. Managed switches with IGMP snooping filter multicast. If IGMP snooping is misconfigured, discovery announcements may not reach all machines.
How Mac Handles Discovery
macOS uses Bonjour (mDNS) for network discovery, which operates on a single service running continuously in the background. There is no multi-service dependency chain.
When a Mac connects to a network, it registers its name and services via mDNS almost immediately. Other Bonjour-enabled devices (Macs, iOS devices, many printers and NAS devices) see it within seconds. This is why Mac-to-Mac discovery in Finder's Network sidebar is considerably more reliable than Windows-to-Windows discovery via the Network folder.
For cross-platform discovery (Mac finding a Windows machine, or vice versa), reliability depends on which discovery protocol each side uses. Macs can connect to Windows shares via Connect to Server (direct IP or UNC path) even when automatic discovery fails.
Why Application-Level Discovery Is More Reliable
File sharing applications that handle their own discovery — rather than relying on Windows' WS-Discovery/SSDP infrastructure — bypass all of the above failure modes.
When Oxolan runs on two machines on the same network, it uses its own protocol to announce presence and discover peers. This does not interact with the four Windows services, does not depend on Private network classification, and does not reset after Windows Updates.
The result is that machines running the application appear in its sidebar reliably, regardless of whether the Windows Network folder is showing anything.
Frequently Asked Questions
I can ping the machine but it does not appear in the Network folder. Why? Ping uses ICMP, a completely separate protocol from WS-Discovery. A machine being pingable confirms it is on the network and reachable — it says nothing about whether its discovery services are running. The machine is there; its announcement services are not.
Does rebooting the host machine fix it temporarily? Yes, often. Rebooting restarts the discovery services (if their startup type is set to Automatic) and sends fresh Hello announcements. The fix is temporary if the underlying issue (wrong startup type or wrong network profile) is not addressed.
Can I disable the Network folder and just use UNC paths?
Yes. Many experienced users train themselves to use \\COMPUTER-NAME\ShareName directly instead of browsing the Network folder. This bypasses the discovery layer entirely and is more reliable. The mapped drive (Z:\) approach achieves the same thing with less typing.
Does a VPN affect network discovery? Yes, in two ways. First, some VPN clients change the network profile, which can disable discovery. Second, VPN traffic routing can interfere with multicast traffic. Check your VPN client's documentation for network discovery settings.
Done troubleshooting Windows?
Oxolan handles file sharing so you never have to think about this again.
Get Oxolan for Windows