none
SQL 2016 sp1 SQLLocalDB versions errors with "Windows API call "RegGetValueW" returned error code: 0." RRS feed

  • Question

  • I have SQL LocalDB 2016 sp1 installed and when I execute at the command line "SQLLocalDB versions" I get the following error "Windows API call "RegGetValueW" returned error code: 0."

    I used sysinternals procmon.exe to capture any errors accessing the registry.

    The following path was not found that seems significant.  

    HKLM\SOFTWARE\Microsoft\Microsoft SQL Server Local DB\Installed Versions\13.1

    I loaded regedit and confirmed the path does not exist.  The registry does have

    HKLM\SOFTWARE\Microsoft\Microsoft SQL Server Local DB\Installed Versions\13.0

    SQL LocalDB installed with Visual Studio 2017 which is not SP1 runs without errors.

    I have tried installing service packs for SQL, uninstalling/reinstalling.  I have reset windows 2 times.  In this final test I installed Windows 10 from scratch and installed only SQL Express Advanced with Sp1.  All Windows updates are installed.

    I can't resolve this issue with reinstall or installing the updates.  

    I do not find any hits in google for this error.  The error is on a clean install of Windows 10.

    Thanks.

    Wednesday, March 22, 2017 8:37 PM

Answers

  • I got this on my machine, the problem was that under this registry key:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL13E.LOCALDB\MSSQLServer\CurrentVersion

    There is an "CurrentVersion" value that is "13.1.4001.0" and under:

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

    I had "13.0" - changing it to "13.1" fixed the error - not sure why the installed versions wasn't changed when it went to 13.1.

    Probably uninstalling/re-installing would fix it as well.


    SSDT Dev Pack - Open source (free) Visual Studio Add-in: -Extract select statements into TVF's -Create stub tSQLt tests -Change keyword casing -Name constraints -Ui for Merge statements https://the.agilesql.club/Projects/SSDT-Dev-Pack

    • Proposed as answer by Ed-Elliott Wednesday, March 29, 2017 8:59 AM
    • Marked as answer by .MARK Sunday, April 30, 2017 5:48 PM
    Wednesday, March 29, 2017 8:59 AM

All replies

  • I have tested the install of SQL 2016 RTM.  The SQLLocalDB works until the SP1 is installed.    CU5 installs and SQLLocalDB works.  Once the sp1 update is installed SQLLocalDb outputs the error.

    The output up to SP1 installed.  after sp1 the previous post error message is given.

    PS C:\Users\ssssssql> sqllocaldb versions
    Microsoft SQL Server 2016 (13.0.1601.5)
    PS C:\Users\ssssssql> sqllocaldb versions
    Microsoft SQL Server 2016 (13.0.1601.5)
    PS C:\Users\ssssssql> sqllocaldb versions
    Microsoft SQL Server 2016 (13.0.1601.5)
    PS C:\Users\ssssssql> sqllocaldb versions
    Microsoft SQL Server 2016 (13.0.1728.2)
    PS C:\Users\ssssssql> sqllocaldb versions
    Microsoft SQL Server 2016 (13.0.1728.2)
    PS C:\Users\ssssssql> sqllocaldb versions
    Microsoft SQL Server 2016 (13.0.1728.2)
    PS C:\Users\ssssssql> sqllocaldb versions
    Microsoft SQL Server 2016 (13.0.2197.0)
    PS C:\Users\ssssssql>

    Thursday, March 23, 2017 2:19 AM
  • Hi .MARK,

     

    Based on my test, I can reproduce this problem. We are currently looking into this issue and will give you an update as soon as possible.

     

    Best Regards,

    Teige


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thursday, March 23, 2017 2:36 AM
    Moderator
  • I got this on my machine, the problem was that under this registry key:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL13E.LOCALDB\MSSQLServer\CurrentVersion

    There is an "CurrentVersion" value that is "13.1.4001.0" and under:

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

    I had "13.0" - changing it to "13.1" fixed the error - not sure why the installed versions wasn't changed when it went to 13.1.

    Probably uninstalling/re-installing would fix it as well.


    SSDT Dev Pack - Open source (free) Visual Studio Add-in: -Extract select statements into TVF's -Create stub tSQLt tests -Change keyword casing -Name constraints -Ui for Merge statements https://the.agilesql.club/Projects/SSDT-Dev-Pack

    • Proposed as answer by Ed-Elliott Wednesday, March 29, 2017 8:59 AM
    • Marked as answer by .MARK Sunday, April 30, 2017 5:48 PM
    Wednesday, March 29, 2017 8:59 AM
  • Hi Ed,

    I thought about changing the registry.   I may give that a try.  I had hoped Microsoft would have been able to provide a fix or solution by now.  

    Uninstall and re-install does not fix the registry problem.  

    -Mark

    Wednesday, March 29, 2017 4:22 PM
  • Hi Teige,

    Would you have any updates on a solution for the error?  I have SQL code that will not execute unless the LocalDB is upgraded to SP1.

    -Mark

    Wednesday, March 29, 2017 4:23 PM
  • Hi .MARK,

    I have reported this problem to the SSMS product team last week, they are handling this problem, they will give a solution and fix in a short time.

    If this fix has been released or some solution delivered, I will give you an update.

    Best Regards,
    Teige


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thursday, March 30, 2017 1:20 AM
    Moderator
  • It is particularly annoying because to start a localdb instance you need the full 13.0/13.1 and I have scripts that started local db and something has uninstalled 13.0 and installed 13.1 breaking my scripts

    SSDT Dev Pack - Open source (free) Visual Studio Add-in: -Extract select statements into TVF's -Create stub tSQLt tests -Change keyword casing -Name constraints -Ui for Merge statements https://the.agilesql.club/Projects/SSDT-Dev-Pack

    Thursday, March 30, 2017 7:41 AM
  • I have received an email from the [Forums] to remind me to please remember to click "Mark as answer" on the post if your question was answered appropriately.

    This post is not to discredit Ed-Elliott's being the first to publish the work around.  It does not discredit his knowledge or ability to assert the workaround as a solution.

    It is a post to address how it would not be fair to identify it as an answer compared to having Microsoft address and fix the problem with a Cumulative Update.   The reasoning is due cost the workaround for end users and that it is still a guess that appears to work.

    Teige Gao has followed up that he has submitted a bug report.  

    A user Bardnet has contributed to the thread but at this time I can't find.  I have it in email.  He indicated a mix of Windows 7, registry editing, and installing the latest version of SSMS 2017.  I was still thinking 2016 was the latest and learned there is a 2017 SSMS available.  Some of it is likely anecdotal but I will be checking out SSMS 2017.  

    What I have found it is not easy to find the individual SQLLocalDB.msi but I assume there have not been any updates to the 2016 due to the 2017 that is soon to be released.

    The thread remains not answered.  

    1. The problem is found at the installation of the product and the installation of Service Pack/Cumulative Updates.  
    2. The latest Service Pack 1 cumulative update is sill "March 20, 2017)
    3. A Cumulative Update does not exist to address the problem.

    Why is the work around not a solution.

    • Every end user who encounters this problem will have to search the internet for a solution to the error.
    • Every installation of SQL LoalDB will require the end user to apply this registry hack.
    • It is not known if the altering the registry will not cause a problem when the next Service Pack or Service Pack Cumulative Update is released.  It cannot be assumed the next update will account for the hack to exist and be able to handle the situation.  
    • It is not a solution to the scope of how SQL LocalDB is used.

    It is not a solution for some if the workaround has to be applied at scale and/or maintain uniformity 

    • If using SQL LocalDB in a product that is installed at customer locations.  Adding extra development cost to installation and maintenance to the product delivery.
    • DevOps making scripts to alter the registry state.
    • A single user making the change is insignificant.  Multiply this by every single user who encounters this error.  That is a different scale.  Their job is to get things done.  Instead an unexpected error is found, may take time to debug locally or search the internet for potential answers.  Learn there is a workaround.  Modify registry.  Make sure the registry changes continue to work with their product.  The developer may then have to address the problem with team to address how this problem is going to be solved with the release of their product.

    In closing the registry hack works but it is not a cost effective solution for end users.  It will likely let you continue past the error.  Unfortunately you will have had to figure it out on your own or find the solution online.

    This is not how I manage my software or customers.  The thread engine has an algorithm to make sure if there is an answer to have them marked to assist others in finding threads with answers.

    If finding this workaround is harder to find because it does not have it marked as an answer then I should address this by marking it as an answer.  But clearly not the answer.  It has been found to be a functional work around that has unknown side effects.  Ed-Elliot may like a few points for forum contribution.

    -Mark

    Sunday, April 30, 2017 5:08 PM
  • I am going to mark Ed-Elliott's post as answer and I hope he would agree that it is a workaround with unknown side effects.

    Ed-Elliott was the first to actually follow through with the idea to perform the registry change, test, and provide results.  I think this will allow the forum to provide the thread to other users seeking for the same answer.

    It is a functional workaround and I think Ed-Elliot has indicated it may not resolve all situations.

    What I have started is another thread to allow an actual answer to be marked.  The thread is found here.

    -Mark

    Sunday, April 30, 2017 5:48 PM
  • Is there an update about this issue?

    I changed the registry entry and after that, the local db api returns the version without any errors
    But when I try to connect to the instance with sql management studio it still failes.

    Could somebody link the bug report to microsoft in this thread, because I can not find any report on this problem.

    Wednesday, June 14, 2017 9:26 AM
  • Worked for me.

    Many many thanks Ed-Elliot.

    I hope someone has warned Microsoft about this BUG of MSI file... I've used the last .msi file taken 2 hours ago from MS website ;)


    Davide Dolla

    Tuesday, July 11, 2017 3:01 PM
  • Find '13.1.4001.0' and replace for '13.0.4001.0' in registers!  
    Monday, July 31, 2017 10:52 PM
  • This work around works for me too (win 10 Build 1709 x64 Fr).

    Bug still not fixed in november.

    Tuesday, October 31, 2017 9:38 PM
  • Something else to add to this I can reproduce this using a silent install of SQL Local DB.

    SSDT Dev Pack - Open source (free) Visual Studio Add-in: -Extract select statements into TVF's -Create stub tSQLt tests -Change keyword casing -Name constraints -Ui for Merge statements https://the.agilesql.club/Projects/SSDT-Dev-Pack

    Tuesday, November 21, 2017 12:55 PM
  • I would like to add that I a clean install of the Windows 10 Version 1703 with Visual Studios 2017 enterprise installed and this error was reproduced.  By changing the registry from 13.0 to 13.1 everything was fixed. But for a complete clean install of OS and Visual Studios to not having SQL working was a headache to figure out.  Especially seeing this bug has persisted for quite a while.
    Wednesday, November 29, 2017 6:56 PM
  • Worked well for me as well Thanks !

    Wednesday, January 24, 2018 5:33 PM
  • I just went through this nightmare, hopefully this helps...

    My theory: 

    • Versioning and binary conflict with the default instances internally.
    • Resolution needed to re-set some internal flags (could be registry)
    • This seems cleaner than regexing values
    • "Should" be something sqllocaldb.exe could detect and recommend reset
    • I have no idea what this did internally, but automagically solved my issues

    My Fix:

    1. sqllocaldb d MSSQLLocalDB
    2. sqllocaldb c MSSQLLocalDB

    Friday, April 6, 2018 3:31 PM
  • NB: d = delete in step 1. 

    Backup any database on MSSQLLocalDB first.

    Thursday, October 18, 2018 4:04 PM
  • I found a reported bug here: https://feedback.azure.com/forums/908035-sql-server/suggestions/34222855--windows-api-call-reggetvaluew-error-when-displ
    Wednesday, January 9, 2019 12:11 PM
  • A few interesting things:

    1. I have SQL Server 2016 Express SP2 LocalDB and it still reports as being version 13.0.x, not 13.1.x:

      SELECT @@VERSION;
      Microsoft SQL Server 2016 (SP2-CU3) (KB4458871) - 13.0.5216.0 (X64)

      And yes, it shows as this same version number in registry key 
      HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL13E.LOCALDB\MSSQLServer\CurrentVersion
       
    2. I just tested again (I haven't for a while), and noticed that the "v" option is now working correctly for all 4 installed versions:

      Microsoft SQL Server 2012 (11.0.7462.6)
      Microsoft SQL Server 2014 (12.0.6024.0)
      Microsoft SQL Server 2016 (13.0.5026.0)
      Microsoft SQL Server 2017 (14.0.3045.24)

    3. In my testing I noticed that some new things are broken in only the 2016 version of sqllocaldb.exe, namely getting output for the "-?" option, error messages, and output for the "i" option (when passing in a valid instance name). But "i" by itself is just fine. I have reported this in the following ticket:

      SQLLocalDB Utility 2016 returns "FormatMessageW failed. Error code returned: 15100"


    Wednesday, January 9, 2019 9:22 PM
  • Solved my problem, thanks.
    Sunday, July 14, 2019 10:07 AM