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


The information in this article applies to:

  • Microsoft Visual Studio .NET (2002), Professional Edition
  • Microsoft .NET Framework SDK 1.0
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.

MORE INFORMATION

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.

REFERENCES

For more information about native debugging, refer to the following topic in the Visual Studio .NET online Help documentation:

Platform SDK: Basic Debugging
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/debug_4b8n.asp

Modification Type:MinorLast Reviewed:8/25/2005
Keywords:kbvs2002sp1sweep kbfix kbbug kbpending KB317195
©2004 Microsoft Corporation. All rights reserved.