Now I asked this question directly with Microsoft here , here and here . Apparently, the problem is still arising in the current RC for VS2015 (see second link above).
In Visual Studio 2013, you can view several elements of the C array using a clock such as p, 10000 (where p is a double *, for example).
The following example shows a screenshot of part of such an array, as shown in the viewport, and of the same part of the array as CTRL-C and CTRL-V inserted into a text editor. Note that starting at element 25, the copy / paste values do not match the values in the viewport (which are correct).
[20] 1.0945579725021715 double [21] 0.99979213435791758 double [22] 1.0971002689671798 double [23] 0.99977802981060826 double [24] 1.1002739126009620 double [25] 0.99964664435140704 double [26] 1.1054689877466559 double [27] 0.99963245464284955 double [28] 1.1002149405804762 double [29] 0.99961125488418856 double [30] 1.0956742333763470 double
Until now, in my experiments, I tried to see the first few values, and the last few values were copied correctly, leaving the middle part of the array incorrect. This does not always go wrong. Often this works for the first array to be tested, but is not suitable for subsequent ones. Also, when this happens incorrectly, it seems that copying / pasting the values a second time leads to the correct result. It seems that the wrong numbers are usually the previous values of some elements of the array - what is copied to the clipboard is a mixture of the current and previous contents of the array. The arrays with which I see this have long elements with a length of 2000 s.
This suggests an incorrectly-invalid (that is, sometimes only partially updated) copy of the data used in the implementation of copying Visual Studio to the clipboard. My experiments convincingly show that the elements in the copy of the data transferred to the clipboard are updated if and only if these elements (or sufficiently "close" elements - it seems that they can have the size of the "paging block") were shown on the screen, In particular, scrolling the array one page at a time leads to the fact that copying will work correctly, and clicking from the top of the array to the bottom using the HOME and END keys will not update the middle part of the array into a copy, which is then displayed on the clipboard.
Indeed, if you set several hours in one array, you can get several answers, for example, this is data copied to the clipboard after three times getting to the same breakpoint. The first time I hit a breakpoint, I copy all the data, and all of them are correctly copied to the clipboard. The second time is heterogeneous. Unfortunately, I scrolled about 25% of the way through the clock window, enough to enter the yellow data into what ends up on the clipboard. Then I went back to the beginning of the clock window and continued execution until the third time the breakpoint hit. Then I selected all the data in the viewport and copied it using CTRL-A CTRL-C. As a result, the data is pink from the first moment the breakpoint was deleted. The data is yellow from the second time, and the data that has not passed the light is truly correct. Note that elements 0 and 1 of pink data do not even correspond to the sum of the array just above them! For brevity, I skipped elements 2-497 and 503-997.
Using various versions of VC ++ starting with 6, I had not seen such behavior before and could not immediately find a link to it on the Internet.
If you rely on this functionality when debugging something complicated, you can scratch one head, wondering about strange numbers for centuries, before realizing that they are misleading.
I am using Microsoft Visual Studio Professional 2013, version 12.0.31101.00 Update 4.
Has anyone else seen this and does anyone know more about this or know about a fix or workaround for it?