Visual Studio 2013 C++ watch window: arrays copy incorrectly to clipboard

Question

I have now raised this question directly with Microsoft here, here and here. Apparently the issue still arises in the current RC for VS2015 (see second link above).

In Visual Studio 2013 it is possible to view multiple elements of a C array using a watch like p,10000 (where p is a double * for example).

In the example below I show a screenshot of part of such an array as seen in the watch window and the same part of the array as CTRL-C copied and CTRL-V pasted into a text editor. Note that from element 25 onwards the copy/pasted values are not in line with those in the watch window (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

So far in my experiments I tend to see the first few values and the last few values are copied correctly leaving a middle section of the array which is incorrect. It does not always go wrong. Often it works for the first array inspected but goes wrong for the subsequent ones. Also when it goes wrong it seems that copy/pasting the values a second time sometimes leads to a correct result. It appears that the incorrect numbers are generally the previous values of some of the elements of the array - what is copied to clipboard is a mixture of the array's current and previous contents. The arrays I'm seeing this with are 2000-plus elements long.

This is suggestive of an incorrectly-invalidated (i.e. sometimes only partially updated) copy of the data being used in Visual Studio's implementation of the copying to clipboard. My experiments strongly suggest that elements in the copy of the data rendered to clipboard are updated if and only if those elements (or sufficiently "nearby" elements - it appears there could be a "paging block size" involved), have been shown on screen. In particular scrolling through the array a page at a time seems to cause copying to work correctly while flicking from the top of the array to the bottom of it using HOME and END keys does not lead to the the middle section of the array being updated in the copy which then gets rendered to clipboard.

Indeed if one sets up multiple watches on the same array one can get multiple answers, for example this is the data copied to clipboard after hitting the same breakpoint three times. The first time the breakpoint is hit I copy all the data and it all gets copied to clipboard correctly. The second time is patchy. Crucially I then scrolled down about 25% of the way through the watch window, enough to inject the yellow data into what ends up on the clipboard. I then returned to the start of the watch window and continued execution until the third time the breakpoint is hit. I then selected all the data in the watch window and copied it using CTRL-A CTRL-C. The result is that the data in pink is from the first time the breakpoint was hit. The data in yellow is from the second time and the unhighlighted data is actually correct. Note that elements 0 and 1 of the pink data are even out of line with the summary of the array just above them! I have omitted elements 2-497 and 503-997 for brevity.

Having used various VC++ versions from 6 onwards I have not previously seen such behaviour and have not immediately been able to find a reference to it on the web.

If one is relying on this functionality when debugging something complex one can scratch one's head wondering about the strange numbers for ages before realising one is being misled.

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 it or know of a fix or workaround for it?

Answer 1

Various colleagues also see this. Apparently it affects Visual Studio 2015 editions also.

As I write Microsoft have apparently accepted the bug report and replicated the issue but haven't yet indicated a timetable or plan for a fix.

A workaround is to scroll through all the data in the watch window which one wishes to copy before copying it. Seemingly what is shown is updated but what has not been shown is not necessarily up to date at the point one copies the data.

Update (Feb 2018)

The simple repro below now works correctly in Visual Studio 2017. So it looks like the bug is fixed, albeit the copy stage takes aeons and a pop-up window appears while 10000 lines of text are created on the clipboard. It was much quicker (and worked correctly) until and including Visual Studio 2010.

Have a watch on a and expand it. Ctrl-A, Ctrl-C means select and copy everything in the watch window.

int a[10000];
for (int i=0; i<10000; ++i)
    a[i] = i;

(void)a[0]; // breakpoint here, Ctrl-A, Ctrl-C, paste somewhere

for (int i=0; i<10000; ++i)
    a[i] += 100;

(void)a[0]; // breakpoint here, Ctrl-A, Ctrl-C, paste somewhere

Visual Studio 2013 and 2015 will give you something like this

-       a   0x00ef5af4 {100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, ...}  int[10000]
        [0] 100 int
        [1] 101 int
        [2] 102 int
        [3] 103 int
        [4] 104 int
        [5] 105 int
        [6] 106 int
        [7] 107 int
        [8] 108 int
        [9] 109 int
        [10]    110 int
        [11]    11  int // Oops. The line it goes wrong on depends
        [12]    12  int // on the number of visible lines in the
        [13]    13  int // watch window.
...