72

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.

Ho Ho Ho
  • 1,429
  • 1
  • 10
  • 10
  • What was the total length of path before you shortened it. Also did your path have any unusual characters? If you could also provide the initial path used that would also assist anyone trying to answer your query – Chelseawillrecover Nov 06 '13 at 06:03
  • The working service now has an executable name length of 17. Unfortunately I didn't save the old one but it was closer to 30 or 35 characters. The service name (service controller name) was the same (without the .exe extension) and the service title showing in the service controller was around 40-50 chars. Total local full path to the exe had something near 100 characters and now that it is working the path is 67 characters. I could write some test projects and vary the length to check for failure. Mostly just wondering if there is some known documented limit. – Ho Ho Ho Nov 06 '13 at 14:19
  • Its difficult to assist without knowing the exact path length or how the setup was initially. Just for your information, this type of question should be posted on [Server Fault](http://serverfault.com/) – Chelseawillrecover Nov 06 '13 at 17:25

10 Answers10

68

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 a 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 the file was 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 – I just used the assembly name without the .exe and that is what actually fixed it, not simply shortening it.

SeReGa
  • 1,219
  • 2
  • 11
  • 32
Ho Ho Ho
  • 1,429
  • 1
  • 10
  • 10
  • 3
    What was the powershell registry query? – Robert Penridge Jul 29 '14 at 14:56
  • 41
    Path can be found at `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\YourServiceName\ImagePath`. – Baz Guvenkaya Sep 10 '14 at 06:23
  • bravo sir. In my case, I set the command prompt to the EXE folder, so, the ImagePath had the .exe but did not have any path information =( – Mike_Matthews_II Jun 30 '15 at 15:54
  • i had the exact same problem, 10x. – eran otzap Jan 03 '16 at 16:47
  • 1
    I'm using the sc command to install mine and had this same problem. After reading over all the info, all I had to do was provide the fully-qualified path of the EXE and it now starts right up! – Scott Fraley Jul 05 '16 at 19:47
  • The problem I had was that didn't provide the full path to the assembly file. I ran the command prompt as administrator, the cd to the path to the assembly file, then I just provide the assembly name in binpath. – Ali Majed HA Apr 20 '23 at 18:39
17

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

jasttim
  • 723
  • 8
  • 19
10

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.

  1. 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"

  1. Also, verify that the path is correct. Because, I once installed with the wrong path and it got successfully installed, but when I tried to start it, I got the same error.
Xpleria
  • 5,472
  • 5
  • 52
  • 66
  • Another option is to change the "ImagePath" property in the registry editor to the full path. The key of the service can be found in Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\{your_service}. Change the ImagePath value to the full path and it works – Stan Nov 28 '21 at 10:43
1

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.
AgathoSAreS
  • 378
  • 3
  • 7
1

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!

Zac
  • 4,510
  • 3
  • 36
  • 44
  • 1
    Thanks Zac, I was trying to set path in cmd opened as administrator and it did not work. But when I logged back to server as administrator I was able to create and start the service – Andrewski Feb 02 '21 at 18:08
1

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.

desperat0
  • 56
  • 6
  • The bad status value is not the problem by itself. The problem is that your driver doesn't exit clearly on error. I guess you hold some resources and this blocks the `sys` file, so it can't be accessed. In my case for example, I forgot to unregister callout on Device unload. This causes blockage of `sys` file so it can't be started again. – Mike Keskinov Sep 22 '21 at 12:43
1

Another possible reason that the sys file is blocked. If your driver doesn't exit clearly (for example, you forget to clean up Device, Callouts etc), the sys file may be blocked. To check that you can try removing sys file when service is not working. Normally you should be able to do so. If not, the driver may hold some resources and in turn blocks the sys file.

If your service indeed blocks the file, you should set the service start to Manual (check HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\YourServiceName\Start flag: 0 - start on boot, 3 - manual) and restart your device. This will free up the sys file and you can try again until you fix your clean-up flow.

Mike Keskinov
  • 11,614
  • 6
  • 59
  • 87
0

Well, there is a path limit but not sure the char limit at this movement. Also the the file name should match exe name. sc create MyWinService BinPath=C:\System32\Queue\MyWinService.exe

Raghavendra Dinavahi
  • 31
  • 6
0

For me the issue was that I was deploying from Azure Dev Ops. A command line script in the Release definition runs it on the Agent machine not the destination machine.

Specifying the server to register the service on using the server name parameter i.e. sc \\TargetServer ... fixed the problem.

nh43de
  • 813
  • 11
  • 11
0

For me, the problem was using single quotation mark. When using this:

sc create 'testserv' binPath= 'C:\testsrv.exe'

Looking at the properties of the service path to executable, that path was:

'C:\testsrv.exe'

which means that single quotation mark was part of the path. Of course, that path does not exist.

Solution was simple - I've used double quotation marks instead of single and everything was fine. System found the file immediately.

FrenkyB
  • 6,625
  • 14
  • 67
  • 114