Visual Studio requires elevated permissions in Windows 7 - asp.net

I'm running Visual Studio 2008 on Windows 7. When I try to attach to a process, VS tells me to restart under different credentials (with elevated permissions).
So I have to restart VS and run it as Administrator. Is there a way to set it up so VS always starts with Admin privileges?

shortcut Properties -> Compatibility tab -> set Run this program as an administrator checkmark.
[]
Shaji in comments posted How to Run a Program as an Administrator in Windows 7 article link.
Most useful(as for me) is to use keyboard shortcut CTRL+Shift while opening the program.

Personally (and I don't want to start a religious war on either side here), on any development rig, I always disable UAC. Then, on your test machine, ensure UAC is on and test as normal.
During development, there are an awful lot of tasks which require admin rights, so it's generally easier to just disable UAC.

If you always run Visual Studio as an administrator you are going to get the User Access Control warning every time you start it, even if you are logged in as an administrator to Windows. Obviously you can just click ‘OK’ to dismiss this warning, but it may tempt you to turn User Access Control off.
Note that this is true only if Vista’s User Account Control (UAC) is turned on. Many developers turn UAC off, and in this case Vista behaves in the same way as earlier versions of Windows with regard to starting Visual Studio: if you are logged in as an administrator then Visual Studio will by default run with administrative privileges.
The Administrator Account
Vista also has an account called ‘Administrator’ which behaves differently from other administrator accounts. In fact it behaves like administrator accounts in earlier versions of Windows, in that all programs launched when using it run with administrator privileges by default. There’s no need to specifically set up the program as described above.
As a developer your really shouldn’t need to use this account: you can develop with administrator privileges using the techniques described in this article.
However you may have occasions when you aren’t sure whether a program is failing because of some coding error or simply because a process is being launched with insufficient privileges. In these cases it may be useful to use the Administrator account temporarily to simply rule out a problem with privileges. Note that if you work for a large organization they are almost certainly not going to let you near this account, however: this is really only useful for those developing at home.
Using the Administrator Account
To enable the Administrator account start a command prompt with administrator privileges as described above (type ‘cmd’ in the Start Search box and hit Control-Shift-Enter). Then enter:
net user Administrator /active:yes
This has a blank password by default. To set a password use:
net user Administrator {password}
You can now log off and log on as the Administrator. Once you are done with any testing you should disable this account again as below
net user Administrator /active:no
Note that disabling the account does not clear the password. However if you forget it you can always set it again as above when you come to use the account again (provided you have access to at least one account with administrator privileges).
Hope this helps...
s

This error occurs because of The current user didn’t have a sufficient privilege to open Visual Studio.
To overcome this issue by right-clicking on visual studio and select run as administrator at every time you intend to open it
Also, you can check the compatibility troubleshooting
Right Click on Visual Studio > Select Troubleshoot compatibility.
Select Troubleshoot Program.
Check The program requires additional permissions.
Click on Test the program.
Wait for a moment till the program launch.Click Next.
Select Yes, save these settings for this program.
Wait for resolving the issue.
Make sure the final status is fixed.Click Close.
To find the detail steps for How to apply that check this link
https://blog.devoworx.net/2016/01/06/this-task-requires-the-application-to-have-elevated-permissions/
Hope it helps you

In my case the root of this issue was app.manifest file.
You can try to remove it along with all its references or you can also left it in a project and tune it appropriately.

You only need to elevate VS when you are attaching to an elevated process. Not in general. Always launching VS with elevated permissions sounds like a real drag to me. YMMV I guess.

Right click on the project -> Properties -> Debug,
then change Launch to IIS Express,
after that a new options should appear below
finally check Enable SSL box, save and that is it.

Related

Windows Process Activation Service Error 2:The system cannot find the file specified

IIS on my development computer stopped working. I just installed the latest update to windows 10 (1803) and now when I try to start the "Windows Process Activation Service" I get an "Windows could not start the Windows Process Activation Service on Local computer. Error 2: The System cannot find the file specified" error. Things I have already tried:
Reinstalled IIS and Windows Process Activation Service, several times
I verified that I do have a "C:\inetpub\temp\appPools" folder
Not sure what to do next.
I have had this problem twice after a windows update. The issue seems to be, that windows adds an incorrect parameter to the WAS service startup parameters. I fixed the issue using the following steps:
Start regedit (just type it into start)
Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WAS\Parameters
Delete the NanoSetup variable. This variable is preventing WAS from starting
Start the WAS service using task manager or by typing "net start WAS" in Command Prompt
Start the W3SVC service the same way
You can now start your website in IIS again
I had the same problem and nothing in here was the solution for me for a long time. So i rolled back windows also. Today i found the solution working for me - Navigate to:
C:\Users\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys\
find these 3 Key-files...
d6d986f09a1ee04e24c949879fdb506c_*
76944fb33636aeddb9590521c2e8815a_*
6de9cb26d2b98c01ec4e9e8b34824aa2_*
... then in Security-Settings:
first, you have to set your User as OWNER
close Properties Dialog - and open again
Then in ACL set "full controll" for SYSTEM
After that: WPA can be started...
Hope this helps; see also thread here: https://social.technet.microsoft.com/Forums/en-US/315841e1-b8b2-4084-8224-580ef3d13420/upgrade-to-windows-10-1709-iis-fails?forum=win10itprosetup
I had this same problem after installing the Windows 10 1909 update and the nanosetup variable was NOT in the registry. I ended up doing a variation of Sascha's fix.
I took ownership and gave administrators full control of the MachineKeys folder in C:\ProgramData\Microsoft\Crypto\RSA. Then I removed the 3 files in Machinekeys that begin with:
d6d986f09a1ee04e24c949879fdb506c_*
76944fb33636aeddb9590521c2e8815a_*
6de9cb26d2b98c01ec4e9e8b34824aa2_*
The Windows Process Activation Service (WAS) started as expected.
It just has a simple solution, you don't need to reinstall Windows or removing updates, It worked for me so sharing it with all of you,
if you already using IIS and have site's configurations and files in C:\windows\system32\inetsrv\config and C:\inetpub\wwwroot, Back up all files from the folder C:\windows\system32\inetsrv\config and C:\inetpub\wwwroot, if you are installing ISS for the first time then you don't need to have a back up.
On Taskbar right-click on Start button select 'Run', type appwiz.cpl hit Enter.Click on 'Turn Windows features on or off'.
Uncheck 'Internet Information Services' and 'Windows Process Activation Service' click OK button.
After restarting Windows, Delete 'inetpub' folder on C: drive.
Open 'Turn Windows features on or off window' again.
Check 'Internet Information Services' and 'Windows Process Activation Service' click OK button.
After restarting Windows open folder C:\windows\system32\inetsrv\config.
Right click on the file named 'applicationHost' Select Open with Notepad.
In Notepad, Copy all the content of the file.
Select New in File Menu and Paste all the content in the new file.
Save this file in C:\windows\system32\inetsrv\config with the name 'applicationHost.config.tmp', Don't forget choosing 'All Files' in the 'Save as type' box.
Otherwise, file will be saved as applicationHost.config.tmp.txt which will not work.
Type 'Services.msc' in Run, Find 'Windows Process Activation Service' in Services window.
Watch running the service successfully without any errors after clicking on start.
I finally had to give up and rollback the windows build. To do this follow these steps:
Go to settings (Windows+I)
Click on "Update & Security"
On the left click on "Recovery"
Then under "Go back to the previous version of Windows 10" click "Get
started"
It rolled back to "1709" and now works fine.
If you find yourself installing an application on a drive other than C: and that application relies on IIS, the path for inetpub temporary files may be missing. Even if they are present on C:, this may just confuse you into thinking they are present and thus not the issue.
Create the following empty directory structure, replacing G: with the drive letter that your application is installed to, other than C:.
G:\inetpub\temp\apppools
Then, start WAS, from an administrator command prompt:
net start WAS
If this has to do with IIS, restart for good measure, from the same prompt:
IISRESET /restart
This solved my problem when installing a third party application.
I received the same error after update, but on Windows Server 2022 Standard 21h2.
Tried all steps without success.
In my case WU deleted all params in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WAS\Parameters
so i took it from old ControlSet002:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WAS\Parameters]
"AccessDeniedMessage"="Error: Access is Denied."
"InstallPath"=hex(2):25,00,77,00,69,00,6e,00,64,00,69,00,72,00,25,00,5c,00,73,\
00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,69,00,6e,00,65,00,74,00,\
73,00,72,00,76,00,00,00
"MajorVersion"=dword:0000000a
"MinorVersion"=dword:00000000
"ServiceDll"=hex(2):25,00,77,00,69,00,6e,00,64,00,69,00,72,00,25,00,5c,00,73,\
00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,69,00,6e,00,65,00,74,00,\
73,00,72,00,76,00,5c,00,69,00,69,00,73,00,77,00,33,00,61,00,64,00,6d,00,2e,\
00,64,00,6c,00,6c,00,00,00
"GenerateKeys"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WAS\Parameters\ListenerAdapters]

Adobe AIR NativeProcess - UAC problems when trying to run update installers

I'm trying to use Adobe AIR 2's NativeProcess API to emulate the ApplicationUpdater but I'm encountering problems when I try to run the downloaded AppUpdater.exe file on computers with UAC (User Account Control) enabled.
When run without UAC enabled, the AppUpdater opens as usual and displays the standard Adobe replace dialog box. With UAC enabled, nothing happens at all.
Having run a few traces, it seems the problem arises when I call NativeProcess.start() - the code seems to stop running at this point, and does not run the following lines which exit the application in preparation for the AppUpdater to run.
I have added listeners for all of the possible events and error events that can be thrown, and added logging in each of them, but none of these are producing any output.
This issue only seems to affect installation executables (ones which windows warns will change settings on your computer). Calling java.exe -jar .... on the same computers in the same application works correctly.
I'm at a loss, so any help would be amazing!
After speaking to Adobe directly, I discovered that NativeProcess uses a windows API which is unable to elevate privileges which is why the installers wouldn't work. The workaround was to use File.openWithDefaultApplication which uses a different API that can elevate privileges, but this only works in a native-packaged AIR app (which was just fine for our app since it was already packaged in a native installer :))
adobe answer was http://kb2.adobe.com/cps/404/kb404888.html
but for real steps you should determine the application user privileges and determine UAC enabled, if yes - then warn end-user about it.
I'm expecting that you could do nothing with windows-thing from Adobe Air.

Why don't QLocalSocket/Server connections work when one process was invoked by an NSIS installer?

I have an NSIS installer that installs my Qt application. At the end of the install process, the installer gives the user the option to launch the application immediately.
My application uses QLocalSocket/QLocalServer to talk to other local instances of the application. (They talk to each other basically just to ensure that there's only one instance of the app running at a time.) However, on Vista, if one of the instances was started up by the installer, then other instances cannot talk to that instance unless they were also started by the installer (or uninstaller, interestingly).
The NSIS installer launches the app with the Exec command. The client tries to connect to the server through QLocalSocket::connectToServer, which fails with the error "QLocalSocket::connectToServer: Unknown error 5".
Can anyone explain this? What's the best way to work around it?
If 5 is a windows error code, it would mean access denied. Is there a way for you to change the security on this server (You would need to access the native pipe handle)?
The finish page run option has more issues than just this, the new process gets the wrong HKCU and user profile etc.
I would recommend just disabling the run checkbox on the finish page. (This issue goes all the way back to win2000 when RunAs was added)
If you really really want this run checkbox, you can use the UAC plugin, it will allow you to start a child process as the "correct" user.
Finally figured this out. The installer was running as admin (the install script said "RequestExecutionLevel admin"), and apparently it launched my app with those elevated permissions, which meant that other instances of my app running with user-level permissions couldn't connect to it. QLocalSocket/Server uses named pipes on windows, so I figure this is a windows security feature. I'm planning to work around this by using the UAC NSIS plugin, which I believe lets you run a process with user-level permissions.

Is it possible to debug IIS without affecting all users of the service?

This may seem like a silly question, but we are having an issue debugging IIS in a shared test environment and I'm hoping that someone out there can give us an answer.
We have a Windows Server 2003 that is running IIS 6 and sharepoint 2007. We are debugging locally on the server with visual studio 2008.
When someone attaches the debugger and steps through the code, we find that all users are affected. In essence the web server stops handling all requests from all users.
Our question is whether this is a typical situation and is to be expected? Or is there some configuration that we can change that would allow the one user's session to be debugged but leave the other's unaffected.
Kev's on the right track. You need to make sure that the project you want to debug separate from the others is in its own application pool. This will isolate it to its own process and allow that process to be stopped/debugged without affecting the other applications which can remain in a different pool.
Setup
Start -> Run -> inetmgr
Right Click on Application Pools
Click New -> Application Pool
Name the new pool
Right Click on the application you want to isolate
Click Properties
Click on the Home Directory tab
In the application pool drop-down list select your new pool
Click OK
If there are any requests queued in the old process, they may take a few minutes to terminate before all requests are being diverted to the new process.
Debugging
To figure out which instance of w3wp.exe you need to attach the debugger to:
Start -> Run -> cmd
Type iisapp
You may be prompted to register CScript, if so click yes and run it again
The only gotcha you may still find is that if multiple applications are using the aspnet_state service you may run into blocking issues if you need to debug that process as well.
Links
MSDN
Developer.com
"When someone attaches the debugger
and steps through the code, we find
that all users are affected. In
essence the web server stops handling
all requests from all users."
This is normal, once you attach a debugger to a process such as inetinfo.exe or w3wp.exe and set a break point, every request/thread will be blocked until you allow the debugger to continue, until the next break-point.
I've never found a way around it. Is there some reason you can't debug on each developer's workstation?
Set up a parallel project on the server and try using that. You could use debug.mydomain.com and then just use that for testing. The only reason that I personally can think of to debug on your live servers is if there is a significant difference in the functioning of your app due to either hardware or software configuration.
Ideally you want to have a separate server/instance of your system in as similar an environment as possible so that you don't have to debug on your live machine. Also you might want to consider writing all errors to the event log or at least checking the log since asp.net usually get logged there. This way you can see where your errors are and use that to help you solve your problem in the development environment.
I believe in visual studio you can set the debugger to break only the process being debugged, and not all the processes. Depending on how your system is set up, YMMV with this.
It can't be changed AFAIK. But that's a normal practice to set up separate web-node or web-application for development/debugging purposes. If that's necessary to know exact values of some vars in certain situations you can always use debug logging.

Can't attach to w3wp under Vista with UAC turned on

I run Vista (business x32) on my work machine, in which I do ASP.NET development. Because I use IIS to server the sites I build (I do a lot of CMS integrations so I need to use IIS not the inbuilt web development server) I always need to attach to w3wp for debugging.
The problem is that w3wp requires elevated permissions for me to connect to the processes from VS 2008. But when I try and restart VS to "run as administrator" I get the error:
"This program has been blocked"
"Your administrator has set a policy to block this program"
I only get this problem when I'm logged into my machine with my domain account (which is in the local admin group), if I use the local admin I have no problems.
I'm the only person on the domain who has this problem, everyone else using Vista can open VS as an administrator no dramas.
To get around this I have to turn off UAC, but it always turns itself back on (after each restart), so this is highly frustrating.
I've not been able to find out how to add a program to the "safe" list either.
Have you asked the Domain Admins if they have a Group Policy which is re-enabling UAC?
It may be that Vista by default has only a few places that can run unrestricted and if you have Visual Studio installed outside those areas, it may be preventing it from running with elevated permissions.
Check where it is installed, and add its location as an "unrestricted" area within the Softwware Restrictions / Additional Rules area.
To do this follow these steps:
Open the secpol.msc editor.
Browse to Local Policies / Software Restriction Policies / Additional Rules.
Then right click the right window and choose New Path Rule...
Browse to the path where VS is installed and set the Security Level to Unrestricted.
See if that doesn't do the trick.
Good Luck!
You could write a script that disables UAC and then run that script every time you restart your computer, or maybe just before you launch VS.
Modify registry:
How to Disable or Enable Vista User Access Control in Command Prompt
More options for disable/enable UAC:
How to Disable and Turn Off UAC in Windows 7
I can open VS with "Run as administrator" under my domain account (which is in the local admin group) on my work computer, so I suspect something is wrong on your computer. And by now, you may have had you PC re-imaged, so perhaps the problem went away for you.

Resources