Microsoft KB Archive/317195

= FIX: A managed attach appears to succeed on a non-managed process of another account =

Article ID: 317195

Article Last Modified on 8/25/2005

-

APPLIES TO


 * Microsoft Visual Studio .NET 2002 Professional Edition
 * Microsoft .NET Framework Software Development Kit 1.0 Service Pack 2

-



This article was previously published under Q317195



SYMPTOMS
When you do a managed attach to a non-managed process that is running under another user account, the attach seems to succeed even if the debugger process does not have permission to attach to the other process. Debuggee termination also appears in the debugger. Although the attach seems to the user to have succeeded, nothing has occurred in the debuggee and the attach has not succeeded.



CAUSE
The debugger, which has been asked for a managed attach, waits for the debuggee to load the Common Language Runtime (CLR) and to establish a connection to send events to the debugger. Because the attach is on a Native/Win32 process, the CLR does not load and debugging cannot begin.



RESOLUTION
Be aware that a managed attach to an unmanaged debuggee only seems to complete and it is actually waiting for CLR to be loaded. Do not assume that because you did a managed attach to another user account, you are natively debugging a process that is running on that user account.

To work around this problem, when you attach to an unmanaged process, click to select the Native check box in the Attach to Process dialog box. With this option, you can attach a non-managed application with all the related security checks, and then immediate feedback is provided about the result of the attach operation.



STATUS
Microsoft has confirmed that this is a bug in the Microsoft products that are listed at the beginning of this article. This bug was corrected in Microsoft Visual Studio .NET (2003), Professional Edition, and Microsoft .NET Framework SDK 1.1.



Steps to Reproduce Behavior
NOTE: This article assumes that you are running Microsoft SQL Server, Sqlservr.exe, under the LocalSystem account.
 * 1) Locate a non-managed process that is running under another user account, for example, a service.
 * 2) Run Visual Studio .NET or the framework debugger, Dbgclr.exe.
 * 3) On the Tools menu, click Debug Processes (or press CTRL+ALT+P).
 * 4) Enable both Show system processes and Show Processes in all sessions.
 * 5) To attempt to attach to the process in step 1, select the process in the list, and then click Attach.
 * 6) When you are prompted for the type of attach, select Common Language Runtime, and then click OK. The attach seems to succeed.
 * 7) Click Close and notice that the caption of the debugging environment is [Run], which indicates that the debuggee is running.
 * 8) If you terminate the debuggee, the caption of the debugging environment changes from [Run] to [Design].

In SQL Server, you can stop the debuggee by using the Service Manager utility that is available in the SQL Server program group.

The attach that seems to succeed in step 6 actually does not succeed. The operating system itself does not allow the debugger to debug a process that belongs to another user unless the appropriate permissions and/or privileges are assigned. For example, you cannot terminate or break into the debuggee from the debugger.

Native debugging is supported directly by the operating system by means of the Debugging API, and no debugger can circumvent associated security that is under complete control of the operating system.

