Windows 10, Version 1809. Network does not show computers

Not so for me. Upgraded 1809 - 1903 last night and the issue still persists! 

Hi skvenus99,

I did a few more checks and I verified that when all my five machines on my home network are at level 1903 build 18362.116 they all worked without using the workaround, but when I have a mixed environment with one machine at different level (like 20H1 build 18898.1000 or  back to 1809 build 17763.529) the other machines in the network may fail too even if they are running 1903.

Apparently the mixed level environment brings back the original bug consistently. 

I had to enable the workaround to get the failing ones to show up in the network.

It looks like the results are deceiving, with all the computers at 1903 it seems to work, but very intermittently I managed to get one of the PC's to fail and not show up after a restart.

With mixed environment they fail every time after a restart.

galileo1564,

I believe that Microsoft could fix this bug for any network adapter combination by checking that the network adapter is ready before starting the service Function Discovery Resource Publication.

That would take care of the problem regardless of how long it takes for the different adapters and drivers to be up and running. Unfortunately MS never fixed the bug that was reported over a year ago with the release of 1809.

The fact that it seems to work with 1903 could be just a coincidence and the service FDResPub may be starting when the network is actually already up.

Since the bug is still present with Preview 20H1 build 18898 it means that the bug was never really fixed.

You may well be right in that some network adapters make their network connections faster than others.  And, if this is a timing issue, the hardware response times could be the culprit(s).  A test to see if this is the issue is to find two machines: one that has never exhibited the network connection issue and another that has exhibited the issue - and then perform clean installs of each version of Windows from...say 1703 through 1903...on each machine and monitor the network connection following cold boots and sleep resumes.  This will yield some insight as to whether or not this is a Windows issue or a hardware issue. 

This is not a perfect test though.  The acid test would be taking a given machine and repeating the installs - and - performing this install regimen for different network adapters on the same machine - using adapters that have exhibited the issue and that have not.

That's is a lot of effort for an end user, and frankly, not an end user's responsibility.  This is the type of A:B testing across various versions of Windows that is - or should be - conducted in house by MS prior to release of any Windows version.  That effort is what it takes to tease out these kinds of issues.  Regardless of what one would discover in doing this triage effort, the end user cannot fix this issue if it really is an OS "plumbing" problem.

Hence, for end users, a simple work around and reporting the issue to MS are the best courses of action.

Hi galileo1564,

In my case this problem seems to be limited to 2 machines out of 5.  Note that all 5 worked fine with 1803.

It seems like the problem is affecting machines with specific network adapters and the time it takes for the adapters to be ready.

If service FDResPub is started before the network adapter is up and ready then we get the issue and we need to restart the service.

Three out those five machines never failed regardless of upgrade or fresh installs at any level.

Two machines failed solid with 1809 and with all the preview releases of 19H1 and 20H1, but now they work fine with released 18362.116. 

Failing machines:

1. Dell XPS 8700 with

    Realtek PCIe GbE Ethernet Controller

    Dell Wireless 1703 802.11b/g/n (2.4GHz)

2. MSI GT70-0NC laptop with

    Killer E2200 Gigabit Ethernet Controller

    Intel Centrino Wireless N 2230:

Machines that never failed at any update level:

3. Dell XPS 8300 with

    Broadcom NetLink Gigabit Ethernet

4. Dell OptiPlex 380 with

    Broadcom NetLink Gigabit Ethernet

5. Lenovo Yoga 920 13IKB with

    Intel Wireless AC 9260  160MHz

Wonderful that 1903 build 18362.116 has solved the issue for you!  This issue is a very difficult one to triage - it appears somewhat mercurial in its appearance (and disappearance).  I have seen no problems on machines that have been upgraded over all builds from 1703 up through 1809...but have seen the issue appear on several clean install builds within that range of upgrades...a very difficult issue to track to its root cause.

It seems as though there may be some internal setting that is getting installed - or "set" - in some builds that isn't receiving the same value in some other builds.  And, in some cases said setting may be set either correctly or incorrectly and is being "grandfathered" as other upgrade builds are installed.  Thus, propagating downstream whatever condition you particular machine is in - i.e. new upgrade builds do not change the particular setting regardless of whether it was correctly or incorrectly set initially.  In other cases, upgrades do "revise" the relevant setting(s).

Clean installs that "happen" to work correctly "may" be the key to resolving this issue - assuming that there is an "unknown" setting that will remain "grandfathered" and propagated downstream as future upgrades are applied.  This would be the reason that some installations work correctly across all downstream upgrades - in that once a "correct" build is clean installed its "correct" settings then propagate downstream across all future upgrade installations (regardless of whether a given future upgrade would have worked incorrectly if it were clean installed).  And, conversely, once an "incorrect" build is clean installed its settings would also be propagated downstream across future upgrade installations - again, regardless of whether a given future upgrade would have worked correctly if clean installed.

Definitely a maddening situation for the end users. And, equally not the responsibility of the end users to resolve...

galileo