By default, Windows services start in the sytem32 directory (usually C:\WINDOWS\system32).

Is there a way to set up a different working directory? I am thinking of some registry parameter beneath HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SomeService.

So - can this be done?

  • 3
    @Tomalak: Is it a service you wrote? You can do it through code, but I don't think there is a way through the service settings.
    – MattB
    Feb 18, 2010 at 14:49
  • No, it isn't a service I wrote. I was hoping some little-known registry setting here.
    – Tomalak
    Feb 18, 2010 at 15:39
  • What is the purpose of doing it?
    – user35115
    Feb 18, 2010 at 18:48
  • @user35115: Well, to be honest… While tracking down an unrelated problem with procmon, I noticed that a certain I/O-heavy service (a full text indexer) consistently checks for its own files in the wrong locations (pretty dumb). It starts at system32, tries a few more locations, and eventually its own directory. I figured when it would run in its own directory right away, it would do less unnecessary file checks. Not that it would not work currently, yet it made me wonder if there was room for improvement.
    – Tomalak
    Feb 18, 2010 at 19:53
  • 1
    @user35115, To avoid having to mass change configuration settings of a certain app (say Apache, etc), which are all relative to the working directory.
    – Pacerier
    Apr 11, 2016 at 18:07

4 Answers 4


You could use DLL injection to call SetCurrentDirectory after the process has already launched. This would require you to build an injector application, plus the DLL to inject. Some tutorials exist; probably the two best ones I've found are:

You'll need a decent amount of C++ programming background (and a working build environment) to get through that.

However, this assumes that the service is looking at the current directory. Another possibility is that it's using %path%. You say that it "starts at system32, tries a few more locations, and eventually its own directory", so this seems more likely to me.

Compare the directories you see in procmon with your %path%. If they're the same, consider modifying either the SYSTEM %path% or the %path% of the user running the service, so that the directory you want it to search is first.

I believe Fred is right, though -- you're unlikely to see any significant performance benefit by doing any of this, unless it's happening very frequently. Simple file open operations are not particularly expensive, especially if it's a local path and the file doesn't actually exist.

  • The system PATH environment variable was the first thing that came to mind for me. Inserting the service's path at the start of the PATH variable will however have a negative effect on the performance of just about every other application so I wouldn't advise that. Feb 25, 2010 at 21:21
  • I don't have hard numbers to back this up either way, but my intuition tells me that no practical performance gain or loss would occur from modifying the path. This is a fairly common scenario; nobody blames, say, the Windows Support Tools, or SQL Server, for negatively impacting system performance when it modifies the path during installation. This isn't the first time I've seen someone look at procmon and go "omg, look at all those file accesses!", not realizing that it's typical for most applications.
    – fission
    Feb 25, 2010 at 23:15
  • +1 for creativity. :-) I fully understand that these file operations do not impact performance measurably, so I'm not going to actually bother writing a DLL injection solution. Modifying %PATH% for the user account the service runs under is a decent idea, though.
    – Tomalak
    Feb 26, 2010 at 9:56
  • 1
    Creating a special user to run this service only and modifying the %PATH% for this user sounds as a very good way to go. +1
    – Sunny
    Feb 26, 2010 at 21:37
  • @fission: Yes, it does mean I accept your answer. ;) It's not what I had hoped for, but it is as close as it gets, I guess.
    – Tomalak
    Mar 1, 2010 at 10:15

Do this within the Service main function:

  • Make a call to GetModuleFilename. It will retrieve the module (the exe) filename including path, in the form C:\path\to\exe\your_service.exe.
  • Use string manipulations (maybe using std::string function find_last_of()), to find the last backslash. Strip/trim the string from there on to obtain the path to your module and therefore the directory of your exe.
  • Make a call to the function SetCurrentDirectory and voila!
  • 1
    do not forget to pass null to the HMODULE parameter in the GetModuleFilename function call :)
    – uprightech
    Feb 8, 2011 at 8:54

Like MattB, I don't know of any way to change the service's working directory w/o access to the source code. For this specific scenario, it's likely that the extra directory checks don't impose that much unnecessary disk activity relative to the amount of i/o required for the full text indexing operation. Even if you could optimize them away, the full text index will be disk intensive by the nature of the beast.


Add an "AppDirectory" string value to the Parameters Key and set the value to your desired working directory.

  • Hm. Just tested, does not seem to work (On Windows 7, used REG_EXPAND_SZ data type). Can you re-confirm this actually works for you, please?
    – Tomalak
    Nov 22, 2010 at 18:06
  • This works when using srvany. Not sure about normal services. Mar 2, 2011 at 2:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .