-
-
[原创]再战堆栈损坏:Critical error detected c0000374
-
发表于: 2024-10-31 10:04 1234
-
继分析堆栈损坏:Critical error detected c0000374再分析一案例。为什么对0xc0000374那么情有独钟呢?理由有:
- 崩溃点不在引起错误的代码位置
- 崩溃点随机。如果涉及线程,崩溃点更加随机
- 崩溃出的调用堆栈对调试工作基本没有太大用处
正文开始,程序运行崩溃,在输出窗口出现信息:
赤果果的发现了异常代码:0xc0000374,并且弹出窗口:
弹出的RDEmboss.dll是友商的模块,所以是否可以扔锅了呢?(奸笑)
鉴于之前有374的分析经验,所以个人还是先挑战一下。对于崩溃时读取内存位置跟踪一下:
咦,发现该地址之后的内存确实是无法访问的,但是,它临近的内存是有数据的,观其数据的形象,应该是图片数据的像素值。所以,怀疑这个内存可能是访问图片数据类似的数据,但是这里的内存可能又被释放或者没有申请过,总之,这里的内存不管之前是否有效,但是现在是无效了。于是接下来,观察了一下崩溃现场的变量数据,发现一个可疑的地址:
这个地址和崩溃地址是比较接近的,并且该地址对象是图片相关对象。于是,凭经验假设该地址其实是在遍历pShape->pDIBData的内存越界造成的崩溃。于是根据图片的宽高估算了一下,地址范围
发现确实是越界了。于是,顺着pDIBData查看生成该数据的相关代码,很快,发现了可疑代码:
原本这里应该是图片每行的像素个数,但是错用了cv::Mat的rows。最后,改成cv::Mat的cols,问题果然解决了。
总结:
- 观察崩溃时访问内存附近的数据,是否能猜测出数据的对象
- 虽然崩溃指向明确的模块,但是有可能是输入参数出现了错误
[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入!
最后于 2024-10-31 10:16
被_THINCT编辑
,原因:
赞赏
他的文章
- 重新认识线程sleep 797
- [原创]CPU爆高,程序卡顿分析 1660
- [原创]再战堆栈损坏:Critical error detected c0000374 1235
- [原创]在无用的堆栈中分析DLL版本错误 1314
- [原创]小白也能通过特征码定位源码 2747
看原图
赞赏
雪币:
留言: