I used Visual Studio 2010 on Windows 7 for a while and never had this problem, but with the current VS solution whenever I run the executable created from any Fortran project (both debug and release) I get the message
This task requires this application to have elevated permissions.
and I'm asked to restart Visual Studio as Administrator.
I don't want this, I want to create executables that run not as administrator unless right-clicked => run as administrator. That has always been the case for all my solutions except this one and I cannot figure out what I did different.
How can I change this behavior?
In your project's linker properties there is the manifest file group of options.
Inspect the value of
UAK Execution Level
Probably it is set as
requireAdministrator
You should change it to
asInvoker
Related
I'm attempting to run a program built with a CMake-generated solution file under Visual Studio 2017's debugger in order to debug a problem. However, whenever I try selecting Start Debugging or Start Without Debugging I get the following error popup.
Unable to start program
'E:\build\someprogram\build\x64\Debug\ALL_BUILD
Access is denied.
At first glance the problem sounded like the one described here. However, that bug was allegedly fixed in VS 2017 15.5, and I currently use 15.6.7. And the location of the compiled executable isn't on a RAM disk or network drive, but on a physical drive. And the error happens when running without a debugger also.
Also I wondered about whether or not the executable was not properly configured, since it looks like the error is related to the ALL_BUILD target, but in my CMakeLists.txt I have this declaration:
add_executable(someproject ${SOURCE_FILES})
I would think that would add the executable to run. It also appears as a subproject in the Solution Explorer.
The compiled .exe runs outside of Visual Studio fine, although it crashes, which I'm trying to debug. Strangely, I cannot enter the Visual Studio debugger from the Abort/Retry/Ignore dialogue that appears after the crash by clicking Retry like it instructs; the window for choosing the Visual Studio version never appears.
It does not seem to be a permissions issue since I manually adjusted the permission of all the build directories with all permissions, with no changes. I'm also running Visual Studio with administrator privileges, and it makes no difference. Additionally I replicated the build process on an entirely different machine (Windows 10, as opposed to Windows 7) and the exact same error occurs, so I'm suspecting it's a CMake issue.
You need to set a different project as startup project (right click on your target executable project "someproject" and select "Set as StartUp Project" from the context menu). ALL_BUILD is a symbolic target and is not connected to an executable.
When I try to run a vs solution file, I cant do it with run elevated access...as that option is not showing up on right click.
There is no such option in VS. If your program requires UAC elevation to do its job then you have to ask for it in your program itself. So it will still operate correctly on the user's machine. Edit the manifest of your EXE project as described in this answer.
To debug such an app, Visual Studio needs to be elevated itself. It normally prompts you for that, but there's a bug in VS2013 that prevents that from working if the Visual Studio Hosting Process option is turned on. Avoid this bug, and the prompt, by starting VS elevated. Do so by right-clicking the shortcut and selecting "Run as Administrator".
In Visual Studio 2010, I'm adding a command by going tools -> customize -> commands. However, the changes I make there appear to be temporary. After I open Visual Studio another time, my command is not there.
How do I add a command so that it stays?
The problem probably comes from VS not having permissions to modify its settings, when running as a non-administrator, due to UAC limitations. I actually don't have this problem - on my Win7, VS10 settings stick even when running as regular user, but this might be an issue with specific installation settings.
Bottom line, running VS as administrator should remove the permissions limitations, and allow VS to store the modified settings properly.
I'm running Visual Studio 2008 on Windows 7 64-bit. I'm logged in as administrator, and I'm running it as administrator, but the program I'm working on fails with access denied when I call a restricted API. If run the program from Explorer with "Run as Administrator" it works.
I was under the belief that Visual Studio 2008 debugs programs with whatever rights Visual Studio 2008 itself is running with. As it stands I can't debug my application due to this, and I'm at a loss as to what's going on.
This works for Visual Studio 2012.
Create a manifest file: right click on the project and select "Add New Item", select "Application Manifest File". This will add a file named app.manifest to the project.
Edit manifest file: set attribute level for tag requestedExecutionLevel to requireAdministrator.
Now your program will always require admin privileges, wherever it is executed. If launched by Visual Studio debugger, it will prompt you for restarting Visual Studio as administrator, if needed.
It's best to run Visual Studio 2008 as administrator. Moreover, it's good to change your application's manifest settings to require administrator privileges. You will be prompted by the system to elevate to system administrator each time you start your application, and when running under Visual Studio 2008 the IDE will offer you the elevation before start of debugging.
To change the setting, open project properties and go to Configuration Properties → Linker → Manifest file → UAC Execution Level.
I found the answer. It turns out that it is, in fact, a manifest issue: by default if you have a manifest you need to set the appropriate administrator privilege.
The default is asInvoker, but that doesn't work if you need elevated privileges; you instead have to set it to requireAdministrator in the manifest properties.
Run Visual Studio 2008 as administrator.
I had a case where I put in the
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
settings (described by another answer at this post)........and did not work.
I found another tip (seen below)...and unchecking that option allowed my code to work.
Try going into the project properties, and under the "debug" tab,
uncheck "enable the Visual Studio hosting process" and see if that
fixes your problem.
(from https://social.msdn.microsoft.com/Forums/vstudio/en-US/b5c4da93-5d64-442e-af28-df6d10765538/debug-as-administrator?forum=vbgeneral)
So I needed the app.manifest settings AND the "uncheck".
My testing with Windows Vista and Visual Studio 2005 showed that when you use a host process, the behavior under the debugger depends only on how you launched Visual Studio and not on the manifest (or lack of manifest) of your application. When Visual Studio is launched elevated, the behavior depends only on the use (or not) of a host process, not on the manifest. This is probably still true with Windows 7 and Visual Studio 2008.
Also, have you tried launching the application outside Visual Studio and using Attach to Process?
When I start my process from Visual Studio, it is always created inside a job object. I would like to know how to turn this behaviour off. Any ideas?
I expect that it is created in a job object to be debugged. I want to place my program in a different job object.
It's not the hosting process. I'm talking about a Job Object. This is an unmanaged C++ application.
This happens when devenv.exe or VSLauncher.exe run in compatibility mode. The Program Compatibility Assistant (PCA) attaches a job object to the Visual Studio process, and every child process inherits it. Check if the job name (as reported by Process Explorer) starts with PCA. If so, PCA can be disabled as described in the link.
You can globally disable PCA using Run -> gpedit.msc -> Administrative Templates\Windows Components\Application Compatibility -> Turn off Program Compatibility Assistant -> Enable.
You can disable PCA for specific executables by adding a registry entry. For Windows 7, the appropriate registry key is HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant. In regedit, right-click that key, select New -> Multi-String Value, name it ExecutablesToExclude. Set the value to the full path of denenv.exe and VSLauncher.exe, on separate lines and without quotes. For me, these were:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe
C:\Program Files (x86)\Common Files\microsoft shared\MSEnv\VSLauncher.exe
A related issue, on Windows 7, is that executables you build in Visual Studio and run from Explorer (not Visual Studio or the command line) may run in compatibility mode, and again get job objects wrapped around them. To prevent this, your executable needs a manifest that declares compatibility with Windows 7, using the new Application Manifest Compability section. The link gives an example of a Windows 7 compatible manifest. The default manifest provided by Visual Studio 2010 does not include this Compatibility section.
I'm not aware of any ways to control this aspect of processes spawned for debugging by VS.NET. But there's a workaround, which is applicable to any situation in which VS.NET can't or doesn't start your process in the exact way you want:
Start your process (possibly using a wrapper EXE that runs as part of the post-build event), then attach to the newly started process using Tools/Attach to Process. If you break into the debugger as part of your startup code, this won't even be required (and you can also debug startup issues...).
I can't reproduce what you're seeing. I've created an unmanaged C++ application in both VS 2005 and VS 2008 and I have no problems associating that process to a new job object when starting the process in VS.
Are you sure the debugger is doing this?