C++ Edit and Continue in Visual Studio 2015

We previously announced that we were working on support for Edit and Continue for both x86 and x64 in the default debug engine in Visual Studio 2015. Today we’re pleased to announce that Edit and Continue (EnC) is enabled by default in Visual Studio 2015 RTM. As a quick reminder, EnC enables you to make changes to your code when you’re stopped in the debugger, and have those changes applied when you continue execution without the need to stop debugging, recompile and run the application back to that location.

In Visual Studio 2015 we’ve made great progress on satisfying this top customer request, so in this post I’ll walk you through the current state of Edit and Continue including what doesn’t currently work and when we hope to enable it.

How do I use Edit and Continue?

Edit and Continue will work with the default project and debugging settings for new C++ apps, but there are a few things to check since projects created with older versions of Visual Studio might not have the correct settings. If you upgraded a machine from a previous build of Visual Studio 2015 (e.g. you installed RTM on top of RC as opposed to uninstalling the previous build and then installing RTM) the debugger setting will not be enabled by default:

• The Debug Information Format needs to be set to “Program Database for Edit and Continue (/ZI)”. If this option is incorrectly set the debugger will ignore the edit, it will be just like modifying a file with edit and continue disabled.
  
  If you make an edit in a binary not compiled with this option, the debugger will ignore the edit and you will see an error message when you continue execution “The source file has changed. It no longer matches the version of the file used to build the application being debugged.”
• Enable Incremental Linking needs to be set to “Yes (/INCREMENTAL)”. Note: Using the linker flags /OPT:ICF, /OPT:REF, or /SAFESEH will disable incremental linking.
  
  If this option is incorrectly set and you try to make an edit while debugging you’ll see an error message along the lines of “Edit and Continue : error : Failed to map memory for the edit on the debugged process. Out of reserved address space in module [some module path]”
• Enable Native Edit and Continue needs to be enabled under Debug -> Options: This should be enabled by default in 2015 RTM but if Edit and Continue is not working check the setting. Additionally as previously announced it remains our long term plan to unify this setting into the single “Enable Edit and Continue” checkbox
  

If those three things are correctly set, you should be able to use Edit and Continue with your x86 or x64 project with the exception of the known limitations in the following section.

Known Limitations

While we continue to work hard to improve the Edit and Continue experience, here a few important limitations to note regarding what doesn’t currently work and our plans around the limitations:

• Editing binaries compiled with /bigobj (e.g. this is used for Windows Store apps). If you try to make an edit in a binary compiled with /bigobj you’ll receive an error message stating that “Edits were made which cannot be compiled” (the output window will contain the error message “cl : Command line error D8016 : '/bigobj' and '/ZX' command-line options are incompatible”). You’ll then have the option to go back and manually modify the file, ignore, or have Visual Studio revert (undo) all of your changes. This is something we plan to fix in a future update to Visual Studio 2015.
• Editing binaries linked with /DEBUG:FASTLINK debug information. If you attempt to make an edit in a binary compiled with this you’ll receive an error message “Edit and continue is not supported for this binary. The binary was linked with /DEBUG:FASTLINK which is not currently compatible with edit and continue. Use /DEBUG instead”. This is something we plan to fix in a future update to Visual Studio 2015.
• Binaries support a limited number of edits: In order to support Edit and Continue the compiler reserves empty space in the binary that updated code is written into when edits are made (the /ZI flag is what tells the compiler to do this). That means it is possible to fill up the reserved space after multiple edits (the space used by each edit will depend on the scope and magnitude of the edit, it’s not deterministic simply based on a supported number of edits). If you run out of reserve space in the binary you’ll see the error message “Failed to map memory for the edit on the debugged process. Out of reserved address space in module '[module name]'.”. We plan to add the ability for you to increase the reserved space if needed in a future update to Visual Studio 2015.
• Edit and Continue is not compatible with optimized code: EnC is not currently supported in binaries compiled with optimizations. We are working on a workaround to unblock this scenario in a future update to Visual Studio 2015.
• Adding or modifying global or static variables. If you try this you will see an error message that “Edits were made which cannot be applied while debugging”. You’ll then have the option to go back and manually modify the file, ignore, or have Visual Studio revert (undo) all of your changes. Support for this is not currently scheduled.
• Editing binaries linked with Safe Structured Exception Handlers (/SAFESEH). If you try to make an edit with this incorrectly set, you’ll see an error message along the lines of “Edit and Continue: error : Failed to map memory for the edit on the debugged process. Out of reserved address space in module [some module path]”. Support for this is not currently scheduled.

Stale Code

If you make an edit in a location that supports Edit and Continue but for some reason the edit cannot be applied you’ll see the message “Changes were made that could not be applied. The debugger will show you the original source code that is currently executing”

The debugger will then open a read only version of the original source file so you can see the actual code that is executing.

There are several situations where you can encounter the stale code scenario:

• If the edit was not able to be compiled you’ll continue to see the original source file in the stale code editor for the remainder of your debug session. For example, this will happen if your edit results in a compilation error (the error list will show you the compiler error).
• If the edit was successfully compiled but the debugger was not able to update the process to execute the new code rather than the originally compiled version. If this happens you’ll see the stale code editor while that function continues to execute, the next time the function is called the updated code will execute and you’ll return to the standard editor and continue to have the ability to make additional edits. For example, this can happen if you add or remove a local variable that requires construction or deletion earlier in code execution than the current instruction pointer location (indicated by the yellow arrow in the breakpoint margin).

Summary

In summary, we discussed that Edit and Continue is now available for C++ applications including x64 without the need to change debug engines which means you still have access to features like natvis and async call stacks while using EnC! Additionally, we looked at the limitations with the feature in Visual Studio 2015 RTM and which ones we plan to address. Please try out the capability and let us know how it is working for you in the comments section below, through Visual Studio’s Send a Smile feature, or send us a tweet.