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 -
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.
In my case, I opened the Command Promt and navigated to the exe and installed it from there. So I did not enter the full path. Once I used the full path, it worked.
So, you need to either install the service with the full path or add the exe file's path to PATH in system environment variables.
SC CREATE "Service-Name" binpath="D:\full-path-to-service\service.exe"
or add D:\full-path-to-service\
to PATH variable and use
SC CREATE "Service-Name" binpath="service.exe"
I had same issue, nothing did solve this error, then I resolved by not using the c:\Windows\System32
path to store the service executable!
I had a similar issue with a service, where I was getting the same error.
I went to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\YourServiceName\ImagePath
My 'ImagePath' was set to a virtual drive called "W:\" that exists on "C:\".
I replaced this path with the actual file location on the C:\ drive and then the service started successfully
In my case, the problem was caused by a mistake in the service start routine. DriverEntry (in my case it was a kernel-mode driver) returns a bad status value. I think this situation applies to user mode too.
My Problem was, creating the Service with Powershell command added brakets like: <C:\Path\To\Service\Service.exe>
to the registry.
Replacing < and > with " fixed it for me.