Windows 11 25H2 (Build 26200.9445) does not show the local PC in File Explorer Network

Hi,

As @Mathanraj user has already suggested, this appears to be a bug that has existed since older versions of Windows; many users have reported this issue.

A workaround—though not always effective—is to set up a scheduled task to constantly restart the relevant services (FDResPub, fdPHost, and SSDPSRV), perhaps every 1 or 2 minutes, to ensure the discovery service keeps running.

To clarify, this isn't an SMB failure but rather a service bug—as you correctly suspected. Many users describe it as a bug, and in my experience dealing with this issue multiple times, there is no official, definitive fix.

There is an explanation here: https://learn.microsoft.com/en-us/answers/questions/806041/local-computer-not-appearing-in-explorer-network-v

The link above discusses the likely cause of this bug.

Thanks.

Yes. Based on the symptoms, I would not treat this as an SMB connectivity problem. The important distinction is that \\Lucas, \\localhost, \\127.0.0.1, and \\192.168.0.90 all work, while Explorer's Network view omits the local machine.

The strongest clue is that restarting FDResPub makes Lucas appear temporarily. That points toward the network-computer enumeration/registration path, rather than SMB itself.

Recommended troubleshooting order

Do not re-enable SMB1

SMB1 is not required for normal SMB2/SMB3 file sharing and should remain disabled.

Verify the discovery services and dependencies

Run PowerShell as Administrator:

Get-Service FDResPub,fdPHost,SSDPSRV,upnphost,lanmanserver,lanmanworkstation |
    Select Name,Status,StartType

Then:

sc.exe qc FDResPub

I would leave the default Microsoft dependency configuration intact rather than adding LanmanWorkstation permanently.

Check the FDResPub registration

Restarting FDResPub causing the machine to appear is particularly useful diagnostically:

Restart-Service FDResPub

Immediately check:

\\localhost

and then Explorer → Network.

If Lucas appears only until Explorer is restarted, that strongly supports an enumeration/registration issue.

Check whether Windows sees the PC as discoverable

Run:

Get-NetConnectionProfile

Confirm that the active Ethernet adapter has:

NetworkCategory : Private

Also run:

Get-NetFirewallRule -DisplayGroup "Network Discovery" |
    Where-Object {$_.Enabled -eq 'True'} |
    Select DisplayName,Profile,Direction,Action

Check the Windows network-discovery event logs

Look particularly at:

Event Viewer → Applications and Services Logs → Microsoft → Windows

• NetworkProfile
  • NetworkDiscovery
    • FDResPub
      • Function Discovery
        • WSDAPI
          • WFP
          The objective is to find what happens to the local registration when File Explorer is reopened—not simply whether SMB is working.

A useful diagnostic test

Because the problem is specifically self-enumeration, I would test the discovery path independently of Explorer.

Run:

Get-NetTCPConnection -LocalPort 445 -State Listen

and:

Get-SmbServerConfiguration |
    Select EnableSMB1Protocol,EnableSMB2Protocol

Then:

nbtstat -n

The expected NetBIOS registrations you already reported (LUCAS <00>, WORKGROUP <00>, and LUCAS <20>) make a basic NetBIOS registration failure unlikely.

One particularly important point

Do not use the appearance of Lucas in File Explorer → Network as the test for whether file sharing works.

Explorer's Network page is an enumeration/discovery UI. It is separate from the fundamental ability to establish an SMB connection.

Your successful tests:

\\Lucas
\\localhost
\\127.0.0.1
\\192.168.0.90

already demonstrate that the SMB server is functioning.

So I would frame the issue as:

Windows 11 Explorer/Function Discovery fails to persistently enumerate the local computer in the Network namespace, despite successful SMB connectivity and Function Discovery service operation.

What I would investigate next

Since this is specifically Windows 11 25H2 Build 26200.9445, I would also compare the behavior after installing the latest available cumulative update for that build. If the issue remains, Microsoft's internal investigation should focus on:

• FDResPub
• Function Discovery Provider Host (fdPHost)
• WSD/WS-Discovery
• Explorer Network namespace enumeration
• Windows Filtering Platform loopback handling
• changes between the affected 25H2 build and previous builds

I would not recommend registry hacks, permanently modifying FDResPub dependencies, or reinstalling SMB1 at this stage. Those would be treating the wrong layer.

If this is being posted as a Microsoft Q&A question, the evidence you have already collected is actually quite good. The next valuable diagnostic information would be the FDResPub/Function Discovery event logs immediately before and after restarting FDResPub, because that can help distinguish a genuine Windows discovery regression from a local configuration problem.Yes. Based on the symptoms, I would not treat this as an SMB connectivity problem. The important distinction is that \\Lucas, \\localhost, \\127.0.0.1, and \\192.168.0.90 all work, while Explorer's Network view omits the local machine.

The strongest clue is that restarting FDResPub makes Lucas appear temporarily. That points toward the network-computer enumeration/registration path, rather than SMB itself.

Recommended troubleshooting order

Do not re-enable SMB1

SMB1 is not required for normal SMB2/SMB3 file sharing and should remain disabled.

Verify the discovery services and dependencies

Run PowerShell as Administrator:

Get-Service FDResPub,fdPHost,SSDPSRV,upnphost,lanmanserver,lanmanworkstation |
    Select Name,Status,StartType

Then:

sc.exe qc FDResPub

I would leave the default Microsoft dependency configuration intact rather than adding LanmanWorkstation permanently.

Check the FDResPub registration

Restarting FDResPub causing the machine to appear is particularly useful diagnostically:

Restart-Service FDResPub

Immediately check:

\\localhost

and then Explorer → Network.

If Lucas appears only until Explorer is restarted, that strongly supports an enumeration/registration issue.

Check whether Windows sees the PC as discoverable

Run:

Get-NetConnectionProfile

Confirm that the active Ethernet adapter has:

NetworkCategory : Private

Also run:

Get-NetFirewallRule -DisplayGroup "Network Discovery" |
    Where-Object {$_.Enabled -eq 'True'} |
    Select DisplayName,Profile,Direction,Action

Check the Windows network-discovery event logs

Look particularly at:

Event Viewer → Applications and Services Logs → Microsoft → Windows

• NetworkProfile
  • NetworkDiscovery
    • FDResPub
      • Function Discovery
        • WSDAPI
          • WFP
          The objective is to find what happens to the local registration when File Explorer is reopened—not simply whether SMB is working.

A useful diagnostic test

Because the problem is specifically self-enumeration, I would test the discovery path independently of Explorer.

Run:

Get-NetTCPConnection -LocalPort 445 -State Listen

and:

Get-SmbServerConfiguration |
    Select EnableSMB1Protocol,EnableSMB2Protocol

Then:

nbtstat -n

The expected NetBIOS registrations you already reported (LUCAS <00>, WORKGROUP <00>, and LUCAS <20>) make a basic NetBIOS registration failure unlikely.

One particularly important point

Do not use the appearance of Lucas in File Explorer → Network as the test for whether file sharing works.

Explorer's Network page is an enumeration/discovery UI. It is separate from the fundamental ability to establish an SMB connection.

Your successful tests:

\\Lucas
\\localhost
\\127.0.0.1
\\192.168.0.90

already demonstrate that the SMB server is functioning.

So I would frame the issue as:

Windows 11 Explorer/Function Discovery fails to persistently enumerate the local computer in the Network namespace, despite successful SMB connectivity and Function Discovery service operation.

What I would investigate next

Since this is specifically Windows 11 25H2 Build 26200.9445, I would also compare the behavior after installing the latest available cumulative update for that build. If the issue remains, Microsoft's internal investigation should focus on:

• FDResPub
• Function Discovery Provider Host (fdPHost)
• WSD/WS-Discovery
• Explorer Network namespace enumeration
• Windows Filtering Platform loopback handling
• changes between the affected 25H2 build and previous builds

I would not recommend registry hacks, permanently modifying FDResPub dependencies, or reinstalling SMB1 at this stage. Those would be treating the wrong layer.