Windows 10, Version 1809. Network does not show computers

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

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

Hi skvenus99, 

Strange, I'm not sure what the difference can be, perhaps you have a different issue.

The bug was solid on 2 PC's with 1809 and all the insider previews of 19H1 or 20H1, but the same 2 machines upgraded to released 1903 build 18362.116  work fine without using the workaround that restarts FDResPub . 

I have 5 PC's upgraded to the same 1903 level and none show the bug.

Go figure ?

They will probably fail again on some future update, I guess I'll have to wait and see what happens :(.

Hi Galileo1564, 

The problem appears to be fixed in the new Window 10 V 1903 build 18362.116 just released to general users on 5/21/2019.

I upgraded all my PC's from  v 1809 build 17763.529 to v 1903 build 18362.116 and the PC's that were previously failing with 1809 are now working fine with the workaround disabled in Task Scheduler.

All my PC's are showing up in the network and keep showing up normally after PC restart.

Unfortunately the bug is still present with Windows 10 preview 20H1 build 18898.1000.

Since it appears to be fixed with 1903 I hope they add the same fix in the next 20H1 insider preview.