Windows 10, Version 1809. Network does not show computers

Galileo1564 and @mhanor, 

This is what I see with my machines:

Microsoft Windows [Version 10.0.18362.239]

(c) 2019 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>sc qtriggerinfo FDResPub

[SC] QueryServiceConfig2 SUCCESS

SERVICE_NAME: FDResPub

START SERVICE

          CUSTOM                       : fbcfac3f-8460-419f-8e48-1f0b49cdb85e [ETW PROVIDER UUID]

                DATA                       : PROFILE_CHANGED_TO_PRIVATE

C:\WINDOWS\system32>

As I said earlier I have 5 machines all at 1903 build 18362.239 and only 2 of them used to fail with 1809,

Now with 1903 the 2 that were failing with 1809 are no longer failing and I can confirm that it is a timing issue.

I assume that the trigger used does not insure that the network adapter is up and ready when the FDResPub is started.

The 2 failing machines were the following:

1. Dell XPS 8700 with Realtek PCIe GbE Family Controller , Driver  10.28.615.2018 Dated 6/15/2018
2. MSI GT70-0NC, with Killer E2200 Gigabit Ethernet Controller , Driver 9.0.0.48 Dated 8/31/2018

Currently if all 5 machines are running 1903 Build 18362.239 none fail.

But when I change one of the 5 machines in the same network to the preview Build 18941, then the Dell XPS 8700 fails intermittently after a restart even if it is running 1903 build 18362.239 .

The MSI GT70-0NC with Killer E2200 has now a newer driver 9.0.0.49 Dated 9/20/2018 and I cannot make it fail anymore.

Probably the newer driver is faster to get the adapter up and ready.

I think MS may not be using the correct trigger to start the service, just by luck it may work depending on the network adapter being up and ready before the service FDResPub is started on the trigger.

3 out of 5 of my machines never failed even with 1809, now just one fails intermittently after a restart, while the other 4 seems to work fine every time. 

B.T.W.

I just saw that there is a newer driver for Realtek dated 05/10/2019,  I installed it and tried a few restarts, I could not make it fail yet, we'll see if it is consistent.

@mhanor

Good observation for checking the trigger info.  I am currently running Build 1903 (18362.239) which shows the trigger is - in fact - set correctly.  My case is not Build 1809 and thus is no longer a useful check against issues with that build.  As I no longer have access to that build, I cannot validate whether or not the trigger was set correctly by Microsoft upon installation of that Windows build.

However, I can report that the network issue did still exist in a clean install of Build 1903 - despite the trigger being in place correctly.  Unfortunately, I found it still necessary to add the FDResPub workaround to Build 1903.  It is worth noting that all the way up to and including Insider Build 18941, this issue also still exists.  Apparently, MS has not resolved the timing issue.

As an enhancement to the Task Scheduler FDResPub task, I have added an additional trigger event.  I had noticed that the network entries do occasionally disappear after the system(s) are left in "Sleep" mode for some length of time.  To resolve this, I have added the following additional item in the "Triggers" page of the task:

Begin the task:  On workstation unlock

(Leave all other settings as default on that page)

(Please note that this is an additional trigger event)

For my systems, I require unlocking when returning from sleep mode.  After adding this additional trigger, the act of unlocking the system will trigger the FDResPub task to run again and thus announce/refresh the system's network availability/presence.

The problem for FDResPub not starting when it should, could be a missing trigger.

To see if the trigger is present, run in Command Prompt:

sc qtriggerinfo FDResPub

To add the trigger, run as Administrator:

sc triggerinfo FDResPub start/strcustom/fbcfac3f-8460-419f-8e48-1f0b49cdb85e/PROFILE_CHANGED_TO_PRIVATE

Keep the service on startup type Manual.

The solution was found here:

https://www.sitespiral.jp/information/727/

Thanks to galileo1564 for the FDResPub "work around" solution.

As a Win 8.1 user until earlier this year I have always experienced this issue, migrated to Win 10 Home with a new build, Gigabyte MoBo, Ryzen-5 CPU desktop PC and had absolutely no issues for the first 2 months until Win update 1809 came along when I started to get random, local network disconnect issues with PC running, had to un-install MoBo, Realtek NIC and re-install to restore LAN comm's even though the network device showed completely health in Device Manager.

As there was recorded history of Realtek LAN driver conflict with Win 10, again believed to be associated with Win updates, decided to fit an Intel PCIe NIC, this worked very well for a week or so then returned to the same issue.

Have tried all combination of drivers on both the Realtek and Intel NIC's without success.

The local network device display issue in Win Explorer also comes and goes and appears to coinside with the random network disconnects.

The good news is the FDResPub, Scheduled Task work around restores both the NIC comm's and Win Explorer LAN device visibility with a re-boot, still annoying but a lot easier than previous requirements.

Perhaps MS will get around to supplying a fix at some stage but won't hold my breath on that one !

Hmm, it would seem then that the probability that the network adapter hardware is the issue is rather low.  The behavior of you systems is more probably an OS issue rather than a hardware issue per se.  MS has been re-plumbing the black box of Windows for many reasons and boot-up timing could well be changing across various builds as their development work moves along.  Thus, differing versions may be triggering different behaviors - especially where timing sensitive events are occurring...

This issue is ultimately for MS to triage...and end users to...wait for....

I agree that this looks like a timing issue.

Given that everything works when FDResPub is restarted after the system is up, I think they just need to check that the network is ready before they start the service. 

It is true that the boot-up timing is changing with each release of windows, but the start of the services should be triggered on precise events after the network is ready.

Right now it just works by luck based on timing of different machines.