问题
memcpy发生崩溃但没有详细的调用栈，日志辅助缩小范围到一个怀疑函数，但是内部嵌套有好几个调用memcpy的地方。
过程
A. 改用windbg使用!analyze -v分析后还是缺少调用栈。
B. 运行lm提示无符号：
C. 于是用!sym noisy开启符号加载过程的日志。
D. 手动加载模块及符号：.reload /f "FOO.exe"，注意这里模块名字最好带上引号。提示不匹配：
1
DBGHELP: C:\Program Files (x86)\Windows Kits\08\Debuggers\x86\sym\FOO.pdb\12345678901234567890123456789012\FOO.pdb - mismatched pdb
但实际上这里的exe和pdb是同时编译产生的。
E. 用!itoldyouso "FOO.exe" "C:\Program Files (x86)\Windows Kits\08\Debuggers\x86\sym\FOO.pdb\12345678901234567890123456789012\FOO.pdb"提示
1
Cannot read Image header @ 00b20000
chatgpt3.5回答的套话没用，试过stackoverflow的答案也无效，再次彰显闭源生态的枷锁。
寄存器
出于优化，编译器会在调用函数时优选通过寄存器传递参数，通过故意传递非法参数给memcpy做就能找到规律，最后发现崩溃时想要复制数据的长度是19360字节，这下就找到具体位置了。
结束
毋庸置疑，软件调试是一门好功夫，需要深度学习。回想以前天天和崩溃斗争，不得不大伙使用一些奇奇怪怪的办法，还有的伙伴因而离开。后来才发现，提高质量其实是最便宜的手段。
解决再多的难题也比不上没有问题，以及编写容易阅读、分析和定位的代码。