我现在已经在这里,这里和这里直接向微软提出了这个问题.显然,这个问题仍然出现在当前的VS2015 RC中(见上面的第二个链接).
在Visual Studio 2013中,可以使用p,10000等手表查看C数组的多个元素(例如,p是double*).
在下面的示例中,我显示了在监视窗口中看到的部分此类数组的屏幕截图,以及复制了CTRL-C并将CTRL-V粘贴到文本编辑器中的数组的相同部分.请注意,从元素25开始,复制/粘贴的值与监视窗口中的值不一致(这是正确的).

[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
Run Code Online (Sandbox Code Playgroud)
到目前为止,在我的实验中,我倾向于看到前几个值和最后几个值被正确复制,留下数组的中间部分是不正确的.它并不总是出错.它通常适用于第一个被检查的阵列,但后续的阵列出错了.此外,当它出错时,似乎第二次复制/粘贴值有时会导致正确的结果.看起来不正确的数字通常是数组中某些元素的先前值 - 复制到剪贴板的是数组当前和之前内容的混合.我看到的数组是2000多个元素.
这暗示了在Visual Studio的复制到剪贴板的实现中使用的数据的错误无效(即有时仅部分更新)副本.我的实验强烈建议,当且仅当这些元素(或足够的"附近"元素 - 它看起来可能涉及"寻呼块大小")已在屏幕上显示时,才会更新呈现给剪贴板的数据副本中的元素.特别是一次滚动数组一个页面似乎会导致复制正常工作,同时使用HOME和END键从数组顶部轻弹到底部不会导致数组的中间部分更新然后将副本呈现给剪贴板.
实际上,如果在同一阵列上设置多个手表,则可以获得多个答案,例如,这是在击中相同断点三次后复制到剪贴板的数据.第一次遇到断点时,我会复制所有数据,并将它们全部复制到剪贴板中.第二次是不完整的.至关重要的是,我通过观察窗向下滚动了大约25%,足以将黄色数据注入到剪贴板上的最终数据.然后我返回到监视窗口的开始并继续执行,直到第三次出现断点.然后,我选择了监视窗口中的所有数据,并使用CTRL-A CTRL-C复制它.结果是粉红色的数据是从第一次破坏点开始的.黄色数据是第二次,未突出显示的数据实际上是正确的.请注意,粉红色数据的元素0和1甚至与它们上方的数组摘要不一致!为简洁起见,我省略了元素2-497和503-997.

从6开始使用各种VC++版本我以前没有看到过这样的行为,也没有立即在网上找到它的引用.
如果一个人在调试复杂的东西时依赖于这个功能,那么在意识到一个被误导之前,人们可能会想到这个奇怪的数字.
我使用的是Microsoft Visual Studio Professional 2013,版本12.0.31101.00 Update 4.
有没有其他人看过这个,有没有人知道更多关于它或知道修复或解决方法呢?