In Visual Studio 2015 RTM we announced Edit and Continue (EnC) support for both X86 and X64 C++ in the default Debug Engine with the VC++ 2015 toolset (v140). Over the past couple months, we’ve been working on improving the experience and supporting new configurations. In this blog post I’ll go over the improvements we made to C++ EnC for Visual Studio 2015 Update 1.
To quickly recap – Edit and Continue allows you to modify your code at runtime (while debugging) without the need to stop, recompile and start the app again! For instance, if you are debugging and notice an error in a function of your code while stopped at a breakpoint, you can modify your source file, hit Continue (a Go or Step command), and the debugger will apply your code changes to the debugged process and continue debugging with your new code! This can help speed up your Edit > Build > Deploy > Debug cycle. See our previous 2015 RTM post for further details.
2015 Update 1 EnC Improvements
- Support for Windows Store and DirectX Apps (supporting the /bigobj compiler switch): The VC++ 2015 toolset in Update 1 now supports the /ZI compiler switch (EnC switch) with /bigobj, which is enabled by default on Windows Store projects and DirectX apps.
- Support for binaries linked with /DEBUG:FASTLINK debug information: FASTLINK is a linker switch that speeds up build times (by leaving some debug information in the obj files rather than consolidating it all in the PDB), and the VC++ 2015 toolset in Update 1 now supports using EnC with FASTLINK binaries.
- Show a cancelable wait dialog during EnC: We now show a wait dialog notifying the user of the progress, keeps the UI responsive, and also supports cancelation.
- Notify user if a file was modified that doesn’t support EnC: A common complaint about EnC usability was the difficulty in diagnosing *why* an edit was being ignored by Visual Studio. This is usually due to a compiler or linker switch that is incompatible with EnC (such as not using the /ZI compiler switch or the /INCREMENTAL linker switch).
With Update 1, if a source file was modified during debugging but does not have the right configuration (such as incompatible compiler/linker switches), an error dialog is displayed with actionable information about why the edit isn’t supported.
For example, if the source file was compiled with /Zi (instead of /ZI), an edit will now fail with an error dialog and the following error (in the Error List or Output > Build):
You can choose to ignore the error by clicking “Ignore” in the error dialog.
- Reserving more memory to allow applying more edits to the binary: The memory reserved in the binary built with EnC options (/ZI compiler switch and /INCREMENTAL linker switch) has been increased to prevent the dreaded “Out of reserved address space in module [module name]” error message. With this change you will be able to make more edits before being forced to stop debugging to recompile the binary.
- Improve Instruction Pointer remapping to prevent Stale Code warnings: User feedback indicated a number of people were running into the “Could not determine new address in function X to remap the instruction pointer” warning. Here, the Instruction Pointer would not be remapped to the new (modified) code and would remain in the old (unmodified) code, and such a situation is called “Stale Code” (check out our previous 2015 RTM post for further details). We’ve made some improvements to this area to ensure that we figure out the right address to remap the IP and reduce our chances of ending up with Stale Code.
- Honorable mention – Fixed the “fatal error C1092: Edit and Continue does not support changes to data types; build required” false positive compilation error for unrelated changes: This was one of the top voted EnC bugs.
During EnC recompilation, the compiler would throw the warning “warning C4656: … data type is new or has changed since the latest build, or is defined differently elsewhere” which caused “fatal error C1092: Edit and Continue does not support changes to data types; build required” for unrelated changes. It was easy to run into this error with code using the STL.This was caused due to an false positive ODR violation and we’ve addressed this issue in Update 1 – this warning will no longer cause a fatal error during EnC recompilation.
Summary
Please let us know your feedback and what we can do to improve the experience in the comments below or through the Send Feedback feature in Visual Studio or via twitter.
Gone is my v12.0 build toolset after installing update 1.
On another machine, update 1 did not install on my WP 8.1 build machine, saying the 2015 Professional was installed and to uninstall it before installing Community. There was never a Professional version on that machine.
But nice about the rest. I suppose. I've not used E/C since the 2005 days mainly because 64-bit. Terribly long build times have got me back on board. For now.
It all sounds great, however without an upgrade path from 2013 I guess we'll never know for sure.
How does it perform when considering a "parallel" build (i.e. /MP + several MSBuild processes joke, still no global scheduler…)?
/Z7 used to be considerably faster than /Zi even though it writes a lot more data to the disk for the .obj files.
@Whifed and Mifed : Could you verify whether the Windows 8.1 and Windows Phone 8.0/8.1 Tools optional feature is selected after installing the Update? If it does not show up as selected, you may be able to workaround the issue by selecting that feature.
*In Add/Remove Programs (or Uninstall or change a program) in Control Panel:
1. Select "Microsoft Visual Studio <SKU> 2015", then click "Change"
2. In the Visual Studio Setup dialog, click "Modify"
3. Verify whether "Windows 8.1 and Windows Phone 8.0/8.1 Tools" is selected. If not, select that option and then click "Update".
–Daniel
Can anybody tell me where can I download the update1 iso？ I try to upgrade my vs2015 online but failed after 4 hours later.
E&C false positives are indeed identified and no longer cause the fatal C1092 error, but there is a new problem now: Any breakpoint that is placed in code that changes with E&C is no longer respected and code does not break there… this is in C++.
I'm afraid I'm still getting the C1092 errors in the same file as before, please can I assist you in getting this fixed it is vital for us.
My old E+C bug in Connect seems to have been deleted, should I create a new one, how can we move forwards?
This is the new error, shortened because it is really massive now
——– Edit and Continue build started ——–
manager_manager.cpp
c:perforce_datadevprojectsgamesfmbranchesfm2016maingamecodenews_itemsnational_team_news_items.h(1426): error C2220: warning treated as error – no 'object' file generated
c:perforce_datadevprojectsgamesfmbranchesfm2016maingamecodenews_itemsnational_team_news_items.h(1426): warning C4656: 'CLUB_INSTRUCTIONS_NEWS': data type is new or has changed since the latest build, or is defined differently elsewhere
c:perforce_datadevprojectsgamesfmbranchesfm2016maingamecodenon_player_job_application.h(57): warning C4656: 'NON_PLAYER_JOB_APPLICATION': data type is new or has changed since the latest build, or is defined differently elsewhere
c:program files (x86)microsoft visual studio 14.0vcincludexmemory(481): warning C4656: 'std::_Wrap_alloc<std::allocator<ITEM_TYPE_IN>>': data type is new or has changed since the latest build, or is defined differently elsewhere
with
[
ITEM_TYPE_IN=SICORE::S32
]
c:program files (x86)microsoft visual studio 14.0vcincludexmemory(493): note: see reference to function template instantiation '_FwdIt std::_Uninit_move<_Iter,_Iter,_Alloc>(_InIt,_InIt,_FwdIt,_Alloc &)' being compiled
with
[
_FwdIt=int *,
_Iter=int *,
_Alloc=std::_Wrap_alloc<std::allocator<SICORE::S32>>,
_InIt=int *
]
c:program files (x86)microsoft visual studio 14.0vcincludevector(1679): note: see reference to function template instantiation '_FwdIt std::_Uninitialized_move<_Iter,int*,std::_Wrap_alloc<std::allocator<ITEM_TYPE_IN>>>(_InIt,_InIt,_FwdIt,_Alloc &)' being compiled
with
[
_FwdIt=int *,
_Iter=int *,
ITEM_TYPE_IN=SICORE::S32,
_InIt=int *,
_Alloc=std::_Wrap_alloc<std::allocator<SICORE::S32>>
]
c:program files (x86)microsoft visual studio 14.0vcincludexmemory(481): fatal error C1092: Edit and Continue does not support changes to data types; build required
Project : error (null) : Build errors occurred.
——————— Done ———————-
On our projects both Edit and Continue and FASTDEBUG are still very unstable. Catch a breakpoint (if you are lucky enough not to get "unexpected error loading symbols"), type any character: Visual Studio hangs for a couple of seconds, then crashes.
The only working configuration is "normal" debug mode with Edit and Continue turned OFF.
I also get an IDE crash if I try and edit a source file while debugging when built using FASTLINK
I have logged via using the send feedback tool by attaching another instance of VS, but I didn't realise it was the fast link causing it then
2. In the Visual Studio Setup dialog, click "Modify"
There is no Modify unless I first Skip (the, wants to update).
3. Verify whether "Windows 8.1 and Windows Phone 8.0/8.1 Tools" is selected
That box is already checked.
I shall give the update a go from this Modify path. Somehow, it says 23 GB. Maybe I should have not picked amy Android boxes. Soon will see. Hate to have to download 23 GB only to back it out. But now that I think about it, it never started "Acquiring" yesterday. Today, so far, it is. Cam't tell from the progress bar under Acquiring: since that is already full, from the start.
Setup Completed!
All specified componetsn have been modified successfully.
So far, so good. Bytes in was more like 6.3 GB. Disk space I suppose was all that 23 GB meant.
yuguang: You can download the Visual Studio 2015 Update 1 ISO at http://www.visualstudio.com/…/download-visual-studio-vs – select Visual Studio 2015 > Visual Studio 2015 Update 1 under "Visual Studio Downloads" and select the "ISO" format.
Lefteris Kalamaras: Does the issue persist even with FASTLINK turned off? Can you shoot us a mail at vsdbgfb@microsoft.com with your repro steps (if you have any) so that we can investigate this?
edl_si, Barfy: In some cases, C1902 indicates a genuine ODR violation (modifying a lambda can cause this), and not a false positive. Is this being triggered by unrelated edits (such as a whitespace)?
Is there a chance you can share a project reproducing either this issue or the FASTLINK crash? You can contact us at vsdbgfb@microsoft.com.
Sorry I should have said, I've said it so many times I tend to think everyone is familiar, this a null-change just adding a space to the file.
I cannot give you a project because it only ever reproduces in extremely complex code bases as far as I can tell.
I can give you a preprocessed .i file, can you make anything from that?
Same goes for the fastlink crash, in a small sample project I just tried it didn't crash. Is there some way I can get a crash dump file for you?
@M&W : Did the successful completion of the update resolve the issue with the missing v12.0 build toolset?
I haven't been successful reproducing this issue on my machines (or provisioned Virtual Machines).
–Daniel
No, the v12.0 toolset is all gone. I had a while ago uninstalled 2013 and, like 2012 before, it left the tools there (so I get the new IDE, new tools, and still the old tools, but not the old IDE).
These were two separate machines (one wanted to first uninstall a non-existing vs2015 pro, and the other removed the v12.0 tools) so I wasn't expecting that miracle. It's all right, though, it wasn't in-progress with anything.
Next time, look at these updates this way: 100s-of-thousands-of-updates times half-a-day (at best). I look at it that way every time these things come around.
On the be-gone v12 toolset. I eventually noticed that my x64 debug build was made as x64 release. Matter of fact. my win32 debug was, too. So was my win32 release. Everything was building as x64 release.
The build manager showed everything set to release and x64. That's about 59 projects. All the same, across all configurations.
I managed to get them all the way they should have been, but it cost me two GPFs, and one offer of restoring the .sln file … with one from March 2012. I've seen it do that at least once before and the sln, while stale, was fine, and that was the case this time. The second GPF (event viewer output below) came after I finished each full change and pressed Close. The first GPF lost the changes, but that happened before I got to the Close button (and offered to use a 3.5 year old .sln saying the .sln was corrupt or some other "so sorry!").
This is using the SQLite VC.db if it matters. And all projects had to be switched to v14 from v12 (not installed).
After all that, it did build as expected/so far, so good.
Faulting application name: devenv.exe, version: 14.0.24720.0, time stamp: 0x564ea97e
Faulting module name: VCRUNTIME140.dll, version: 14.0.23506.0, time stamp: 0x563c4550
Exception code: 0xc0000005
Fault offset: 0x00002cc4
Faulting process id: 0xf38
Faulting application start time: 0x01d12da4fa45acca
Faulting application path: D:vs2015Common7IDEdevenv.exe
Faulting module path: C:WINDOWSSYSTEM32VCRUNTIME140.dll
Report Id: 7e701be3-9999-11e5-81dd-001cc08f9c8a
Faulting package full name:
Faulting package-relative application ID:
Application: devenv.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: exception code c0000005, exception address 72F32CC4
Stack:
Faulting application name: devenv.exe, version: 14.0.24720.0, time stamp: 0x564ea97e
Faulting module name: VCRUNTIME140.dll, version: 14.0.23506.0, time stamp: 0x563c4550
Exception code: 0xc0000005
Fault offset: 0x00002cc4
Faulting process id: 0x33fc
Faulting application start time: 0x01d12d8b26902a92
Faulting application path: D:vs2015Common7IDEdevenv.exe
Faulting module path: C:WINDOWSSYSTEM32VCRUNTIME140.dll
Report Id: 32037bc8-9998-11e5-81dd-001cc08f9c8a
Faulting package full name:
Application: devenv.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: exception code c0000005, exception address 72F32CC4
Stack:
Turning on EnC (/ZI) seems to fail to correctly compile some functions. Pointers and references go out of scope at the wrong times.
mystruct* a = getA();
for (int i; i < 5;i++)
{
DoSomething();
} // a becomes null struct here.
a->Foo(); //access violation exception
@Ben L: I'm unable to reproduce that issue with a simple hello world app – could you provide us with some more context about how you run into it? Or perhaps could you share any sample code that repros the problem? You can contact us to vsdbgfb@microsoft.com.
I'm just concerned about the freedom of use of fonts on my computer as I did on Windows 7. That's all.
Just as user 'edl_si', we are still plagued by C1092 (in completely unrelated/unchanged object files), encountered even after only adding a single whitespace character. I've also seeing the IDE crash when applying code changes in E&C.
One additional annoyance is that we are compiling with /WX but E&C produces quite a few C4656 warnings which in turn cause E&C to fail.. now we can either use /WX- (I really don't like that) or suppress C4656 (also suboptimal). I wonder if it would be possible to specify that certain warnings get ignored during a debugging session? Or that /WX does not apply during debugging?
We are developing a complex (game) project, and are using the x64 compiler/debugger exclusively