I'm writing a plugin for Cake Build tool where I need to start a LocalDB instance. But this code will be executed on different machines and LocalDB can be installed in different folders depending on the version of SQL Server installed in the build machine.

I know at least 3 paths possible:

c:\Program Files\Microsoft SQL Server\130\Tools\Binn\SqlLocalDB.exe
C:\Program Files\Microsoft SQL Server\120\Tools\Binn\SqlLocalDB.exe
C:\Program Files\Microsoft SQL Server\110\Tools\Binn\SqlLocalDB.exe

Though I'm not absolutely sure about the last path. And I can't install SQL Server 2016 on my machine, so can't confirm if

c:\Program Files\Microsoft SQL Server\140\Tools\Binn\SqlLocalDB.exe

would the correct guess.

I can iterate through a list of options and pick the one that works.

Are there any other possible folder where SqlLocalDb.exe can be installed? Or is there a registry value somewhere that I can check?

2 Answers 2


There seems to be two Registry paths that contain the installation directory / folder:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server Local DB\Installed Versions

    The Installed Versions Key has sub-Keys for the SQL Server version in the form of 11.0, 12.0, and so on. Each version number Key has an InstanceAPIPath Value of type "REG_SZ" which contains Data such as:

    C:\Program Files\Microsoft SQL Server\120\LocalDB\Binn\SqlUserInstance.dll


  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server

    The Microsoft SQL Server Key has sub-Keys for the LocalDB instances in the form of MSSQL11E.LOCALDB, MSSQL12E.LOCALDB, and so on. Each instance Key has a sub-Key for Setup, which in turn has a SQLBinRoot Value of type "REG_SZ" which contains Data such as:

    C:\Program Files\Microsoft SQL Server\120\LocalDB\Binn\

P.S. If you have a folder for 130 then you do have SQL Server 2016 (or some component of it) installed since that is the version number for SQL Server 2016. 110 is for SQL Server 2012, 120 is for SQL Server 2014, and I don't believe a value of 140 currently exists (which, of course, would certainly make it very hard to confirm ;-).

Regarding Ramveer's answer: While it is true that you can have Registry entries for applications that are no longer installed, starting with the Registry is still more reliable than executing SqlLocalDB.exe as the containing folder is not required to be in the PATH environment variable in order to work, but the registry entries most likely are required (i.e. you aren't going to have LocalDB installed and not have the Registry entries). But yes, it is still a good idea to test each reported installation folder to make sure that it is still there. You can do this in DOS / cmd script by running:

reg query "HKLM\SOFTWARE\Microsoft\Microsoft SQL Server Local DB"


HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server Local DB\Installed Versions\11.0
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server Local DB\Installed Versions\12.0
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server Local DB\Installed Versions\13.0

You can use the DOS FOR command to iterate over that output, capturing the version number (just the integer portion of 11, 12, etc and not the decimal portion of .0 that follows). Then, for each version number, check its registry Key to get the install folder (just replace the "12" in the path below with the extracted version number):

reg query "HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL12E.LOCALDB\Setup" /v "SQLBinRoot"

which returns:

    SQLBinRoot    REG_SZ    C:\Program Files\Microsoft SQL Server\120\LocalDB\Binn\

You can again use the DOS FOR command to capture that output and extract the path. Then, you can check for its existence and if it can actually run by doing the following:

REM You wouldn't need the following SET if extracting with the FOR command
SET CheckPath="C:\Program Files\Microsoft SQL Server\120\LocalDB\Binn\sqlservr.exe"

IF EXIST %CheckPath% ( %CheckPath% -v ) ELSE ( ECHO Not really here )
  • and re SqlServer 2016 - I've managed to install pre-release of v2016 on Windows7, but could not uninistall/reinstall full version of it when the release came out because it requires Windows8 minimum. That explains why I have 130
    – trailmax
    Commented Oct 20, 2016 at 16:21

Checking from the registry may not work all the time becasue if user uninstall the localDb then registry entries may still exist.

Here is the function I am using to identify the localDB installation from command line -

internal static bool IsLocalDBInstalled()
    // Start the child process.
    Process p = new Process();
    // Redirect the output stream of the child process.
    p.StartInfo.UseShellExecute = false;
    p.StartInfo.RedirectStandardOutput = true;
    p.StartInfo.FileName = "cmd.exe";
    p.StartInfo.Arguments = "/C sqllocaldb info";
    p.StartInfo.CreateNoWindow = true;
    p.StartInfo.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden;
    // Do not wait for the child process to exit before
    // reading to the end of its redirected stream.
    // p.WaitForExit();
    // Read the output stream first and then wait.
    string sOutput = p.StandardOutput.ReadToEnd();

    //If LocalDb is not installed then it will return that 'sqllocaldb' is not recognized as an internal or external command operable program or batch file.
    if (sOutput == null || sOutput.Trim().Length == 0 || sOutput.Contains("not recognized"))
        return false;
    if (sOutput.ToLower().Contains("mssqllocaldb")) //This is a defualt instance in local DB
        return true;
    return false;
  • 1
    This is good, yet relies on the path to sqlLocalDb to be in %PATH% and this is more common to be messed about by user
    – trailmax
    Commented May 6, 2017 at 18:55
  • @trailmax and Ramveer: yes, interesting and a good step 2 in the process as the path(s) noted in the Registry should be validated rather than merely assumed to point to valid installations. Still, you would need to start with the Registry, especially if you need to know if more than 1 version exists. I have updated my answer to account for this verification. Also, in SQL Server 2012 Express Local DB, the default instance name was v11.0, not MSSQLLocalDB. Commented May 8, 2017 at 19:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.