It must be psychic debugging week ’round here. I received the following email on an internal mailing list earlier today:
Regarding windows service with ServiceType “SERVICE_WIN32_SHARE_PROCESS”, is there a restriction on the service name such that it can only take the same name as the service executable? I can install a service with share process under different names, but the service cannot be started. If I try to start it manually, it gives the following error, “Error 1083: The executable program that this service is configured to run in does not implement the service.” If I set the service name to be the same as the executable, it will install and start properly.
My psychic response was:
What names are you providing in your service call dispatch table?
In this case, the good news is that the error code mostly gives a reasonable hint as to where to start looking.
Essentially my thought processes were: “Hmm. I wonder where the service controller gets the list of services that are implemented in the process? If I remember correctly, it gets it from the service dispatch table passed into the StartServiceCtrlDispatcher API. Maybe I’ll look there…”
That then led me to the SERVICE_TABLE_ENTRY structure passed into StartServiceCtrlDispatcher, which contains an lpServiceName field. Aha, I knew I was close. Then I saw the comment that says that the lpServiceName field is ignored if the service is a SERVICE_WIN32_OWN_PROCESS (which means that many services probably don’t even bother setting the field to anything other than the empty string), and I knew I’d figured it out.
I’m not surprised that this caused problems, because it’s not at all obvious that this random field in a data structure would change meaning depending on a flag in the service’s configuration.