Solved

Visual Studio 2015 locks debug executable

Posted on 2016-07-16
9
244 Views
Last Modified: 2016-07-18
Microsoft's Visual Studio Professional 2015 has a nasty tendency to lock the executable in debug and refuse to recompile. This happens whenever any change is made in source code (C++ console programs) while at a breakpoint in debug. Sometimes closing Visual Studio and restarting is enough. More often, I have to restart the computer.

Is there any setting in Visual Studio that has a bearing on this behavior? Is there a way to stop it, short of paying $399 for an incident report to Microsoft?
0
Comment
Question by:StMike38
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
9 Comments
 
LVL 63

Expert Comment

by:Fernando Soto
ID: 41715796
This can happen while debugging if you open a resource such as a file on the file system and the program is terminated for some reason before closing the resource. See if that is happening in your case.
0
 

Author Comment

by:StMike38
ID: 41716003
Making any change in one of the .cpp source files triggers the locking. In earlier versions of Visual Studio it was possible (and very convenient) to type in changes while still able to refer to memory, watch, and other debug files. Visual Studio 2015 is behaving differently. Did Microsoft really intend to lock the executable and force a reboot? Surely there is some way around this.
0
 
LVL 63

Expert Comment

by:Fernando Soto
ID: 41716036
So are you saying that starting Visual Studio opening a project then modifying a source file and then compiling the project without doing anything else will cause the issue? Is that correct?
0
PeopleSoft Has Never Been Easier

PeopleSoft Adoption Made Smooth & Simple!

On-The-Job Training Is made Intuitive & Easy With WalkMe's On-Screen Guidance Tool.  Claim Your Free WalkMe Account Now

 

Author Comment

by:StMike38
ID: 41716044
The key point: The phenomenon occurs only when in debug and stopped at at a breakpoint. If (while still in debug), one changes a single keystroke in any source file, the locking feature kicks in.
0
 
LVL 63

Expert Comment

by:Fernando Soto
ID: 41716046
To my first post has the program have a resource such as a file open?
0
 

Author Comment

by:StMike38
ID: 41716089
Just ran a test. No programs open except Visual Studio 2015. Ran in debug a console program with multiple .cpp source, but only one source file open. Ran to a breakpoint. Typed a few keystrokes near the breakpoint line in the code. Ran the compile. Message "fatal error LNK1168: cannot open E:\Data\epub\EpubHdgs\Debug\EpubHdgs.exe for writing". In other words, no files were open except the one source code.
0
 
LVL 22

Accepted Solution

by:
ambience earned 500 total points
ID: 41717079
When the executable is open for debugging it cannot be overwritten, which is what the LINKER is complaining about. This is pretty normal, when you try the regular build. I maybe forgetting but you can edit and just continue debugging and the code change will be applied automatically.

What you are trying to do should be covered by the Edit & Continue settings. See if thats enabled in the Settings. I think Deubg -> Options & Settings is the place to check.

https://msdn.microsoft.com/query/dev12.query?appId=Dev12IDEF1&l=EN-US&k=k(VS.ToolsOptionsPages.Debugger.ENC)&rd=true
0
 
LVL 34

Expert Comment

by:sarabande
ID: 41717119
This is pretty normal, when you try the regular build.

i don't think it is normal. normally, - if edit and continue was not enabled - the Debugger asks whether you want to stop the program to be debugged. then you only have the choice to continue (with the new code ignored) or to stop and build.

if edit and continue was enabled you have to proceed with f5 or f10 to invoke the internal compiler.

you cant' use compile or build from build menu while debugging.

i assume the executable you were debugging is not the output target of your project build. that would explain why the build was started while you were debugging without getting asked before.

Sara
1
 

Author Closing Comment

by:StMike38
ID: 41717319
Locking diminished considerably with "Enable Edit and Continue" checked. I took the further step of unchecking the sub box  "Apply changes on continue". With those two changes, I have had no recurrence of locking.

Many thanks.
0

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Entering a date in Microsoft Access can be tricky. A typo can cause month and day to be shuffled, entering the day only causes an error, as does entering, say, day 31 in June. This article shows how an inputmask supported by code can help the user a…
Although it can be difficult to imagine, someday your child will have a career of his or her own. He or she will likely start a family, buy a home and start having their own children. So, while being a kid is still extremely important, it’s also …
Viewers will learn how to properly install Eclipse with the necessary JDK, and will take a look at an introductory Java program. Download Eclipse installation zip file: Extract files from zip file: Download and install JDK 8: Open Eclipse and …
In this fifth video of the Xpdf series, we discuss and demonstrate the PDFdetach utility, which is able to list and, more importantly, extract attachments that are embedded in PDF files. It does this via a command line interface, making it suitable …

733 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