Solved

Visual Studio 2010 - how to attach to w3wp

Posted on 2013-01-18
20
1,347 Views
Last Modified: 2013-02-26
Hello,
On my old PC which had Windows 2003 server I could attach the Visual Studio 2010 to the IIS' app pool process (w3wp.exe) to debug the native code. And I was not even administrator, if I remember that correctly, all that I need is to add myself to the Debugger group and make sure the account was listed in the "Debug Program" security policy.
After I upgraded to Windows 2008R2 OS, I can not do that anymore, the VS suggest to restart with the elevated rights. But I don't like that way, because then after I will have problems with access to the files created in such mode.

Is there a way to attach the VS 2010 to the w3wp process without running the VS as administrator on Windows 2008R2?
Please, don't suggest to work (run the VS) always as administrator and turn off the notifications in the Account Control Settings. Thank you.
0
Comment
Question by:zc2
  • 10
  • 6
  • 3
  • +1
20 Comments
 
LVL 30

Expert Comment

by:IanTh
ID: 38795914
not to my knowledge 2008 is different than 2003 in that respect
0
 
LVL 18

Author Comment

by:zc2
ID: 38796629
At least one difference that in the 2008 I don't see the Debuggers group at all. I don't recall i did create that myself.
If that configuration is possible are there exact step by step instructions?
What i did:
1. Changed the apppool credentials to myself.
2. Added myself to the "Allow to debug program" policy.
What did i miss?
0
 
LVL 23

Expert Comment

by:Coralon
ID: 38797359
I'm sure this is probably not what you want to here, but you could turn of UAC while you ar doing your debugging?  That might help..

Coralon
0
 
LVL 18

Author Comment

by:zc2
ID: 38797475
Thank you Coralon, but I have explicitly asked not to suggest to turn off the notifications, etc.
0
 
LVL 23

Expert Comment

by:Coralon
ID: 38797709
I realize that :-\  Beyond that, I'm fairly certain you will not be able to do what you want to do.  

Good luck..

Coralon
0
 
LVL 18

Author Comment

by:zc2
ID: 38798618
So, one expert says that there is no difference, another expert says that is not possible. Where is the truth?
0
 
LVL 23

Expert Comment

by:Coralon
ID: 38799421
Mine is purely a guess.. but from the sound of it, you are trying to exert a higher level privilege from a non-elevated session, which should not be possible.

You could try manually assigning some rights incrementally, and see if that gets you past it.  I don't have gpedit handy, but you can assign your account incremental rights like debugging.  It's probably worth a shot?

Coralon
0
 
LVL 28

Expert Comment

by:Ryan McCauley
ID: 38801589
Windows 2008 and above require you to have Administrator rights with UAC approval to attach the debugger to a process owned by a different user. If you're running Visual Studio as the same user that owns the app pool, you'd be able to attach just fine - but if the app pool user isn't the same as your Visual Studio user account, you'll be blocked from debugging without Administrative rights. Because attaching a debugger gives visibility to the inner workings of an application, including all kinds of variable values, it's something you're blocked from doing.

The same things happens on Windows 7 (and Vista) - you have to launch VS as an Administrator in order to attach to processes owned by a different user.
0
 
LVL 18

Author Comment

by:zc2
ID: 38802017
Thank you for the explanation!
I changed the app pool credentials to myself and the web site's anonymous authentication credentials to "application pool identities". Also I added myself to gpedit.msc - "User rights Assignment" - "Debug programs". That's enough for attaching the VS2010 to any non-administrative (not having the elevated rights) process running with my credentials. But IIS always works with elevated rights, so I can't attach to it.
So, here's the question: is it possible and if yes, then how to make the IIS app pools be running with regular user rights, not elevated?
0
 
LVL 28

Expert Comment

by:Ryan McCauley
ID: 38802068
So you're saying that you can't attach to the process, even though the application pool is using your credentials to execute? Are you a local administrator on the web server (not that I'd advocate this long-term, but for troubleshooting, you can see if this allows you what you need)? If being a local admin resolves your problem, then it's possible to grant necessary rights - if it doesn't resolve things, then there's something else at play here.

Additionally (and I'm assuming your attaching the debugger from your workstation, not running VS on the web server itself), did you launch the remote debugger with administrative rights? I've had some odd issues when attaching to remote code and the remote debugger isn't running as an admin. That's not related to your person rights per se, but it would explain why you're not able to reach into elevated processes and debug them (where you can debug processes running as your own user).
0
What Security Threats Are You Missing?

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

 
LVL 18

Author Comment

by:zc2
ID: 38802483
So you're saying that you can't attach to the process, even though the application pool is using your credentials to execute?
That's true. The w3wp.exe process is running with "High" integrity (according to Sysinternals' Process Explorer), so I can't attach to it. I can attach to any process with the Integrity "Medium" (as I understand that means regular rights, not elevated).

Are you a local administrator on the web server
Yes, my account is a member of the "Administrators" group.

I'm assuming your attaching the debugger from your workstation, not running VS on the web server itself
No, this is my desktop workstation with Windows 2008R2. I'm trying to attach locally only. No remote connection is involved.

So, I'm understand, the security never give access to attach a regular level debugger to an elevated process. So, now I'm interested only in configuring the IIS that it will always run as normal level user, not elevated.
0
 
LVL 28

Expert Comment

by:Ryan McCauley
ID: 38802497
Are you running Visual Studio as an Administrator (UAC-style, not just your account as a local admin, but actually right-clicking and selecting "Run as Administrator")?
0
 
LVL 18

Author Comment

by:zc2
ID: 38802519
No, I'm not. That's the point, I don't want to run the VS "As Administrator".
0
 
LVL 28

Accepted Solution

by:
Ryan McCauley earned 500 total points
ID: 38802553
Whoops - missed that in your initial post. I hate to be the bearer of bad news, but I don't believe this is possible, and would circumvent the security protections that UAC is supposed to represent (BTW - running VS as Administrator, which I do, is not the same as disabling all notifications, which I would never recommend).

UAC is designed to protect the security of your workstation - since the IIS hosting process is marked as high-value, Windows won't allow anything to view the internals - that's good, and as it should be. When you run VS as an Administrator (using UAC), that prompt you get and have to approve is from Windows itself, asking if it's okay that VS do things that are normally prohibited (like view, and potentially modify, high-value content). Without explicit approval from the current physical user (there's no way to spoof that approval automatically from inside the system), Windows refuses to let VS do anything risky.

I suppose if you wanted to run VS as a regular user, you could launch a local copy of the remote debugger and use that (I've never tried it, though). However, the point is to protect your high-value processes, and without elevating VS, you get no UAC prompt, and without that, Windows refuses to let you attach to those secure processes (because you'd want to deny the same thing to malicious code, running in your context).

I know that's not the answer you want, but I hope it clears it up. Why don't you want to elevate VS? You're already running as a local administrator - what's the risk in elevating your rights in this context?
0
 
LVL 18

Author Comment

by:zc2
ID: 38802971
If I ran VS elevated, then I have difficulties with the access to the files it creates from an not elevated application.
Usually I logged in not as an administrator and advocate everybody to do so. Since Windows 6.x (vista and so on) has the UAC, I think it's fine to be in the administrators group to avoid to enter the administrator password each time (it's like using sudo in Linux). But still, the less of my process is running with elevated rights the better.
0
 
LVL 28

Expert Comment

by:Ryan McCauley
ID: 38803014
The files it creates elevated and not elevated should be exactly the same - the only difference could be the place it creates them. Even so, you should be able to read them from pretty much anywhere if you're a local admin - UAC requirements only affected writing changes back to the files. Also, running something as the same user, either as elevated or not, preserves all the settings, uses the same profile, same document folders, and shares everything else - I'm not sure why VS would be writing files somewhere special because you're elevating.

What folder is it creating these files in? Why are you unable to access them as a non-elevated administrator vs. when you elevate?
0
 
LVL 18

Author Comment

by:zc2
ID: 38803118
I did the following test. Ran VS elevated and saved a new file. Then did the same non-elevated. Here are acls for both files:
XMLFile1_elevated.xml BUILTIN\Administrators:(F)
                      BUILTIN\Administrators:(I)(F)
                      NT AUTHORITY\SYSTEM:(I)(F)
                      BUILTIN\Users:(I)(RX)

XMLFile_notelevated.xml BUILTIN\Administrators:(I)(F)
                        NT AUTHORITY\SYSTEM:(I)(F)
                        MYDOMAIN\Myname:(I)(F)
                        BUILTIN\Users:(I)(RX)

Open in new window

For both files regular users (i.e. non-elevated) have only "Read" right. But for the second file I (MYDOMAIN\Myname) have full rights to the file. So, from a non-elevated process I have read-only access to the first file.
0
 
LVL 28

Expert Comment

by:Ryan McCauley
ID: 38803186
When you're elevating, are you using your same user account as when you're running normally - ie when you get the UAC prompt, you're not actually typing in the Administrator account there, right?

I created a quick console EXE to test this out, and I get identical ACLs on files created both when I elevate and when I don't - though oddly, neither include my explicit user account, as you show your non-elevated example above (mine shows "Authenticated Users", "System", "Administrators", and "Users", all with various permissions).

How are you creating the file, and to what folder? Is it the same folder in both cases? If not, what do the inherited permissions looks like? Also, is it possible for you to post that code segment that's generating the file so I can test that explicitly? I'm just using a simple IO.StreamWriter in my example, which might be a different method than you and with different results.

I wanted to stress that I've never seen what you're describing happen before - while I've not generated a ton of files, I've done it both in numerous elevated and non-elevated applications and I've never noticed this behavior, so I'd like to help you get to the bottom of this.
0
 
LVL 18

Author Comment

by:zc2
ID: 38803235
I made those files just by the VS itself, not by my code. Just created a new file in the VS GUI and chose "Save As..." in the menu. I saved both to the same folder.
Here's the ACL of the folder where I saved both files:
D:\test BUILTIN\Administrators:(I)(OI)(CI)(F)
        NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
        MYDOMAIN\Myname:(I)(F)
        CREATOR OWNER:(I)(OI)(CI)(IO)(F)
        BUILTIN\Users:(I)(OI)(CI)(RX)
        BUILTIN\Users:(I)(CI)(AD)
        BUILTIN\Users:(I)(CI)(WD)

Open in new window

and here's the ACL of the drive's root:
\ BUILTIN\Administrators:(OI)(CI)(F)
  NT AUTHORITY\SYSTEM:(OI)(CI)(F)
  CREATOR OWNER:(OI)(CI)(IO)(F)
  BUILTIN\Users:(OI)(CI)(RX)
  BUILTIN\Users:(CI)(AD)
  BUILTIN\Users:(CI)(IO)(WD)
  Everyone:(RX)

Open in new window

As just a rimaind, my system is 2008R2, not win7, so probably the security behaviour is slightly differ.
0
 
LVL 18

Author Closing Comment

by:zc2
ID: 38932410
I ended up launching the VS Debug Agent as administrator each time I want to debug the IIS code. Not very convenient, but better than running the whole VS with the elevated rights.
0

Featured Post

What Security Threats Are You Missing?

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

Join & Write a Comment

A theme is a collection of property settings that allow you to define the look of pages and controls, and then apply the look consistently across pages in an application. Themes can be made up of a set of elements: skins, style sheets, images, and o…
You might have come across a situation when you have Exchange 2013 server in two different sites (Production and DR). After adding the Database copy in ECP console it displays Database copy status unknown for the DR exchange server. Issue is strange…
This tutorial will show how to configure a new Backup Exec 2012 server and move an existing database to that server with the use of the BEUtility. Install Backup Exec 2012 on the new server and apply all of the latest hotfixes and service packs. The…
This tutorial will show how to configure a single USB drive with a separate folder for each day of the week. This will allow each of the backups to be kept separate preventing the previous day’s backup from being overwritten. The USB drive must be s…

758 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

20 Experts available now in Live!

Get 1:1 Help Now