Must my service name have the name of the executable in which it's contained?

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.