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?
0 Answers