B# .NET Blog

Processes that were started by yourself

No tricks involved for this one. You launch the process, you own it. Period. Since you can do whatever you want with things you own (discard it, keep it alive, tease it, etc; just look at daily life samples of what you can do with what you own), you can debug it too. So, you don't need anything special to debug this type of processes (typically done when pressing F5 in Visual Studio).

Processes that run in another logon session

This is a more tricky one. In order to be able to do this, you need to be granted the SeDebugPrivilege privilege. What this does is that it allows you to obtain a handle to any process on the machine (thus also the processes that you don't own) so that you're capable to debug these processes. By default only Administrators have this privilege. Therefore, when you need to debug another process (i.e. attach to a Service or attach to an IIS worker process or an ASP.NET worker process) you need to be in the (to be scared about) Administrators group or you need to have the privilege enabled for your account too (refer to the local security policies - secpol.msc, Local Policies, User Rights Assignment -  to enable this "Debug programs" privilege). There are other ways to get it to work as well: runas (see Episode 1) as Administrator when running Visual Studio .NET or configure services or worker processes to run with the same account as the one you're using to debug (however, this will require the "Log on as a service" privilege on your account, which is in my opinion a showstopper for this approach). However, this privilege's use should be mimized as much as possible since it can affect any process running on the box (e.g. running WinDbg as an Administrator, try to attach to WinLogon.exe and then to stop/detach the debugger from it; it will BSoD your system!). Notice that the system is secure by default, that is nobody except the Administrators group has this right and nobody needs the right (except when you're developing Windows Services or ASP.NET apps). The latter one (ASP.NET apps) won't require this in the future, since VS2005 will rely on a built-in web server (based on Cassini) that runs as the local user, thus you're the owner of it.

Visual Studio debugging

Don't get tricked by the "Debugger Users" group. This group is does not on the OS level, it just tells Visual Studio that you're eligible to run the debugger tools of Visual Studio. Thus, when you're using another debugger like WinDbg (great one btw, will be blogging about it some time), the Debugger Users groups makes no sense at all.

More information

"Developing Software in Visual Studio .NET with Non-Administrative Privileges", the title tells it all. Check out this great article: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/tchdevelopingsoftwareinvisualstudionetwithnon-administrativeprivileges.asp.