File Explorer may not detect other devices or perform file sharing on the local network when running Windows 10 version 1803

Microsoft did NOT solve my problem!! I am gradually working my way through all of the suggestions from everyone on this thread. I appreciate all of the suggestions. So far, no results, but I haven't given up. If I do find a solution, I will try to figure out exactly how I got there and share it.

I am of the same opinion. It seems like Microsoft is waiting for one of its users to solve the "mystery" so they don't have to!!!

Agreed!!!

From my household incident log, a follow-up on yesterday's diatribe.  The left column of Table 1 reprises yesterday's observations of machines WARTHOG1-M and WARTHOG2-M.  Microsoft's '1803 update enema left file sharing and RDC connectivity almost completely disabled.  Today, I brought WARTHOG1-M back to sentience by restoring its OS volumes from backups.  I left WARTHOG2-M damaged, and ran some tests.  The good news is that file sharing and RDC were back, despite the damaged code that remains in WARTHOG2-M:

+------------------------ Table 1: File sharing and RDC connectivities ------------------------+

|                                              |                                               |

|        Both machines run '1803               | WARTHOG1-M runs backup, WARTHOG2-M runs '1803 |

|                                              |                                               |

|----------------------------------------------|-----------------------------------------------|

|+ WARTHOG1-M RDC could reach WARTHOG2-M.      | + WARTHOG1-M RDC could reach WARTHOG2-M.      |

|- WARTHOG2-M RDC could NOT reach WARTHOG1-M.  | + WARTHOG2-M RDC could reach WARTHOG1-M.      |

|+ WARTHOG2-M file shares appear on WARTHOG1-M | + WARTHOG2-M file shares appear on WARTHOG1-M |

|- None of WARTHOG1-M's file shares came up on | + WARTHOG1-M file shares appear on WARTHOG2-M |

|  WARTHOG2-M.  When I picked WARTHOG1-M from  |                                               |

|  WARTHOG2-M's "Network" share offerings,     |                                               |

|  Win10 offered its troubleshooter, which     |                                               |

|  found no fault and did nothing.             |                                               |

|- For the volume letter map of the shared     | + Shared folder \WARTHOG1-M\iTunes mapped to |

|  iTunes directory to \WARTHOG2-M\X:, it     |   \WARTHOG2-M\X: as it should.               |

|  produced:                                   |                                               |

|    An error occurred while reconnecting X:   |                                               |

|    to \WARTHOG1-M\iTunes Microsoft Windows  |                                               |

|    Network:  The network path was not found  |                                               |

|    This connection has not been restored.    |                                               |

+----------------------------------------------------------------------------------------------+

Table 2 extends the results of a recommendation from Microsoft to change the start states of eight services.  The center two columns represent yesterday's work.  The leftmost column is new:

+----------------------- Table 2:  Service Start Change Problems (N1)--------------------------+     

|             |            |            |                                                      |

| WARTHOG1-M  | WARTHOG1-M | WARTHOG2-M |                                                      |

| runs backup | runs '1803 | runs '1803 |                   Service Name                       |

|    (N2)     |    (N3)    |    (N3)    |                       (N4)                           |

|-------------|------------|------------|------------------------------------------------------|

|     E1      |     E1     |     E1     |  Computer Browser                                    |

|             |            |            |  Function Discovery Provider Host (FDPHost)          |

|             |            |            |  Function Discovery Resource Publication (FDResPub)  |

|             |            |            |  Network Connections (NetMan)                        |

|             |            |            |  UPnP Device Host (UPnPHost)                         |

|             |            |     E2     |  Peer Name Resolution Protocol (PNRPSvc)             |

|             |            |     E3     |  Peer Networking Grouping (P2PSvc)                   |

|             |            |            |  Peer Networking Identity Manager (P2PIMSvc)         |

+----------------------------------------------------------------------------------------------+

NOTES:

  N1   Service start state change tests under the left column were done after making the the

observations recorded in Table 1, with WARTHOG2-M running the '1803 update.  Change tests under the middle two columns were made when both machines were under power and running the '1803 update.

  N2   This machine runs the1013 2018.05.28 backup build listed above.  I did what I could to staunch Windows Update.

  N3   Both machines ran builds from stable backups made on 2018.05.28.  Windows Update had its vile

       way with them on 2018.07.23.

  N4   I tried to modify the start state of these services in response to recommendations given in

https://answers.microsoft.com/en-us/windows/forum/windows\_10-networking/file-explorer-may-not-detect-other-devices-or/a7509468-27ce-4e92-a19b-a6b78d311b14?auth=1

Three of the services balked.  As usual, Microsoft gave no hint about why this particular set of services should be expected to produce a miracle.

ERRORS:

  E1    The service seemed to stop and auto-restart normally until I tried to "apply" the new

settings, which produced this error message:

"The delayed auto-start flag could not be set.  Error 87:  The parameter is incorrect."

This error is particularly egregious, because Microsoft is responsible for the

"C:\WINDOWS\System32\svchost.exe -k netsvcs -p"

command (and possibly other parameters through a StartService() call) that is the source of the error!  The solution seems obvious.  I don't know what the right arguments might be, so I can't try them in the "You can specify the start parameters. . ." box at the bottom of the Service Properties window.

  E2    The service wouldn't start, got error message

"Windows could not start the Peer Name Resolution Protocol service on Local Computer. Error 0x80630203:  Unable to access a key."

Too bad the nimble wit responsible for the error message was too lazy to tell us which key was missing.

  E3    The service wouldn't start, got error message

"Windows could not start the Peer Networking Grouping service on Local Computer. 

Error 1068:  The dependency service or group failed to start." 

This error is inevitable.  The Peer Name Resolution Protocol service depends on the Peer Name Resolution Protocol service, so it can't run until error E2 is fixed.  

HARDWARE AND SOFTWARE SIMILARITIES:

Apart from the damage done by '1803, tests in Table 1 were made on identical Windows builds and nearly identical driver and application sets.  The Warthogs are desktop machines.  They use the same motherboard (Asus A88x-Pro), power supply (Seasonic 750W) and CPU (AMD A10-7850).

+-------- Table 3:  Hardware Differences ---------+

|    Machine    |   Main Hard Drive   |  Memory   |

|---------------|---------------------|-----------|

|  WARTHOG1-M   |  500gB Velociraptor |   16gB    |

|  WARTHOG2-M   |  250gB      "       |    8gB    |

+-------------------------------------------------+

Both machines have a second hard drive.  The only other differences are in each machine's their ensemble of external USB devices.  Both machine are set up for dual boot operation with Ubuntu 16.04.  I've been spending a lot of time on Ubuntu lately.

INFERENCES:

I'm not sure what to make of the results in Table 2.  The reason for the faulty performance of WARTHOG2-M under the right-center column is unclear, because WARTHOG2-M seems to run more reliably under '1803 than does WARTHOG1-M.  Table 2 may connect in some way with one or more of the the many other problems with '1803.  

WARTHOG1-M and WARTHOG2-M behave differently despite being as similar as two machines can be.  The disk and external I/O are probably blameless.  I surmise on thin evidence that some nitwit damaged the memory manager when he ripped HomeGroup out.  I could pull 8gB of memory out of WARTHOG1-M to test my conjecture.  If WARTHOG1-M began to run reliably with reduced memory, the first place to look for the problem is in a data structure.  That's Microsoft's responsibility, as are its other schoolboy howlers and insults.  I'm dropping this tail-chase.  I expect no response from Microsoft, because its 100,000+ employees lack the ability or initiative to dig into such problems.  Moreover, I have already spent too much time repairing its miserable prima donna operating system when I should be doing things that are useful and satisfying.