I'm using VS2017 (Enterprise) to build a project. I'm pretty new to VS and especially to setting up my machine for a big project, so please do let me know if you need more info.
A while ago, my build was working fine, all cpp files were compiling well. Then I made some changes to a few cpp files (harmless little changes). But after I restarted my machine, I keep getting a
D8050: failed to get command line into debug records
The full error message is:
D8050 cannot execute 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x86\c1xx.dll': failed to get command line into debug records projectnameC:\Users\username\Documents\reponame\projectname\cl 1
However, this seems to be a really outdated error. I can't find the official support doc for this error (when I click on the error code on VS, it leads me to the support main page) and all the S/O questions are from 3-4 years ago. This question's answer suggests changing the TMP variable, but this can't be found under Properties anymore.
Just fyi, my OS is Windows 8, and my computer shut down abruptly while the project was building (it's a borrowed laptop, battery is old). I'm wondering if that has anything to do with this issue.
Again, please let me know if you need more details (eg logs).
I was able to solve this by switching to a user with admin rights, I had a feeling this was something related to user-permission rights
I was suggested by a friend to do a clean build (clean + rebuild), but this also failed.
What did solve my problem was deleting and reinstalling VS all over again. This reset the program files folder for VS and my build is working again.
I did uninstall McAfee at the same time, because I saw somewhere that antivirus software might be disturbing the build, but I'm not sure if this affected the build.
I've googled pretty much but i can't seem to find any information on this..
I've cloned a project from github, it opens and builds no problem. it's also added to my start menu.
I can run the program from my start menu as if it was a "normal" program.
Now I have made some changes to the sources and built it, and the changes seem to be present in the installed version (which I start from start menu) just by themselves.
my question is: is that really the case? do UWP apps get installed and updated automatically? is there a way to NOT update my installed version with my release-build every time? it seems wrong, did I miss something? (did I maybe "install" the changes somewhere along the way without noticing/by double-clicking the executable etc.) and: can I replace the executable that is started in the start menu? I tried to find where it is stored/linked, but I couldn't find anything, as there is zero information in the start menu.
Or can I rely on the start menu version always being my latest release build?
I'm confused, if someone has any information on this, I'd be really happy. :)
You are correct whenever you build and run the app on the local machine using Visual Studio it gets deployed to the system apps from where you can run it. So each time you build and run with any changes they will be updated in the system installed app as well(Basically they are same)
If you want that these changes do not get reflected in the system's app then I think you can use Device emulators available in the Visual Studio.
I've recently bought a new tower and used third-party software to port across all my development tools (another story in itself), including VB 6.0, all my third-party tools, and Btrieve. The only problem I have with Btrieve is more an annoyance than anything. On this new tower, I have to remember to run my compiled application once before attempting to run it from inside the IDE or else it will not load, and subsequently return a corresponding error when it attempts to open the first file.
If anyone else has encountered this and knows how to fix it, I'd much appreciate it.
After checking this page on Wikipedia I realized that I needed to focus on two files: w32mkde.exe and wbtrv32.dll
By manually running the exe file, it would load the engine and my application would then run in the IDE, but I still had to manually start the exe. The desired and original behavior on my older machine was that running my program in the IDE would automatically launch the sever exe. From the Wiki page, I learned that it was wbtrv32.dll that was actually called by the program, which in turn would call the exe if needed.
I had recentl ported over my old machine to a new tower, and many of the ocx and dll files in \windows\syswow64 did not make it. There seems to be no pattern to which ones, but I had to re-register those as I found them. There must be some link there, because when I copied-over the W*.exe and W*.dll files from my production backup folder to the syswow64 folder, it suddenly worked again. Likely just a corrupt copy of the dll file. I believe the reason that the compiled version ran correctly is because those dll and exe files were installed to the application folder, and were apparently okay, but not being invoked when run from the IDE.
Hope this might help someone else some day.
I am using Visual Studio Community 2017 (C++) with default configuration on Windows 10 (64 bit).
I have a single CPP file and I am trying to compile it.
The problem is that the "build" works fine, it says success, but the expected exe file is just not created.
I spent a few hours now trying all the available options - release/debug, 64bit/32bit, empty project/console app and many settings changes as was advised on various forums - no luck.
Does anybody know what could be the problem? I just can't find a solution for this.
I found my executable in my projects folder called "Release" (for x32) and "x64/Release".
Although I didn't see them either the first time going through the folders looking for it.
Alternatively I found this site with standalone build tools:
http://landinghub.visualstudio.com/visual-cpp-build-tools
ps: for the pros, I am still a big noob, so I can't tell if that site and tools is of going to be of any use, or even right, to the person asking the question.
So atleast I have added it and is for him/her to decide if so. ;p
regards,
E Karaagacli
Using Visual Studio 2010, when I build + run my application in short intervals I often get the following error. If I just wait a minute or two and try again it works fine. Unlocker claims no handle is locking the executable file. How can I discover what's locking it? If it's Visual Studio itself, what should I do to make it stop? or alternatively to release the file?
1>------ Build started: Project: MyProj, Configuration: Release Win32 ------
...
1>InitializeBuildStatus:
1> Creating "Release\MyProj.unsuccessfulbuild" because "AlwaysCreate" was specified.
1>ClCompile:
1> All outputs are up-to-date.
1> SomeFile1.cpp
1>ResourceCompile:
1> All outputs are up-to-date.
1>LINK : fatal error LNK1104: cannot open file 'D:\...\MyProj.exe'
1>
1>Build FAILED.
1>
1>Time Elapsed 00:00:00.94
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Had this issue after a reinstall today. Make sure the Application Experience service is started and not set to disabled. If its set to manual, I believe VS will start it.
I'm aware this is quite old but I just had the same problem with Visual Studio 2010 all patched up so others may still run into this.
Adding my project path to "Exluded Items" in my AVG anti-virus settings appears to have fixed the problem for me.
Try disabling any anti-virus/resident shield and see if it fixes the problem. If so, add your project path to excluded directories in your AV config.
You probably had a stray build process that was locking the executable, and it (the stray process) didn't get cleaned up. In that case, shut down visual studio, open up process explorer, and nuke every process you can find that is related to visual studio.
Then open up visual studio again and try rebuilding your project.
the file can be locked because it is being run now. Try killing the process with a task manager.
Like Jonathan said, yes, renaming can help to work around this problem. But ,e.g. I was forced to rename target executable many times, it's some tedious and not good.
The problem lies there that when you run your project and later get an error that you can't build your project - it's so because this executable (your project) is still runnning (you can check it via task manager.)
If you just rename target build, some time later you will get the same error with new name too and if you open a task manager, you will see that you rubbish system with your not finished projects.
Visual studio for making a new build need to remove previous executable and create new instead of old, it can't do it while executable is still runinng. So, if you want to make a new build, process of old executable has to be closed! (it's strange that visual studio doesn't close it by itself and yes, it looks like some buggy behaviour).
It's some tedious to do it manually, so you may just a bat file and just click it when you have such problem:
taskkill /f /im name_of_target_executable.exe
it works for me at least.
Like a guess - I don't close my program properly in C++, so may be it's normal for visual studio to hold it running.
ADDITION:
There is a great chance to be so , because of not finished application. Check whether you called PostQuitMessage in the end, in order to give know Windows that you are done.
You might have not closed the the output. Close the output, clean and rebuild the file. You might be able to run the file now.
I've concluded this is some kind of Visual Studio bug. Perhaps C Johnson is right - perhaps the build process keeps the file locked.
I do have a workaround which works - each time this happens - I change the Target Name of the executable under the Project's properties (right click the project, then Properties\Configuration Properties\General\Target Name).
In this fashion VS creates a new executable and the problem is worked around. Every few times I do this I return to the original name, thus cycling through ~3 names.
If someone will find the reason for this and a solution, please do answer and I may move the answer to yours, as mine is a workaround.
I had the same problem, however using Codeblocks. Because of this problem i quited programming because everytime i just wanted to throw my computer out of the window.
I want to thank user963228 whos answer is really a solution to that. You have to put Application Experience on Manual startup(you can do it by searching services in windows 7 start menu, and then find Application Experience and click properties).
This problem happens when people want to tweak theyr windows 7 machine, and they decide to disable some pointless services, so they google some tweaking guide and most of those guides say that Application Experience is safe to disable.
I think this problem should be linked to windows 7 problem not VS problem and it should be more visible - it took me long time to find this solution.
Thanks again!
Just to add another solution to the list, what I've found is that Visual Studio (2012 in my case) occasionally locks files under different processes.
So, on a crash, devenv.exe might still be running and holding onto the file(s). Alternatively (as I just discovered), vstestrunner or vstestdiscovery might be holding onto the file as well.
Kill all those processes and it might fix up the issue.
I have just run into the same issue with VS2013, creating device drivers in C++ , and none of the above seemed to fix the issue. However, I have just discovered that in my case the issue appears to have been VMWare-related.
I was running a VMWare workstation client with a shared folder defined on the VM on my entire C: drive. When I disabled the shared folders on the VM Settings, VS2013 was able to happily build my .exe files.
My new process is:
1) Disable the shared folder on the vm (VM Settings | Options | Shared Folders - and uncheck the checkbox)
2) Run the build on the host PC
3) RE-enable the shared folder (and proceed from there)
Hopefully this might help someone else.
(BTW, the errors you receive are that the .exe (or other files) are locked or require Administrator permission, but that is a red herring - It seems to me that the VMWare share is causing those files to appear as locked.)
Usually, this means that your program is locked and might not be killed through task manager or process explorer. I met a similar case that my program had an exception during running and triggered the windows error reporting which locked the program. For the case that windows error reporting locks the program, you can go to control panel->System and Security->Action Center->Problem Reporting Settings to set "Never check for solutions". Hope it helps.
For me it was happening, when I was trying to build in debug mode, but it was working fine in release mode. I changed the build configuration in the visual studio from x86 to x64 and it worked fine for me, as I was running on 64 bit system.
I just had this issue in VS22 - I think I closed the debugger right when it was compiling. All I had to do was restart my computer.
The error comes (at least sometimes) from paths that are too long. In my project simply reducing the output file path does the job:
"Properties/Configuration Properties/General/Intermediate Directory"
Seems that I have hit the 250 character path limitation.
Working with Bjarne Stroustrup Programming Principles and Practice Using C++ "FLTK" example i got the same error but after like 1 hour i got an idea, i tracked one of the libs already seen in Project Properties -> Linker -> Input -> Additional Dependencies, in my case i tracked the kernel32.lib to see where was located and saw there were many kernel32.lib's in different folders. So i started copy the FLTK libs in those folders and the last one i tried worked. Visual Studio 2013 Express found the fltkd.lib and the code worked.
In my case the correct route was C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x86
I don't know how to set that route inside Visual Studio.
Not sure if that Windows kits folder was created when i installed Microsoft Windows SDK for Windows 7 and .NET Framework 4 (ISO) http://www.microsoft.com/en-us/download/details.aspx?id=8442
Hope that helps you people.
I just had thesame problem. With me the exe was still running but I could not end it with the Task Manager. Just by restarting VS, it worked for me.
Mine is that if you set MASM listing file option some extra selection, it will give you this error.
Just use
Enable Assembler Generated Code Listing Yes/Sg
Assembled Code Listing $(ProjectName).lst
it is fine.
But any extra you have issue.