locked
Failed to start debugger - Data is Null. SQL Server 2012. RRS feed

  • Question

  • Problem:  Try to start sql debugger in SSMS 2012 against a local instance of sql server and get the message:  Failed to start debugger – Data is Null.  This data or property cannot be called on Null Values. (SystemData).
    The same error occurs from other tools trying to execute the sql debugger … Visual Studio 2012 and a third party toolset.
    >>
    Environment: Windows 8 Professional 64 bit   6.2.9200 , SQL Server 2012 Developer 64 bit 11.0.3000 (which is SP1), Visual Studio 2012 Ultimate, .net framework 4.0.30319.18010
    >>
    Tried to solve by: The PC has all  the latest Windows updates. Use network logon account which is an Administrator on the PC and has sysadmin privilege in sql server. Tried using a local windows administrator account and sql server login with  sysadmin privilege. Connected to sql using both ‘ local and  the ‘explicit’ instance name. ‘Repaired’ the sql server installation. Uninstalled/re-installed sql server installation. Installed SSDT 11.1.30618.1/Data Tier App Framework 11.1.2861.
    Monday, July 22, 2013 6:41 PM

Answers

  • This is how it was resolved.

    ==========================

    •   Verified that ssdebugps.dll is present in ‘C:\Program Files\Common Files\Microsoft Shared\SQL Debugging’
    •   Tried replacing the dll file from a working environment of the same version
    •   Reproduced the issue and collected Procmon trace
    •   Verified Windows authentication account used to connect to SSMS has sysadmin server role and even SA account was failing
    •   Found Debugger worked when we changed the SQL Server service account  to a Local administrator account and then restarted sql server.   This confirmed that there was permission issue with NT Service\MSSQLSERVER account that was being used.
    •   NT Service are service SID and not accounts hence we have to explicitly provide permissions to NT Service on the required locations
    •   On Procmon trace we checked that there was access denied message for a registry key hence we went to registry editor and right clicked on HKCR\Wow6432Node\Interface\{87BC18DC-C8B3-11D5-AE96-00B0D0E93CC1} > Permissions > Advanced > Add > Changed the Location to  root server > Then added NT Service\MSSQLSERVER account
    •   Then highlighted  the account that we added in the ‘Permission entries’ list > Checked the option ‘Replace all child object permissions with inheritable permissions from this object.’ > Apply > OK
    •   Similarly we gave permission on {87BC18DB-C8B3-11D5-AE96-00B0D0E93CC1} since it was accessed by ProxyStubClsid32 folder under above registry.

    NOTE: There were about 5 keys in a row with ProxyStubClsid32 that had to have permissions changed to get full functionality of debugger to work.

    •   We were now able to successfully debug with no error messages
    • Proposed as answer by Evgeniy Polyakov Thursday, July 30, 2020 6:28 PM
    • Marked as answer by Naomi N Thursday, July 30, 2020 6:41 PM
    Thursday, August 1, 2013 12:31 PM

All replies

  • Hello,

    Can you please try to install the latest update for SQL Server 2012 Service Pack 1? You can get the update information from the following KB article:
    http://support.microsoft.com/kb/2772858/en-us

    Reference:http://technet.microsoft.com/en-us/library/cc646024.aspx

    If the issue persists, please let me know.

    Regards,
    Fanny Liu

    If you have any feedback on our support, please click  here.


    Fanny Liu
    TechNet Community Support

    Wednesday, July 24, 2013 1:53 AM
  • Fanny,

    I could be wrong, but my understanding with Cumulative Updates is that they should not be applied unless you are experiencing an issue identified in the CU?  I didn't see any fixes for this debugger problem?  I have opened an incident with Microsoft support... and will update this later with resolution.

    Thanks for responding.

    Tom

    Thursday, July 25, 2013 3:03 PM
  • This is how it was resolved.

    ==========================

    •   Verified that ssdebugps.dll is present in ‘C:\Program Files\Common Files\Microsoft Shared\SQL Debugging’
    •   Tried replacing the dll file from a working environment of the same version
    •   Reproduced the issue and collected Procmon trace
    •   Verified Windows authentication account used to connect to SSMS has sysadmin server role and even SA account was failing
    •   Found Debugger worked when we changed the SQL Server service account  to a Local administrator account and then restarted sql server.   This confirmed that there was permission issue with NT Service\MSSQLSERVER account that was being used.
    •   NT Service are service SID and not accounts hence we have to explicitly provide permissions to NT Service on the required locations
    •   On Procmon trace we checked that there was access denied message for a registry key hence we went to registry editor and right clicked on HKCR\Wow6432Node\Interface\{87BC18DC-C8B3-11D5-AE96-00B0D0E93CC1} > Permissions > Advanced > Add > Changed the Location to  root server > Then added NT Service\MSSQLSERVER account
    •   Then highlighted  the account that we added in the ‘Permission entries’ list > Checked the option ‘Replace all child object permissions with inheritable permissions from this object.’ > Apply > OK
    •   Similarly we gave permission on {87BC18DB-C8B3-11D5-AE96-00B0D0E93CC1} since it was accessed by ProxyStubClsid32 folder under above registry.

    NOTE: There were about 5 keys in a row with ProxyStubClsid32 that had to have permissions changed to get full functionality of debugger to work.

    •   We were now able to successfully debug with no error messages
    • Proposed as answer by Evgeniy Polyakov Thursday, July 30, 2020 6:28 PM
    • Marked as answer by Naomi N Thursday, July 30, 2020 6:41 PM
    Thursday, August 1, 2013 12:31 PM
  • Great advices!

    For me scenario was the following:

    1. We installed Sql Server 2012

    2. Then we installed Sql Server 2016

    3. Then we deleted Sql Server 2012.

    With these steps library ssdebugps.dll wasn't registered at the server at all. The key {87BC18DB-C8B3-11D5-AE96-00B0D0E93CC1} was missing.

    To resolve the issue I registered ssdebugps.dll with regsvr32 utility. In my scenario library was at C:\Program Files\Common Files\microsoft shared\SQL Debugging\130

    Thursday, July 30, 2020 6:37 PM