Windows 10, Version 1809. Network does not show computers

>"I disabled the workaround that restarts FDResPub."

>"Enabled Remote Desktop and after that I cannot make it fail it anymore on either 1903 or 20H1."

I did this same test with two PC's which run 20H1 (build 19013.1000) and one run 19H2 (build 18363.449)

and I get same result that you have.

Sharing was working and File Explorer show all 3 connected PC's under 'Network' when workaround was disabled and RDP enabled.

I leave these settings on to see how it work on everyday usage.

>"I disabled the workaround that restarts FDResPub."

>"Enabled Remote Desktop and after that I cannot make it fail it anymore on either 1903 or 20H1."

I did this same test with two PC's which run 20H1 (build 19013.1000) and one run 19H2 (build 18363.449)

and I get same result that you have.

Sharing was working and File Explorer show all 3 connected PC's under 'Network' when workaround was disabled and RDP enabled.

I leave these settings on to see how it work on everyday usage.

Pauli O, 

Thanks for confirming, no idea why the behavior changes.

This works with Win10 Pro, the Home version does not have Remote Desktop so when they have the same issue they can use the FDResPub restart workaround, until MS comes out with a proper fix,  I added a feedback. 

https://aka.ms/AA6eq5z

I have Win 10 Home installed and I've been using the workaround that restarts FDResPub for a long time.

I recently installed a fresh copy (from scratch) of Win 10 v.1909. I was delighted upon the install to see the problem was gone, so I thought. I then proceeded to update my fresh install using Windows Update and I was really disappointed to see the problem coming back as before. I made sure all the appropriate services were running and starting automatically and they were.

I was intrigued by the fact FDResPub was using a trigger start, regardless if it was set to Manual or Automatic. I did not understand what it really was doing. After some research on Google, I was starting to understand the concept. I found a free software ("Service Trigger Editor") which allows to see what the trigger is for every service. In the case of FDResPub, the trigger is based on the network becoming "Private".

The software also allows to add or remove any trigger for any service. I was curious to see what would happen if I removed the trigger for FDResPub. I removed it and rebooted. I could not believe it but the problem was gone and it did not come back up to now. It is still a bit of a mystery to me why this solved my problem.

In any case, I am sharing my experience hoping it could help others that had to cope with this issue for so long.

You can download Service Trigger Editor from this link "https://www.coretechnologies.com/products/ServiceTriggerEditor/".

The network profile is set to private, so if that is what it is looking for, the service should trigger every time, but apparently it is not working even when it says FDResPub is running.

Perhaps that is not the right trigger ? 

I assume that if you eliminated the trigger you set FDResPub to run Automatic , or it would not start at all.

Also it is not clear why restarting the service fixes the problem when it fails.

Anyway I tried eliminating the trigger as you suggested and set it to Automatic and it seems to work. 

It is like going back to 1803 :)

(Perhaps till the next update breaks it again ?)

After over 2 years MS still did not fix this bug. :(

I'm happy to see this worked for you also. The services are set are set as follows on my PC:

1. Function Discovery Provider Host: Manual start, not running
2. Function Discovery Resource Publication: Automatic, running
3. SSDP Discovery: Manual, running (I don't know why it is running if it is set to manual start without a trigger)
4. UPnP Device Host: Manual, not running

I've set my network profile as private while configuring Windows after install.

Hopefully, the trigger will not reappear in future updates. At least, we know what to do if it does.

I agree with you, MS should have fixed this a long time ago.