精华内容
下载资源
问答
  • 2019-07-04 16:57:46

    现象:

    具体场景出现在new分配内存中,VS输出信息为: Critical error detected c0000374    在 X64正常,X86崩溃

    是在分配内存时发生的,但是这里是内核模式地址区域,堆管理器是不可能指定这个地址的.所以很明显,堆数据被溢出篡改了,即堆破坏问题.接下来就要寻找是哪里发生了数据溢出。

    分析:

    debug 看了一下,正常分配内存,一般来说造成这种情况的原因是数组越界了。

    如果不是这次造成的,哪么可能是上次内存赋值都越界了,造成了堆被破坏了。

    解决方案:

       查找代码中上个内存分配的位置,在长度加1,正常。问题解决。

    int Buflen  = 100;

    _PRTA(unsigned char,ScaleBuf,Buflen + 1);//

    这里是使用的智能指针;unsigned char,正常的话不需要存放结束符号,理论上这里不需要加1。

     

    总结:

      遇到这里问题,基本是内存赋值越界了, 查看一下上面的代码是不是这种情况;

    1.分配内存少 1,2.内存赋值越界,长度超了。如memset();

    更多相关内容
  • 而报错信息是“Critical error detected c0000374”,搜出来的文章也都是内存不足、越界之类,还有说用智能指针的问题,但以上问题我都没有。 当内存充足时,new还能报错,那应该是跟内存没多大关系了。加上在代码不...

    在使用QT写GraphicsView时,运行程序添加Item时,无缘无故报错了,debug调试也是跳到QT源码上面去,还都不是报同一个位置的错误,有些还是new的位置报错。而报错信息是“Critical error detected c0000374”,搜出来的文章也都是内存不足、越界之类,还有说用智能指针的问题,但以上问题我都没有。
    当内存充足时,new还能报错,那应该是跟内存没多大关系了。加上在代码不改或者一些毫无影响的改动的情况下,报错还不是在同一个地方,我觉得可以排除内存不足、越界之类。

    1. 但程序蹦绝大部分又是跟指针有关,所以我把我类里面的指针变量注释了,结果运行一点问题都没有,而且我这指针的还是只定义了还没用,连赋值nullptr的操作都没有,真的奇了怪了。如下例1代码
    //例1
    //.h文件
    class A{
    int a;
    int b;
    int *p;//注释了,运行就没问题,不注释运行就蹦,打印的错误信息“Critical error detected c0000374”
    int c;
    ...
    int z;
    }
    
    //.cpp文件
    A::A:a(0),b(1),c(2){}
    
    1. 我只把指针变量写在所有变量的后面,这么顺序一换,运行又没问题,我以为这就把问题解决了,结果只给这变量赋值nullptr就又蹦了。如下例2代码
    //例2
    //.h文件
    class A{
    int a;
    int b;
    int c;
    ...
    int z;
    int *p;
    }
    
    //.cpp文件
    A::A:a(0),b(1),c(2),
    p(nullptr)//注释就能运行,不注释运行就蹦,打印的错误信息“Critical error detected c0000374”
    {}
    
    1. 一开始怀疑是不是变量类型的问题,但后面换了其他类型一样不行。怀疑会不会是因为.cpp文件数据有问题,于是新建了一个.h和.cpp文件,打算重新写原本那文件的代码,结果就只写成类似如下的代码,就是只写了原本.h文件变量定义和构建函数,其他的都没写,运行没问题,然后我就重新试了之前有问题的.h.cpp文件,发现也可以运行,一点问题都没有,代码一点都没改过,后面也试了改成之前出问题的样子,结果也是没问题。这个过程只是将源代码重新构建生成了,将以前的编译生成的任何文件都重新生成了一遍。因为Qt添加新文件之后,要重新 执行qmake->构建/运行/重新构建(或者 清除->构建/运行/重新构建),这个过程就将以前编译生成的.obj、ui_xxx等文件都重新按照现在的代码去生成了。所以我怀疑是之前编译生成的相关文件有问题,导致出现了“Critical error detected c0000374”的问题
    //
    //.h文件
    class A{
    int a;
    int b;
    int c;
    ...
    int z;
    int *p;
    }
    
    //.cpp文件
    A::A:a(0),b(1),c(2),
    p(nullptr)
    {}
    

    根据上面的猜测,排除内存、越界之类和智能指针的问题,可以尝试的解决方案:1、将之前编译生成的文件全部清除,并将所有内容再重新编译生成一遍。
    2、将有问题的.h.cpp重新打一遍,最好别复制,避免文件数据有问题。复制有可能会把之前有问题的数据一起复制了。
    3、先做2,再做1

    展开全文
  • } 执行后,在vs输出错误信息: Critical error detected c0000374 2. 问题分析 引用一些来自stackoverflow中Freya301的错误分析思路: 通常错误来源于(malloc/new/其它内存申请)检测到了堆异常; 通常异常已经...

    (Owed by: 春夜喜雨 http://blog.csdn.net/chunyexiyu)
    参考:https://blog.csdn.net/q610098308/article/details/94630682
    参考:https://blog.csdn.net/weitaming1/article/details/84023789
    参考:https://stackoverflow.com/questions/23471161/critical-error-detected-c0000374-c-dll-returns-pointer-off-allocated-memory

    下面通过触发异常,崩溃堆栈分析,来看看异常发生的场景,以及如何来界定问题范围。

    1. 触发崩溃

    首先触发异常发生,先写一段会崩溃的函数,在main中进行调用
    int* test_heap_alloc()
    {
    int* pTable = new int(256); // 申请一个int结构体变量,初始值为256;
    for (int i = 0; i < 256; i++)
    pTable[i] = i;
    return pTable;
    }
    int main(int argc, char** argv){
    test_heap_alloc();
    return 0;
    }

    执行后,在vs输出错误信息:
    Critical error detected c0000374

    2. 问题分析

    引用一些来自stackoverflow中Freya301的错误分析思路:
    通常错误来源于(malloc/new/其它内存申请)检测到了堆异常;
    通常异常已经发生在之前的程序里;
    但是崩溃抛出延迟了,直到下次堆申请时才发生。
    sometimes its because malloc/new/whatever detects heap corruption,
    often this corruption has already occurred previously in the program,
    but the crash has been delayed until the next call to new/malloc.

    从这个崩溃来看,符合这个思路:

    1. 申请堆内存容量4字节,但使用时超出4字节使用,写入到了未申请的空间中;
    2. 下次申请/释放堆内存时会触发崩溃
    3. 如果没有再申请/释放,但此时程序结束,则在程序结束检查释放时发生了崩溃;

    3. 下次申请时触发的堆检测崩溃

    在test_heap_malloc中使用超申请堆内存,再次申请内存,崩溃在new char()位置上
    int main(int argc, char** argv){
    test_heap_alloc();
    char* p = new char(0); // 申请一个字节,内容初始化为0
    return 0;
    }

    汇编代码栈:
    00007FFB8ED4F1E0 je RtlReportCriticalFailure+65h (07FFB8ED4F1F1h)
    00007FFB8ED57F9D call RtlpReportHeapFailure (07FFB8ED5ACF8h)
    00007FFB8ED58285 call RtlpHeapHandleError (07FFB8ED57F90h)
    00007FFB8ED5DF0C call RtlpHpHeapHandleError (07FFB8ED58210h)
    00007FFB8EC7D761 call RtlpLogHeapFailure (07FFB8ED5DECCh)
    00007FFB8EC7B448 call RtlpAllocateHeap (07FFB8EC7D160h) —ntdll.dll
    00007FFB8CA0FDE0 call qword ptr [__imp_HeapAlloc (07FFB8CAB93C0h)] —ucrtbase.dll
    00007FF72007119E call malloc (07FF720071F84h)
    00007FF720071130 call operator new (07FF720071184h) --test.exe
    崩溃堆栈:
    ntdll.dll!RtlReportCriticalFailure()
    ntdll.dll!RtlpHeapHandleError()
    ntdll.dll!RtlpHpHeapHandleError()
    ntdll.dll!RtlpLogHeapFailure()
    ntdll.dll!RtlpAllocateHeap()
    ntdll.dll!RtlpAllocateHeapInternal()
    ucrtbase.dll!_malloc_base()
    test.exe!operator new(unsigned __int64 size) 行 35 C++
    test.exe!main(int argc, char * * argv) 行 93 C++
    [外部代码]

    4. 下次释放时触发的堆检测崩溃

    修改main代码,则崩溃发生在delete释放堆内存时
    int main(int argc, char** argv){
    int* p = test_heap_alloc();
    delete p;
    return 0;
    }

    汇编代码栈:
    00007FFB8ED4F1E0 je RtlReportCriticalFailure+65h (07FFB8ED4F1F1h)
    00007FFB8ED57F9D call RtlpReportHeapFailure (07FFB8ED5ACF8h)
    00007FFB8ED58285 call RtlpHeapHandleError (07FFB8ED57F90h)
    00007FFB8ED5DF0C call RtlpHpHeapHandleError (07FFB8ED58210h)
    00007FFB8EC760E0 call RtlpLogHeapFailure (07FFB8ED5DECCh)
    00007FFB8EC75B6F call RtlpFreeHeap (07FFB8EC75C00h)
    00007FFB8EC747AC call RtlpFreeHeapInternal (07FFB8EC75710h) —ntdll.dll
    00007FFB8CA0F055 call qword ptr [__imp_HeapFree (07FFB8CAB9398h)] —ucrtbase.dll
    00007FF7515110BD call operator delete (07FF751511140h) --test.exe
    崩溃堆栈:
    ntdll.dll!RtlReportCriticalFailure()
    ntdll.dll!RtlpHeapHandleError()
    ntdll.dll!RtlpHpHeapHandleError()
    ntdll.dll!RtlpLogHeapFailure()
    ntdll.dll!RtlpFreeHeap()
    ntdll.dll!RtlpFreeHeapInternal()
    ntdll.dll!RtlFreeHeap()
    ucrtbase.dll!_free_base()
    demo_snappy_test.exe!main(int argc, char * * argv) 行 95 C++
    [外部代码]

    5. 程序结束时触发的堆检测崩溃

    程序结束崩溃发生在代码:
    文件exec_common.inl,exit(main_result)行
    if (!__scrt_is_managed_app())
    exit(main_result);
    汇编代码栈:
    00007FFB8ED4F1E0 je RtlReportCriticalFailure+65h (07FFB8ED4F1F1h)
    00007FFB8ED57F9D call RtlpReportHeapFailure (07FFB8ED5ACF8h)
    00007FFB8ED58285 call RtlpHeapHandleError (07FFB8ED57F90h)
    00007FFB8ED5DF0C call RtlpHpHeapHandleError (07FFB8ED58210h)
    00007FFB8EC767D2 call RtlpLogHeapFailure (07FFB8ED5DECCh)
    00007FFB8EC75B6F call RtlpFreeHeap (07FFB8EC75C00h)
    00007FFB8EC747AC call RtlpFreeHeapInternal (07FFB8EC75710h) — ntdll.dll
    00007FFB8CA0F055 call qword ptr [__imp_HeapFree (07FFB8CAB9398h)]
    00007FFB8CA1432B call _free_base (07FFB8CA0F040h)
    00007FFB8CA141F6 call <lambda_f03950bc5685219e0bcd2087efbe011e>::operator() (07FFB8CA14230h)
    00007FFB8CA141AF call __crt_seh_guarded_call::operator()<<lambda_7777bce6b2f8c936911f934f8298dc43>,<lambda_f03950bc5685219e0bcd2087efbe011e> &,<lambda_3883c3dff614d5e0c5f61bb1ac94921c> > (07FFB8CA141C0h)
    00007FFB8CA2051D call _execute_onexit_table (07FFB8CA14180h)
    00007FFB8CA204A6 call <lambda_ad52fe89635f51ec3b38e9c3ac6dac81>::operator() (07FFB8CA204D4h)
    00007FFB8CA20449 call __crt_seh_guarded_call::operator()<<lambda_123965863b7b46a3332720573f9ce793>,<lambda_ad52fe89635f51ec3b38e9c3ac6dac81> &,<lambda_8d528b66de6ae1e796d7f5e3101fca72> > (07FFB8CA20470h) — ucrtbase.dll
    00007FF688B8140A call exit (07FF688B81FAAh) — test.exe
    00007FFB8DC6702E call qword ptr [__guard_dispatch_icall_fptr (07FFB8DCD3220h)] —kernel32.dll
    00007FFB8ECA264B call qword ptr [__guard_dispatch_icall_fptr (07FFB8EDD3000h)] —ntdll.dll
    崩溃堆栈:
    ntdll.dll!RtlReportCriticalFailure()
    ntdll.dll!RtlpHeapHandleError()
    ntdll.dll!RtlpHpHeapHandleError()
    ntdll.dll!RtlpLogHeapFailure()
    ntdll.dll!RtlpFreeHeap()
    ntdll.dll!RtlpFreeHeapInternal()
    ntdll.dll!RtlFreeHeap()
    ucrtbase.dll!_free_base()
    ucrtbase.dll!(void)()
    ucrtbase.dll!__crt_seh_guarded_call::operator()<<lambda_7777bce6b2f8c936911f934f8298dc43>,(void) &,<lambda_3883c3dff614d5e0c5f61bb1ac94921c> >()
    ucrtbase.dll!_execute_onexit_table()
    ucrtbase.dll!(void)()
    ucrtbase.dll!__crt_seh_guarded_call::operator()<<lambda_123965863b7b46a3332720573f9ce793>,(void) &,<lambda_8d528b66de6ae1e796d7f5e3101fca72> >()
    ucrtbase.dll!common_exit()
    test.exe!__scrt_common_main_seh() 行 295 C++
    kernel32.dll!BaseThreadInitThunk()
    ntdll.dll!RtlUserThreadStart()

    6. 小结

    a. 借助于这几个崩溃的汇编堆栈,可以看出来,存在堆溢出检查:

    • 在申请堆内存时,存在检查;
    • 在释放堆内存时,存在检查;
    • 在程序结束的时候,也会触发堆内存释放,存在检查;
      而检查点将会是一个识别点,在此时可能异常抛出,并触发了崩溃;

    b. 检查点并不是发生堆内存错误使用的点,错误使用点在检查之前发生的;

    c. 借助于申请/释放的堆检查特点,我们同样可以用于界定问题的代码行:
    例如可以通过在代码中添加内存申请来检测异常,例如添加多处new char(),来检测堆使用异常,在代码中识别异常的所在代码行;

    (Owed by: 春夜喜雨 http://blog.csdn.net/chunyexiyu)

    展开全文
  • 问题描述: 今天在写作业时发现了一个这样的错误,开始时还有些懵,好奇怪! 查了一些博客,发现都在说是堆栈溢出了,我确实new了内存,但是不至于溢出呀?? 解决方案: 后来在退出时,告诉我一个空间被损坏了,我...

    问题描述:

    今天在写作业时发现了一个这样的错误,开始时还有些懵,好奇怪!
    查了一些博客,发现都在说是堆栈溢出了,我确实new了内存,但是不至于溢出呀??

    解决方案:

    在这里插入图片描述在这里插入图片描述
    后来在退出时,告诉我一个空间被损坏了,我仔细看了看new的地方!
    在这里插入图片描述
    发现果然是自己写错了,不应为num_Vertex,而应该是2*num_Edge;
    改完后,问题解决!
    最后的最后,如何解决这个问题呢?当然上面是我的解决办法,通用性的做法:就是去查一下你程序中new的地方是否出问题了,new错了大小呢?(一般是new小了),为读者朋友们提供一种思路。

    欢迎评论区交流!

    展开全文
  • 1主要问题是内存越界。一个个好好查查 Ipp64f* pDstImlf = new Ipp64f[NN1]; memset(pDstImlf, 0, sizeof(Ipp64f) * NN1);
  • 具体场景出现在new分配内存中,VS输出信息为: Critical error detected c0000374 在 X64正常,X86崩溃 是在分配内存时发生的,但是这里是内核模式地址区域,堆管理器是不可能指定这个地址的.所以很明显,堆数据被溢出...
  • 我发现出现上述错误是 free 两次内存 float* dd=new float[2]; delete[] dd; delete[] dd; 转载于:https://www.cnblogs.com/hook-gou/p/9994662.html
  • 具体场景出现在new分配内存中,VS输出信息为: Critical error detected c0000374.也就是堆管理器尝试在0xc0000374这个地址分配内存,但是这里是内核模式地址区域,堆管理器是不可能指定这个地址的.所以很明显,堆数据被...
  • 项目场景 VS2017+QT 使用QTXlsx库 问题描述 在x64 Debug模式下,向excel表格中写入数字可以正常保存,但是一写入字符串再保存就会报错 Critical error detected c0000374 原因分析: 经过多次尝试,后在项目的属性-...
  • 调试报Critical error detected c0000374错误,发现只要屏蔽到RtmpRoad.h就没问题。百思不得其解。后来发现是这个.h文件有一个不匹配的边界对齐,导致的。 #pragma pack(1)  #define MAX_FRM_LEN (1024*2048) #...
  • 有未经处理的异常: 0xC0000374

    千次阅读 2020-04-24 15:02:31
    有未经处理的异常: 0xC0000374: 堆已损坏 关于处有未经处理的异常: 0xC0000374: 堆已损坏的问题, 调试不出错, 直接执行很大几率出错的问题, 最后的跟踪都是在delete的时候报错!. 我的解决方法: 在申请内存处, 申请...
  • 这几天调一个模块莫名其妙就遇到这个问题,碰了很多壁才解决了,所以写个博客记录一下。 按照其他博客的说法,是malloc了内存没有及时free的问题,但是因为我用了别人的库,所以改不了,所以我想了一个很粗暴的方法...
  • Java异常处理

    2021-03-13 12:53:59
    以前用C写数据结构的时候,总有这样一个烦恼:比如写栈的Pop函数,除了在函数体中完成出栈的操作,还要使用一个返回值,表示出栈操作是否成功进行。但是呢,为了将出栈的值返回给调用者,就要用return语句。但是...
  • python Process finished with exit code -1073740940 (0xC0000374) 在运行项目的时候报错:Process finished with exit code -1073740940 (0xC0000374) 解决方法:控制面板 - 时钟和区域 - 区域 - 管理 -非Unicode ...
  • Critical error detected c0000374 Windows 已在 turnover.exe 中触发一个断点。 其原因可能是堆被损坏,这说明 turnover.exe 中或它所加载的任何 DLL 中有 Bug。 原因也可能是用户在 turnover.exe 具有焦点...
  • XXX处有未经处理的异常: 0xC0000374: 堆已损坏,处有未经处理的异常: 0xC0000005: 读取位置 0x4F774B16 时发生访问冲突。 ** 出现该问题的场景是其他公司调用我们的sdk发现了这个问题,本来也以为是代码问题,导致该...
  • 执行基于pytest框架的自动化测试脚本报错:Process finished with exit code -1073740940 (0xC0000374) 最后解决方法: 1. 打开控制面板 -》 时钟和区域 -》区域, 2. 切换到‘管理‘, 点击【更改系统区域设置...
  • 当我们在某个函数中写malloc函数(C)或者new(C++)时,经常会出现 (ntdll.dll)(XXX.exe中)有未经处理的异常:0xC0000374堆已损坏的系统异常报错。 分析 起初我认为是VS的问题,但是实际上并不是,VS为我们提供的...
  • 0xc0000374 错误偏移量: 0x000cf70b 错误进程 ID: 0xdc8 错误应用程序启动时间: 0x01d1cce75a30b83c 错误应用程序路径: C:\Program Files (x86)\Microsoft Office\Office15\EXCEL.EXE 错误模块路径: C:\Windows\...
  • 最近遇到一个问题,win...代码:c0000374 模块:StackHash_423a 之后各种找原因,删除浏览器插件、更新补丁、regsvr32重新注册等等办法均无法解决, 在经历了三天的苦心寻找后终于寻找到解决办法,主要问题出现在"错
  • 一道动态规划的算法题.dp是我用new关键字分配的..."去释放内存出现exit code -1073740940 (0xC0000374)的错误,用的是gnu++11#include #include using namespace std;vector get_divisor(int num){vector vec;for (in...
  • 使用vs运行程序时我们有时候会看到这样的一个错误:“XXX处有未经处理的异常: 0xC0000374: 堆已损坏”。导致该错误产生的原因一般是是访问了未分配的地址,内存越界造成的,越界写了不该写的内存区域。 示例:有...
  •  c0000374 异常偏移量: 000b06fc OS 版本: 6.0.6002.2.2.0.768.3 区域设置 ID: 2052 其他信息 1: 2e7a 其他信息 2: 3a71ec754587b7b3db7918043ad6f3e1 其他信息 3: 82fc 其他信息 4: fd39ee3ebe7553b57105...

空空如也

空空如也

1 2 3 4 5 ... 14
收藏数 279
精华内容 111
关键字:

C0000374