New Windows Service installed, fails to start: "System error 2 ... system cannot find the file specified"

Ho Ho Ho picture Ho Ho Ho · Nov 5, 2013 · Viewed 90.4k times · Source

I have installed several other custom .Net windows services successfully. A new one I had recently written was very similar to the others and while it installed without error - on starting it with the service controller it failed to start with the error dialog: System error 2 ... system cannot find the file specified.

After time and consternation, the only thing I could think of that was significantly different about this service was that the path and executable name were at least 10 characters longer than any of my other services. On shortening both the path and .exe name and re-installing, the service ran fine: no error! I can only assume my previous path or service or .exe name was too long.

Also, It would be pertinent to mention I had used some borrowed "service driver" code built in to my exe to handle the install/uninstall of the service to the service controller via win API calls. It could be a character limit was hidden within that service driver module.

I could not find any windows related docs to confirm if there is a system bound character limit to a path or service name that I had exceeded. I will dig in to the service driver when time permits and see if that turns out to be the problem. Meanwhile I welcome any insights.

Answer

Ho Ho Ho picture Ho Ho Ho · Nov 7, 2013

I experimented with some test services and found it was not the length of any property that caused my problem (“System error 2 ... system cannot find the file specified”) to begin with. My built in service installer uses three properties: ServiceName, ServiceTitle, ServiceDescription. On installing, I found that it writes full service path to the registry, but it doesn’t just take the actual exe (assembly) name, it uses the ServiceName property to build the path! My issue was that the ServiceName and assembly name didn’t match, hence file not found. I used a powershell registry query to expose the path and finally noticed the mismatch from there. When I first noticed the problem I had not noticed that when I shortened the service name from whatever it was – that I just used the assembly name without the .exe and that is what actually fixed it, not simply shortening it.