调试C++ Windows服务时触发Access Violation写入异常（仅Debug模式）

咱们来一步步拆解你遇到的这个问题：Debug模式触发0xC0000005访问违例，Release却正常，换了VS版本后才暴露出来——其实这不是VS版本的锅，是代码里潜伏的bug被Debug模式的严格校验揪出来了，Release只是侥幸没触发而已。

最直接的根源：wcscpy_s的参数传错了！ #

看你代码里触发异常的这一行：

wcscpy_s( (PWCHAR)(buffer + dwBytesWritten), dwBytesToWrite - dwBytesWritten, computerName.c_str());

这里踩了一个宽字符串操作的经典坑：wcscpy_s的第二个参数是目标缓冲区能容纳的宽字符数量（要包含终止符），而不是字节数！

你现在传的dwBytesToWrite - dwBytesWritten是剩余的字节数，但computerName是wstring，每个字符占2字节。举个例子：如果剩余字节是20，那实际只能容纳10个宽字符，但你告诉wcscpy_s可以写20个宽字符，它就会往内存里写40字节，直接超出buffer的边界——Debug模式下VS的调试堆会立刻检测到这种越界写入，抛出异常；而Release模式没有这种严格校验，加上内存布局可能刚好“凑活”，所以没出问题，但这绝对是高危bug。

修复代码的正确写法 #

把第二个参数转换成宽字符数就行，最简单的方式是用字节数除以sizeof(WCHAR)：

size_t availableChars = (dwBytesToWrite - dwBytesWritten) / sizeof(WCHAR);
wcscpy_s( (PWCHAR)(buffer + dwBytesWritten), availableChars, computerName.c_str());

或者更精准一点，因为你之前已经算过computerName需要的字符数是computerName.size() + 1，直接传这个值也可以，但用剩余字节数转字符数的方式更稳妥，能避免前面的长度计算出错带来的连锁问题。

还要检查其他内存操作的正确性 #

虽然wcscpy_s是触发点，但咱们也得确认前面的字段写入有没有累加错误：

• 你计算dwBytesWritten的时候，USHORT加2、BYTE加1、LONGLONG加8，这些都是对的，但建议在Debug模式下加断点，每一步都看一下dwBytesWritten的数值，确认到wcscpy_s之前，剩余字节数确实等于(computerName.size()+1)*2加上后面mac地址的字节数。
• 另外，mac地址的长度计算：你写的是macAddresses.size() +1，要确认macAddresses本身有没有包含终止符，如果已经包含了，这里就多算了1字节，会导致整个buffer的总大小不够，也可能引发越界。

关于VS版本切换后才出问题的原因 #

你说之前VS2017正常，换VS2019后出现，回退也不行——这其实是因为VS2019的调试堆校验更严格，或者内存布局和VS2017不同。之前的越界行为在VS2017的Debug模式下，可能刚好写在了堆的空闲区域，没触发校验；但VS2019把这块区域标记为不可写，所以一越界就立刻抛出异常。说白了，代码本身一直有bug，只是之前没被发现而已。

给你几个Debug排查的小技巧 #

1. 用VS的内存窗口：在wcscpy_s之前打个断点，查看buffer的地址和实际分配的大小，再看buffer + dwBytesWritten的位置，对比computerName的长度，就能直观看到是不是越界了。
2. 确保开启/GS缓冲区安全检查：Debug模式默认是开启的，但如果之前改了项目配置，记得打开它，能更早发现这类越界问题。

内容的提问来源于stack exchange，提问作者idan