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.