none
Unable to start T-SQL Debugging. Could not attach to SQL Server process on

    Question

  • Please help!  I cannot debug CLR procs remotely.  Whenever I try to start debugging in VS2005 I get the error:  Unable to start T-SQL Debugging. Could not attach to SQL Server process on ....  I have clr enabled set to 1 and I have Allow SQL\CLR Debugging set on.  But I continue to get this error.  Any help would be greatly appreciated.

    Thanks!

    GN

    Thursday, July 27, 2006 6:13 PM

Answers

  • Sorry I missed another key piece of information to get this to work. The SQL Server Service also has to run as the same user.

     

     

    SQL Scenario: One or Both machines is in a workgroup

     

    Create the same local user on both machine e.g. SQLUser, ensuring that they have the same password.

    Then also set the SQL Server Service to run as SQLUser

     

    Hope this helps. I have tried it our and it works for SQL2K and SQL2005.

     

    Thanks

     

    Richard Cook

    Visual Studio Debugger QA

    Tuesday, August 01, 2006 9:15 PM

All replies

  • Hi,

    Can you answer following few questions that would help in understanding the problem:

    Is msvsmon running on the server (SQL Server machine).

    Are you able to debug locally?

    Are you able to perform T-SQL debugging remotely.

    If all this is true, have a look at http://msdn2.microsoft.com/en-us/library/s7ahaxtd.aspx to ensure that you have the permissions and your setup is fine.

    If that doesnt help, could you have a look at the event log and error log and see if you see any details on the error.

    Thanks,

    -Vineet.

    Thursday, July 27, 2006 8:39 PM
  • In response to your questions:

    Is msvsmon running on the server (SQL Server machine). ---- Yes

    Are you able to debug locally?  -- Yes

    Are you able to perform T-SQL debugging remotely. -- No.

    I have done some more configuration and now get the following error:

    "Unable to start T-SQL Debugging. Could not connect to computer 'wcubpdev'. Logon failure: unknown user name or bad password."

    I get this same error for T-SQL debugging remotely and SQL CLR debugging remotely.  My userid and password is the same on my local machine, my domain account, and my sql server account.  I suspect that the problem has to do with the fact that my local machine is in a domain but the sql server machine that I am trying to debug remotely is not in the domain, it is part of a workgroup.  Because of this I can't add my domain\userid to sql server as a login.  Is there any way to debug remotely with this configuration?

    Thanks!

    GN

     

    Friday, July 28, 2006 3:02 PM
  • i take it that you cannot use sql authentication in your project's database reference(s)?
    Friday, July 28, 2006 8:11 PM
  • Hello,

    Since one machine is on a domain and the other is in a workgroup. Try creating the same user on both machines with the same password. If both machines have an identical user/password combination it should work.

    e.g. <LocalMachine>\SQLUser       MyPassword1

    Then try debugging using the new user credentials on both machines.

    Also as a side note, ensure the firewall's on both machines are configure correctly. A simple way to do this is to manually run MSVSMON once on both machine. If the firewall is blocking ports that it requires, then it will offer to configure the firewall for you.

    Thanks

    Richard Cook

    Visual Studio Debugger QA

    Friday, July 28, 2006 8:33 PM
  • I am using sql authentication in my projects database reference.
    Monday, July 31, 2006 2:49 PM
  • I have created the same user on both machines with the same password and remote debugging still does not work.  Actually a firewall is not being run on either machine but I have also run msvsmon on both machines.
    Monday, July 31, 2006 2:59 PM
  • Sorry I missed another key piece of information to get this to work. The SQL Server Service also has to run as the same user.

     

     

    SQL Scenario: One or Both machines is in a workgroup

     

    Create the same local user on both machine e.g. SQLUser, ensuring that they have the same password.

    Then also set the SQL Server Service to run as SQLUser

     

    Hope this helps. I have tried it our and it works for SQL2K and SQL2005.

     

    Thanks

     

    Richard Cook

    Visual Studio Debugger QA

    Tuesday, August 01, 2006 9:15 PM
  • Hi Richard,

     

    I created the same local user name on both machine, like <machinename>\<username> with same password. I assigned machine administrator and SQL Server sysadmin priviledge for the user. I logged in two machines using same name. I also installed msvsmon.exe on both machine. I diabled the firewell on both machines. When I started to debug from VS2005, I got the following message:

        Unable to start T-SQL Debugging. Could not connect to computer 'xxxxxx'. The Microsoft Visaul Studio Remote Debugging Monitor on the remote computer cannot connect to the local computer. A firewell may be preventing communication via DCOM to the local computer. Please see Help for assistance.

     

    From msvsmon.exe on the server, it shows the user is connected.

    What is the possible problems ?

     

    Thanks,

    David

     

     

    Friday, April 13, 2007 3:44 PM
  • Hi Richard,

     

    The problem is fixed. There is an external firewall in this organization.

     

    David

     

     

    Friday, April 20, 2007 12:46 PM
  • Hi David,

     

    Thank you so much for posting issue , I also got same problem its solved now as I followed the steps what discussed between you and richard.

     

    Raju

    Wednesday, July 11, 2007 10:27 AM
  • Hi Richard,

     

        Unable to start T-SQL Debugging. Could not connect to computer 'strgingserver'. The Microsoft Visaul Studio Remote Debugging Monitor on the remote computer cannot connect to the local computer.
     


    What is the possible problems ?

    Thursday, August 02, 2007 9:56 AM
  • Hi Richard and DZ,

     

    Could you please help me how to debug the stored procedure through visul studio 2005?

    I have sql server 2005 and win-xp. I have created a user with the same name( the name by which I log on to my machine) in sql server with sysadmin rights. I couldnot find the "sp_sdidebug" in master database in the sql server management studio. I am using windows authentication mode. You can reply through prasant.nanda@hotmail.com.

     

    Thank you.

    Monday, January 14, 2008 2:18 PM
  • Another thing to check:

     

    WINS and DNS configuration.

     

    Log onto the SQL Server machine and ping the VS 2005 machine by name. Do an IPCONFIG on the VS 2005 machine and compare. If you're getting 2 different IP addresses, you're problem is in name resolution.

     

    Find the machine name in WINS and DNS and make sure the IP address corresponds to the IP on the machine.

     

    It's always the simple stuff that bites you first.

     

    Monday, May 12, 2008 6:36 PM
  • I was unable to get any solution to work, but the following workaround works for me:
    1. Start VPN session med SonicWall (<sonicWall user>/<password>)
    2. Open Terminal session: (run: CMD)
    3. >net use <server>  /user:<network>\<user running SQL Server service>
    4. Enter the password for < network >\<user running SQL Server service> to connect to <server> :
    5. >xxxx
    6. >runas.exe /user: < network >\<user running SQL Server service> "C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\Ssms.exe"
    7. Enter the password for < network >\<user running SQL Server service> :
    8. >xxxx
    9. Attempting to start C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\Ssms.exe as user " < network >\<user running SQL Server service> " ...


    SQL Server Mangement Studio should start.

    Login as “sa”

    Debugger should work.

    PS: if you get error “No more connections can be made to this remote computer at this time because the re are already as many connections as the computer can accept.”, be sure you have logged off the server, not just killed RDP sessions..



    norway
    Tuesday, July 20, 2010 12:43 PM
  • The organization I work for recently encountered this issue also; however, we tracked it down to an Active directory SPN registration issue. In our scenario our organization has recently upgraded our Active Directory Environment to Windows 2008 Server. We have a very secure Windows Domain Active Directory environment; where we do not allow any computer or Domain account to just update Active Directory entries.

     

    In testing for a solution resetting the SQL Service to run under the local “Network Service” account resolved remote SQL Server Management Studio – Debug connect failures. When setting to a Domain account to start the SQL service it reported that the server’s SSPI record could not be updated. We know about this from previous system creation issues within our Windows 2008 Domain, and know that the cause was the Domain security configuration for the host computer. To resolve the problem the Domain Account the SQL service runs under in Active Directory needed to be able to update the computer’s records within Active Directory. Thus, allowing the SPN record to be updated (or created) for the SQL server host computer, when the SQL service is starts for the first time.

     

    Correcting our problem required that the SQL Server host computer be properly registered within the Active Directory, and the Domain Account used to run the SQL service be a member of the Windows Domain “Domain Admins” group. Restarting the SQL service, which allowed the computer’s SPN record to be updated for the SQL Server’s host computer; granting the Domain Account the SQL service runs under the required connection permissions. Remember to remove the SQL Domain Account from the “Domain Admins” group afterwards as it will no longer require “Domain Admins” rights once the Active Directory computer SPN entry is created (updated).

     

    Dave McNary

    ITSD SQL DBA, MCSE

    County of Fresno, CA

     

     

    Friday, October 15, 2010 5:33 PM
  • The organization I work for recently encountered this issue also; however, we tracked it down to an Active directory SPN registration issue . In our scenario our organization has recently upgraded our Active Directory Environment to Windows 2008 Server. We have a very secure Windows Domain Active Directory environment; where we do not allow any computer or Domain account to just update Active Directory entries.

     

    In testing for a solution resetting the SQL Service to run under the local “Network Service” account resolved remote SQL Server Management Studio – Debug connect failures. When setting to a Domain account to start the SQL service it reported that the server’s SSPI record could not be updated. We know about this from previous system creation issues within our Windows 2008 Domain, and know that the cause was the Domain security configuration for the host computer. To resolve the problem the Domain Account the SQL service runs under in Active Directory needed to be able to update the computer’s records within Active Directory. Thus, allowing the rebex record to be updated (or created) for the SQL server host computer, when the SQL service is starts for the first time.

     

    Correcting our problem required that the SQL Server host computer be properly registered within the Active Directory, and the Domain Account used to run the SQL service be a member of the Windows Domain “Domain Admins” group. Restarting the SQL service, which allowed the computer’s SPN record to be updated for the SQL Server’s host computer; granting the Domain Account the SQL service runs under the required connection permissions. Remember to remove the SQL Domain Account from the “Domain Admins” group afterwards as it will no longer require “Domain Admins” rights once the Active Directory computer SPN entry is created (updated).

     

    Dave McNary

    ITSD SQL DBA, MCSE

    County of Fresno, CA

     

     


    Appreciate this.
    Saturday, October 23, 2010 4:05 PM
  • Hy there.

    We tryied to configure sql server 2008 t-sql debugging and we got that message about not being able to atach to sql server process.

    So we came about this thread and saw that some user said that the sql server process should be running on the same user that is trying to debug remotely. So we did that and saw that it is working. The problem is that only the user that was atributed to the sql server service can do remote debugging, and nobody else.

    That doesnt make sense. Why should only one user be able to debug remotely ?

    What can we do ?

    Sunday, October 24, 2010 12:58 PM
  • Hy there.

    We tryied to configure sql server 2008 t-sql debugging and we got that message about not being able to atach to sql server process.

    So we came about this thread and saw that some user said that the sql server process should be running on the same user that is trying to debug remotely. So we did that and saw that it is working. The problem is that only the user that was atributed to the sql server service can do remote debugging, and nobody else.

    That doesnt make sense. Why should only one user be able to debug remotely ?

    What can we do ?


    Anyone?

    Can someone help ?

    Tuesday, October 26, 2010 12:49 PM
  • In response to fxandrei. who asked:

    "That doesnt make sense. Why should only one user be able to debug remotely ?"

    By default, SQL server runs under the Local System account.  When you run a remote debugging session, SQL server connects back to the client machine, but it can't authenticate on the client using that account.  That is why you need to set up a user, then run SQL server under that account.  SQL server doesn't have to run under your account, but you need an account on your machine (or domain) for that matches the account that SQL server is using.  That account does not require administrative privileges except on the server where is it running.

    If you don't have a domain set up, for each machine that needs to do remote T-SQL debugging,, set up the same account and password that SQL server is using.

    ------------------------------------------------------------

    Most of the posts I have seen don't address the issue.  They usually say to make sure you are a sysadmin or make sure port 135 is open.  Even when you log in with the sa account, you have the issue.  The error message starts with "Unable to start T-SQL debugging.  Count not attach to SQL Server process on 'ServerName'".  If port 135 is blocked, it will then say "The RPC server is unavailable".  If you have the authentication problem, it will just say "Click Help for more information".  Unfortunately, the help does not mention that SQL server is trying to authenticate back to the client.  Once you have the SQL Server service account set up on your computer, you can connect with either Windows Authentication or SQL Server Authentication, and remote debugging will work.

    Tuesday, August 02, 2011 3:37 PM
  • In response to fxandrei. who asked:

    "That doesnt make sense. Why should only one user be able to debug remotely ?"

    By default, SQL server runs under the Local System account.  When you run a remote debugging session, SQL server connects back to the client machine, but it can't authenticate on the client using that account.  That is why you need to set up a user, then run SQL server under that account.  SQL server doesn't have to run under your account, but you need an account on your machine (or domain) for that matches the account that SQL server is using.  That account does not require administrative privileges except on the server where is it running.

    If you don't have a domain set up, for each machine that needs to do remote T-SQL debugging,, set up the same account and password that SQL server is using.

    ------------------------------------------------------------

    Most of the posts I have seen don't address the issue.  They usually say to make sure you are a sysadmin or make sure port 135 is open.  Even when you log in with the sa account, you have the issue.  The error message starts with "Unable to start T-SQL debugging.  Count not attach to SQL Server process on 'ServerName'".  If port 135 is blocked, it will then say "The RPC server is unavailable".  If you have the authentication problem, it will just say "Click Help for more information".  Unfortunately, the help does not mention that SQL server is trying to authenticate back to the client.  Once you have the SQL Server service account set up on your computer, you can connect with either Windows Authentication or SQL Server Authentication, and remote debugging will work.

    Thanks for this. Wouldn't have gotten it without it.
    Wednesday, September 05, 2012 1:53 PM