0

I’m currently trying to debug a problem with Windows Deployment Services, where when it is set to ask the DHCP server for a multicast address range, the WDS service will not start because it gets an “Access Denied” response from DHCP.

I can’t find any documentation to explain what’s going on. But I am familiar with using the Windows SysInternals Process Monitor to examine what is happening with the various running processes to figure out where the problem is.

Though the way Microsoft runs services makes this really hard to diagnose. Rather than directly running each system service in its own separate process, instead Microsoft runs all of them as a surrogate of the service host.

And then also rather than each service getting its own service host process ID, in some cases a single service host is running multiple system services under it.

So using both the Task Manager and Process Monitor, it’s really hard to tell which service host is running WDS, and it might be grouped together with other unrelated services under the same process ID.

(The logic of when process sharing will occur under a single service host process ID is not obvious.)

I don’t understand why Microsoft decided to indirectly run services like this, though it a very old operating system design decision that goes back to at least Windows NT.

Perhaps the Microsoft engineers don’t even know anymore, and it’s just a familiar but obsolete/unnecessary system design they are carrying on with, but which they don’t really need to be doing.

The service host only seems to make the functionality of the operating system more obscure and difficult to debug when things go wrong.

Is the obfuscation intentional for some reason, perhaps to hide the functioning of their anti-pirating licensing mechanisms?

  • From my understanding, it used to be a way to attempt to save memory. All of the services are housed in DLL files (which can't be directly run), and svchost would be used to run related groups of services that needed the same DLL files - thus, multiple copies of the library wouldn't need to be held in RAM. I believe one of the recent Windows 10 updates changed this behavior on systems with 4GB or more RAM, where now every service gets its own host process. – Rob Pearson Sep 07 '19 at 05:12
  • 1
    In Task Manager, the "Service" tab makes it easier to identify the process that hosts it as it has the PID. As per the comment by @RobPearson: In the Creators Update, if the amount of physical memory is higher than 3.5 GB (3584 MB), most built-in Svchost-ed services host a single service in each Svchost process. So more processes but removes the likelihood of one service affecting another (either because of some instability or security issues). I believe it was added to Windows in the first place to save memory as the overhead of a process was perhaps something that could be optimized. – HelpingHand Sep 07 '19 at 21:26

0 Answers0