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.
Related
We have a legacy Visual Studio 2003.NET C++ DLL project. Still works with VS2003 on Windows 10 but we're looking to migrate to VS2019.
In VS2003 when you debug (F5), the box Executable for Debugging Session pops up. In the Executable file name box you select Browse... and navigate to the .EXE which will consume your DLL. Great!
But how to do the same in VS2019? Whenever I debug, Visual Studio thinks I'm using the Local Windows Debugger and I get the error "[PATH][PROJECT].dll is not a valid Win32 application". The Debug > Attach to Process... option is not right either because my target executable is not running yet.
If I'm understanding the problem correctly, I think you want to select the Debugging section of your DLL project's property pages. There you can choose which debugger to use and you can even set the executable you want to launch.
Our previous development systems used Windows XP and Windows 7. Debugging C++ DLLs from Visual Studio worked great.
A recent move to Windows 10 has resulted in an annoying problem. We can debug once (using F5), but the 2nd time results in a linker error:
MyProg fatal error LNK1201: error writing to program database 'MyProg.pdb'
Trying to delete the .pdb manually in Explorer while Visual Studio is still open results in the error:
The action can't be completed because the file is open in devenv.exe
It doesn't matter whether you hit a breakpoint or not. Just start debugging once results in the problem. Re-starting Visual Studio resolves the issue (in the sense that you can debug once, but then you get the problem again).
If relevant:
x86 Visual Studio 2003.NET
targeting another x86 application
x64 Windows 10 Pro v1803
After hunting around for several hours some related, but unanswered, questions were found. Following suggestions in this MSDN article, along with some debugging of my own, this solution works:
Download FreePDB, a script written by MSDN user Toni76 (thanks Toni!)
Copy this script to a local folder (say C:\Apps\FreeDPB)
Download the latest version of SysInternals tool Handle (currently v4.21)
Copy handle.exe to C:\Apps\FreeDPB
NB! From the command line, run handle /? once. This is to agree the EULA. The script will not work if you skip this step!
Open Visual Studio, then Project > Properties > Build Events > Pre-Build Event
Set Command Line to C:\Apps\FreeDPB\freepdb $(ProjectName)
Set Description to Delete lock on PDB
...and now you don't need to restart Visual Studio to debug a 2nd time!
From comments, this works with multiple versions of Visual Studio on multiple versions of Windows.
Update
A more radical solution is described here which involves replacing a core Visual Studio DLL (NatDbgDE.dll). This solution only works for Visual Studio 2003 SP1, though.
In my case it was due to "Process Explorer" program, which was open alongside with my Visual Studio(I used it to check some properties of the exe I've created). After closing it problem solved.
I've a solution which is ported from VS (Visual Studio) 2010 to VS2017 from one machine to another. I could debug while I can't. I need to know what's the problem. When running, I see the breakpoint marks get changed to include a warning, but I can't find what can be wrong. It seems that everything is ok.
1) Try to rebuild the application. Make sure that it's in the "Debug" mode.
2) If it works fine in VS2010 but failed in VS2017, I wonder if Visual Studio gets confused the configuration of the correct code type, if so you may need manually selected the .NET version. If you are using Framework 3.5 in VS2010, but on Visual Studio 2017 you are using such as Framework 4.6, by default automatically determines the code types to debug (v4.6, v4.5, v4.0). In this case you need to click in "Select..." button on "Attach to process" window and select Managed (v3.5, v3.0, v2.0).
3) Try to clear/delete all breakpoints from the Debug menu, choose Delete All Breakpoints. The reason is that it refreshes your Visual Studio setting file of your project.
4) Potential Workaround: Uncheck "Require source files to match original versions ..." in Options, Debugging.
In my case, changing from "Release" Mode to the "Debug" mode works!
When you launch the process, if the breakpoint icon turns hollow with the warning symbol, then the debugger cannot figure out what part of the program corresponds to that line of the source code. This is typically because the build is out-of-date with the executable, DLL, or PDB file.
A common way to get into the this situation is to not notice that the build failed and then let the debugger try to run the old executable which doesn't correspond to the current sources. It can also happen if Visual Studio gets confused about some of the dependencies and doesn't rebuild everything that needs to be rebuilt (which can happen after significant changes to the solution and/or project file(s), e.g., after an upgrade).
In these cases, clean out the build directory and force Visual Studio to rebuild everything. This will usually get you back in sync.
When you set a breakpoint in DLL code, that breakpoint will appear in the hollow warning state until the DLL is loaded. If your program uses delay-loading or if it manually loads the DLL (e.g., via a LoadLibrary call), you will commonly see this. Once the DLL is loaded, any breakpoint icons in the DLL should return to the normal red-ball state. If it doesn't yet you think the DLL should have been loaded. Check the Output window in the debugger to see if it really was loaded and whether there were any warnings or errors about loading the corresponding symbols from that DLL.
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
A strange error:
error MSB8011: Failed to register output. Please try enabling Per-user
Redirection or register the component from a command prompt with
elevated permissions. C:\Program
Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets 744
I got this error when trying to use OpenSceneGraph (OSG) in an ActiveX control. A Google search showed all kinds of solutions which didn't really solve the problem or locate the exact cause of the error, so I'd like to put the solution in one place: Here.
I found the solution to it, and will be answering my own question soon, so that people can find their solution if they encounter the same problem.
This error happens when Visual Studio (2010) can't find the dependent dll files that are required by the program for creating the OCX. The OCX is created in the Debug directory of the project (for Debug builds), and specifying the "Working directory" (in project settings) as the folder where the dependent DLL's are, won't help Visual Studio in locating the DLL's.
Now the catch is (this is what makes it a headache to solve the problem) that sometimes, without Visual Studio being able to create the OCX, you won't be able to run Dependency Walker on the OCX. So you'll never figure out that the missing DLL's are the problem.
If you know which DLL's need to be placed in the Debug folder, just place them there, and the error will disappear.
If you don't know, and if your OCX didn't get created, then go to project settings > Linker > General > Register Output
and set the value to "No". This will create your OCX for you, but won't go through the process of registering it, which is when it needs the dependent DLL's.
Once you double-click the OCX and Dependency Walker shows you the missing DLL's with yellow circle icons, just place those DLL's in the same folder as the OCX, and your program will work fine. It's that simple.
The issue could be that your project tries to register a COM object, but there are not enough privileges to do that. On Windows 7 and 8 regsvr32 requires administrative permissions.
What you can do is the following. Create a shortcut on your desktop to C:\Windows\SysWOW64\cmd.exe (the 32-bit console). Right click, Properties -> Advanced -> check Run as administrator. Launch the shortcut, and make sure User Access Control pops up, and click Yes. Start building from this special console window.
I tried using run as "Administrator" VS 2015, it's able to solved the problem
MSB8011 seems to be a generic error raised whenever regsvr32 encounters a problem. In my case, regsvr32 exited with code 4 when Per-User Registration was set to "Yes", but the DLL I was building did not define a DllInstall entry point.
You can also do this via VS 2013 IDE by launching this IDE from program files shortcut, Select Visual Studio 2010/2013 and then right click and select run as administrator, after IDE launched, then open your solution file and build it, you will never get such errors because of regsrv32 DLL/COM registration
On the Property page go to
Configuration Properties->Build Events->Post-Build Event
you might be referring to it as a /Service. Modifying options as shown below could help.
Before modification:
After modification:
I fixed this in Visual Studio 2019 by going to "Properties -> Linker -> General -> Per-User Redirection" and setting it to True.