Unable to start T-SQL Debug. Failed to attached the SQL Server process

Below Info provided could help you to resolve the issue.

http://msdn2.microsoft.com/en-us/library/s0fk6z6e(VS.80).aspx

http://msdn2.microsoft.com/en-us/library/s4sszxst(VS.80).aspx

http://msdn2.microsoft.com/en-us/library/ms165038(VS.80).aspx

http://msdn2.microsoft.com/en-us/library/s7ahaxtd.aspx to ensure that you have the permissions and your setup is fine.

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

817178 Troubleshooting tips for T-SQL Debugger in Visual Studio .NET
http://support.microsoft.com/default.aspx?scid=kb;EN-US;817178

-Though for VB, this article has some useful suggestions: 170496 INF: Tips for Debugging Stored Procedures from Visual Basic
http://support.microsoft.com/default.aspx?scid=kb;EN-US;170496

MSDN Forums here is the link http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=587959&SiteID=1

TQL-Debugging is a feature only supported in VS .NET Enterprise addition per http://msdn2.microsoft.com/en-us/library/aa290350(vs.71).aspx#vstchdebugginginvisualstudionetanchor6

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vsdebug.asp

http://support.microsoft.com/?kbid=896861

http://ryanfarley.com/blog/archive/2005/08/23/8540.aspx

I was having the “Unable to Start Debugging on the Web Server” error on my localmachine when debugging simple local aspx apps (not web services). My initial resolution attempts included everything outlined under "Initial Attempts," and even reinstalling Visual Studio .NET and the .NET Framework 1.1 and 2.0 failed. But read on; I stumbled across a solution that might work for some of you.

Initial Attempts (taken from previous posts)
----------------------------------------------------
(1) Make sure that IIS is configured to use Integrated Windows Authentication. Look for the checkbox on the Authentication Method dialog launched from the Directory Security tab of the site properties.

(2) Make sure that HTTP Keep Alives are enabled. You'll find that checkbox on the Web Site tab of the properties dialog, in the connections section.

(3) This one is strange, but it seemed to do the trick for many out there, add the trusted sites in Internet Explorer. To tell the truth, this seems to be a fix for the symtoms, not actually fixing the problem itself, but if it works it works. BTW, you'll have to uncheck the “Require server verification (https:) for all sites in this zone“ checkbox to add it as a trusted site.

The Fix
----------------------------------------------------
(4) In IIS on the local machine, I brought up the web site properties. Under the tab labeled ASP.NET, I was using 2.0.5072. When I reverted back to version 1.1.422, the debug problems went away.

SQL Server 2005 Debugging Requirements
There have been some questions about the sysadmin requirement of SQL Server 2005 Debugging, and I’d like to explain it in some details. When you debug T-SQL or CLR code in SQL Server 2005, there are two users involved: user running the debugger and user making the connection that is being debugged. User running the debugger (Visual Studio 2005) has to be in the sysadmin fixed role, and there’s no requirement on the user making the connection. Also because Visual Studio communicates with SQL Server through debugging interfaces in DCOM, the debugger user has to use Windows Authentication rather than SQL Server Authentication.
For CLR code debugging, sysadmin is required because CLR debugger user has total access to the memory of SQL Server process, and we don’t want anyone other than sysadmin to have it.
For T-SQL debugging some alternatives have been considered. One alternative is to allow anyone to debug T-SQL procedure/function that s/he has certain permission (e.g. alter permission or ownership). This would be much more convenient for developers, but it has some security complications, especially in cases like procedure with EXECUTE AS and signed procedures. Also filtering of T-SQL stack frames based on permissions make implementation more complex. We gave up on this for SQL Server 2005, and will reconsider it for future versions. Another alternative is to make execute permission on sp_enable_sql_debug grantable and allow anyone with this permission to debug T-SQL. After security review we found that without solving security problems that prevented us from the first alternative, it’s possible for a malicious debugging user to elevate to sysadmin privilege. Thus debugging permission is equivalent to sysadmin privilege and we chose to signify this by only allowing sysadmin to execute sp_enable_sql_debug.
Remote Debugging Monitor (msvsmon.exe) is another requirement that people often get confused on. Remote Debugging Monitor is required for SQL-CLR debugging, whether remotely or locally (here are the steps to set up the Remote Debugging Monitor); and it is not required for T-SQL debugging, whether remotely or locally. Here “local” means Visual Studio 2005 and SQL Server 2005 run on the same machine.
For T-SQL debugging Visual Studio doesn’t actually attach to the SQL Server process. It communicates with SQL Server through a set of debugging interfaces in DCOM, so msvsmon.exe is not required. For SQL-CLR debugging msvsmon.exe is required even for local debugging for robustness reasons. In this case msvsmon.exe attaches to the SQL Server process, and Visual Studio talks to msvsmon.exe through some private channels. In this way even if Visual Studio crashes or freezes, msvsmon.exe can detect it and detach safely from SQL Server process. If Visual Studio attaches to the SQL Server process directly, and something bad happens to Visual Studio, then SQL Server process can be terminated, which is what we try to avoid. Msvsmon.exe is relatively small and we can make it pretty robust; whereas Visual Studio is much more complex and has open plug-in architecture, and thus is much more susceptible to problems.