Game in endless crashing.
Sign up for a new account in our community. It’s easy!
Sign in
Already have an account? Sign in here.
Recently Browsing 0 members
- No registered users viewing this page.
- Existing user? Sign In
- Sign Up
Community
DayZ
Information
Premium
Support
- Create New.
Important Information
We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we’ll assume you’re okay to continue. You can read our privacy policy here: Privacy Policy
Status heap corruption dayz 0xc0000374 что делать
Severity Crash Resolution Open Reproducibility Always Operating System Windows 10 x64 Category Game Crash
Steps To Reproduce
- Start the game
- Join any stable community (non-third person) server
- Enter the server with old character, with previous gear and everything.
- Game crash after few seconds.
Additional Information
DayZReport_Log_20190605T161859_JM.zip 9 MB Download
Update:
The game crashes when I look around or move, so I was able to drop everything on the ground while I got my friend to pick them up and kill me.
I respawned and everything was running good again, until I got my gear back, and the game crashed, which started the problem again. My conclusion is there is something wrong with the gear I had. Its surprising that my friend doesnt have any problems with my gear tho.
Anyways I’ve decided to ditch all my gear and start everything anew. Hope this doesn’t happen again.
Update 2
After respawning and doing some looting of (new) gears, I was experiencing the crashing again.
Update 3
After validating my game files with Steam, the game runs fine again.
Status heap corruption dayz 0xc0000374 что делать
Обратите внимание:
1. Прежде чем начать новую тему или отправить сообщение, убедитесь, что вы не нарушаете правил форума!
2. Обязательно воспользуйтесь поиском. Возможно, Ваш вопрос уже обсуждали. Полезные ссылки приведены ниже.
3. Темы с просьбой выполнить какую-либо работу за автора в этом разделе не обсуждаются.
4. Используйте теги [ code=cpp ] . текст программы. [ /code ] для выделения текста программы подсветкой.
5. Помните, здесь телепатов нет. Старайтесь формулировать свой вопрос максимально грамотно и чётко: Как правильно задавать вопросы
6. Запрещено отвечать в темы месячной и более давности без веских на то причин.
Модераторы: B.V.
‘> Не ловится исключение 0xC0000374, повреждение кучи .
- Подписаться на тему
- Сообщить другу
- Скачать/распечатать тему
Сообщ. #1 , 23.04.11, 16:54
Senior Member
Рейтинг (т): 43

Привет. Опять я про исключения . Намеренно вызываю исключение — повреждение кучи, но оно не ловится! Ни с помощью try/catch, ни с помощью __try/__except. В чём проблема?
Если оно не предназначено для того чтобы оно ловилось с помощью try/catch или __try/__except, как его поймать тогда?
Программу пробовал компилить со всеми возможными ключами /EH и без него вообще. В общем получаю при отладке следующее окошко:
//Компилировать с /EHa
#define _WIN32_WINNT 0x0502 //_WIN32_WINNT_WS03
#define WINVER 0x0502 //_WIN32_WINNT_WS03
#define UNICODE
#define _UNICODE
#pragma comment(lib,»Shlwapi.lib»)
#define TCHAR_SIZE sizeof(TCHAR)
#define MAX_PATH_SIZE 32769
#define MAX_FILENAME_SIZE 256
TCHAR AppExePath[MAX_PATH_SIZE];
TCHAR AppExeName[MAX_FILENAME_SIZE];
TCHAR logdir_name[]=_T(«logs\\»);
TCHAR *logdir_path;
TCHAR dumpdir_name[]=_T(«minidumps\\»);
TCHAR *dumpdir_path;
volatile BOOLEAN was_init_done;
LONG MainExceptFilter(DWORD except_code,PEXCEPTION_POINTERS except_info)
//. сюда не попадаем
printf(«In MainExceptFilter\n»);
return EXCEPTION_EXECUTE_HANDLER;
void ExtractFilePathAndName(TCHAR *path,TCHAR *name)
ptr=StrRChrI(path,NULL,’\\’);
StringCchCopy(name,ARRAYSIZE(AppExeName),ptr+1);
LONG WINAPI TopLevelUnhandledExceptionFilter(PEXCEPTION_POINTERS except_info)
//. сюда не попадаем
printf(«In TopLevelUnhandledExceptionFilter\n»);
return EXCEPTION_EXECUTE_HANDLER;
void InitializeMainFunction()
size_t pt_size,p1_size,p2_size,p3_size;
SetUnhandledExceptionFilter(TopLevelUnhandledExceptionFilter);
pt_size=p1_size=p2_size=p3_size=0;
AppExePath[0]=0;
GetModuleFileName(NULL,AppExePath,ARRAYSIZE(AppExePath));
ExtractFilePathAndName(AppExePath,AppExeName);
StringCchLength(AppExePath,STRSAFE_MAX_CCH,&p1_size);
StringCchLength(logdir_name,STRSAFE_MAX_CCH,&p2_size);
pt_size=p1_size+p2_size;
logdir_path=(TCHAR *)malloc(pt_size+1);
StringCchPrintf(logdir_path,pt_size+1,_T(«%s%s»),AppExePath,logdir_name);
CreateDirectory(logdir_path,NULL);
StringCchLength(dumpdir_name,STRSAFE_MAX_CCH,&p3_size);
//следующая строка вызовет исключение 0xC0000373, повреждение кучи
dumpdir_path=(TCHAR *)malloc(pt_size+p3_size+1); //. Эта строка вызывает исключение
StringCchPrintf(dumpdir_path,pt_size+p3_size+1,_T(«%s%s»),logdir_path,dumpdir_name);
catch(std::exception &except)
//. сюда не попадаем
printf(«In catch of InitializeMainFunction\n»);
//отправляем исключение дальше
//. сюда не попадаем
printf(«In catch of InitializeMainFunction\n»);
//отправляем исключение дальше
int _tmain(int argc, _TCHAR* argv[])
int ret_code=0;
was_init_done=false;
InitializeMainFunction();
was_init_done=true;
//далее код программы
//. сюда не попадаем
printf(«In __finally\n»);
if (logdir_path!=NULL) free(logdir_path);
if (dumpdir_path!=NULL) free(dumpdir_path);
__except(MainExceptFilter(GetExceptionCode(),GetExceptionInformation()))
//. сюда не попадаем
printf(«In __except\n»);
return ret_code;
Сообщение отредактировано: neokoder — 23.04.11, 20:01
Сообщ. #2 , 23.04.11, 19:13

Рейтинг (т): 527
У меня не воспоризводится. Вообще нет никакого исключения. Подозреваю, что проблема растёт из:
Цитата HeapSetInformation Function
| Value | Meaning |
|---|---|
| HeapEnableTerminationOnCorruption 1 |
Enables the terminate-on-corruption feature. If the heap manager detects an error in any heap used by the process, it calls the Windows Error Reporting service and terminates the process. |
After a process enables this feature, it cannot be disabled.
The HeapInformation parameter should be NULL and HeapInformationLength should be 0.
Добавлено 23.04.11, 19:15
Т.е. до исключения просто не доходит, WER возникает раньше.
Сообщ. #3 , 23.04.11, 19:33
Senior Member
Рейтинг (т): 43
Цитата Qraizer @ 23.04.11, 19:13
Т.е. до исключения просто не доходит, WER возникает раньше.
Если WER(windows Error Reporting) всё же возникает, значит исключение есть. А до этого ты пишешь «Вообще нет никакого исключения.». Так я не понял всё-таки возникает исключение или нет? Оно в приницпе может быть и раньше, например на этом операторе:
StringCchPrintf(logdir_path,pt_size+1,_T(«%s%s»),AppExePath,logdir_name);
Поскольку уже записывает байты туда где память не выделялась.
Ты попробуй под отладчиком запустить, чтобы этого WER вообще не было.
Сообщение отредактировано: neokoder — 23.04.11, 19:36
Сообщ. #4 , 23.04.11, 19:39

Рейтинг (т): 527
Именно что вообще ничего нет. Не могу воспроизвести исключение.
Сообщ. #5 , 23.04.11, 19:54
Senior Member
Рейтинг (т): 43
Странно, блин! Можешь сказать конфигурацию на которой ты запускаешь:
1) Операционка 32bit иди 64bit?
2) Компьютер 32bit иди 64bit?
3) Версия Visual C++.
з.ы. Я ещё немного подправил, внёс в код то что было в stdafx.h. Проверь, пожалуйста. Хотя конечно не в этом дело.
Добавлено 23.04.11, 20:00
Цитата Qraizer @ 23.04.11, 19:13
Подозреваю, что проблема растёт из HeapSetInformation.
Подозреваешь, что это где-то по умолчанию для основной кучи процесса вызывается? Ну так а всё равно как я изменю это? Тем более в MSDN вроде написано что если один раз установлено значение его уже нельзя изменить.
Сообщ. #6 , 24.04.11, 00:51

Рейтинг (т): 527
WinXP Pro SP3, VS2008 Express. Ничего странного в том, что не воспроизводится, если я прав в том, что цитата имеет отношение к твоей проблеме. Попробуй простым SEH-ом поймать.
В MSDN 2008, специально смотрел, STATUS_HEAP_CORRUPTION, который 0xC0000374, упоминается только в одной статье «Availability of Windows XP COM+ Hotfix Rollup Package 14» в подразделе «Issues that are fixed in the hotfix rollup package». Так что я даже не знаю, откуда этот NTSTATUS может взяться. Наверно, действительно относительно недавняя фишка.
Сообщ. #7 , 24.04.11, 07:29
Рейтинг (т): 940
Цитата neokoder @ 23.04.11, 16:54
//следующая строка вызовет исключение 0xC0000373, повреждение кучи
dumpdir_path=(TCHAR *)malloc(pt_size+p3_size+1); //. Эта строка вызывает исключение
malloc может выдать исключение только в случае, когда поврежден или сам выделяемый свободный блок или заголовки блоков, связанных с ним по FLink\BLink в списке свободных блоков. Тебе в данном случае просто «повезло», что два последовательных malloc выделяли блоки памяти последовательно друг за другом, хотя в общем случае это совершенно не обязательно.
Добавлено 24.04.11, 07:36
Цитата neokoder @ 23.04.11, 19:33
Так я не понял всё-таки возникает исключение или нет? Оно в приницпе может быть и раньше, например на этом операторе:
StringCchPrintf(logdir_path,pt_size+1,_T(«%s%s»),AppExePath,logdir_name);
Поскольку уже записывает байты туда где память не выделялась
Насколько я понимаю, несмотря на «интригующее название» все эти safe-функции просто контролируют выход за переданный в них размер cchDest, а никаих проверок на принадлежность указателя куче и на превышение размера блока кучи не делают. Соотв-но и никакого исключения выдать не могут (кроме AV, если вылезут за область виртуальной памяти, разрешенной для записи)
Сообщение отредактировано: leo — 24.04.11, 07:38
Сообщ. #8 , 24.04.11, 11:46
Senior Member
Рейтинг (т): 43
Цитата Qraizer @ 24.04.11, 00:51
WinXP Pro SP3, VS2008 Express. Ничего странного в том, что не воспроизводится, если я прав в том, что цитата имеет отношение к твоей проблеме. Попробуй простым SEH-ом поймать.
А у меня что не простой SEH что ли? В коде есть же блок __try/__except. Кроме того изначально у меня блока try/catch вообще не было, это я его уже добавлял с надеждой что мож он поймает это исключение.
Цитата Qraizer @ 24.04.11, 00:51
В MSDN 2008, специально смотрел, STATUS_HEAP_CORRUPTION, который 0xC0000374, упоминается только в одной статье «Availability of Windows XP COM+ Hotfix Rollup Package 14» в подразделе «Issues that are fixed in the hotfix rollup package». Так что я даже не знаю, откуда этот NTSTATUS может взяться. Наверно, действительно относительно недавняя фишка.
Ну значит это проблемы Windows 7 или VS 2010, поскольку при эмуляции с RaiseException исключение ловится всеми блоками как это и должно быть.
Первый вариантом проблемы я считал фаэрволл и антивирус. Поскольку это как раз тот случай о котором мы в первой теме про исключения говорили(если помнишь : — если сторонняя DLL не имеет обработчика исключения, то эту проблему я уже никак решить не смогу, т.е. перехватить исключение мне никак не удастся. Ну я вроде первым делом повыключал из автозагрузки с помощью autoruns всё что касается фаэрволла и антивируса. Проблема не решилась. Не хочется пробовать их удалять, но наверное придётся, чтобы теперь убедиться на 100%. Если не в них проблема значит в Windows7 или VS2010.
Добавлено 24.04.11, 11:50
Цитата leo @ 24.04.11, 07:29
Насколько я понимаю, несмотря на «интригующее название» все эти safe-функции просто контролируют выход за переданный в них размер cchDest, а никаих проверок на принадлежность указателя куче и на превышение размера блока кучи не делают. Соотв-но и никакого исключения выдать не могут (кроме AV, если вылезут за область виртуальной памяти, разрешенной для записи)
Ну так именно это и происходит: «вылезание за области невыделенной памяти». Намеренно.
Сообщ. #9 , 24.04.11, 14:54
Рейтинг (т): 241
Цитата neokoder @ 23.04.11, 19:33
StringCchPrintf(logdir_path,pt_size+1,_T(«%s%s»),AppExePath,logdir_name);
Поскольку уже записывает байты туда где память не выделялась.
Да. И у меня твой пример устойчиво генерирует исключение EXCEPTION_ACCESS_VIOLATION.
Если ошибку ликвидировать, всё работает. XP SP3, VS2005 EE
Не понятно, что у тебя происходит.
Можно сделать предположение:
А вдруг printf, который ты используешь для вывода диагностики
тоже использует кучу, которая портится и в результате ты диагностики не получаешь ?
(я в твоём примере printf не использовал.)
Сообщение отредактировано: ЫукпШ — 24.04.11, 15:00
Сообщ. #10 , 24.04.11, 15:42
Senior Member
Рейтинг (т): 43
Цитата ЫукпШ @ 24.04.11, 14:54
Да. И у меня твой пример устойчиво генерирует исключение EXCEPTION_ACCESS_VIOLATION.
А оно ловится как надо или нет?
Цитата ЫукпШ @ 24.04.11, 14:54
Если ошибку ликвидировать, всё работает. XP SP3, VS2005 EE
Да это то понятно .
Цитата ЫукпШ @ 24.04.11, 14:54
Не понятно, что у тебя происходит.
Можно сделать предположение:
А вдруг printf, который ты используешь для вывода диагностики
тоже использует кучу, которая портится и в результате ты диагностики не получаешь ?
(я в твоём примере printf не использовал.)

Я в дебаггере брейкпоинты расставил на все printf, он туда даже не попадает. Вот финальный стек вызовов, после этого программа просто завершается.:
Как видишь никаких printf не вызывается.
Сообщ. #11 , 24.04.11, 17:15
Рейтинг (т): 241
Цитата neokoder @ 24.04.11, 15:42
Цитата ЫукпШ @ 24.04.11, 14:54
Да. И у меня твой пример устойчиво генерирует исключение EXCEPTION_ACCESS_VIOLATION.
А оно ловится как надо или нет?
А попробуй.
Прикреплённый файл TestHeapEx.zip (31,87 Кбайт, скачиваний: 141)
Сообщ. #12 , 24.04.11, 17:20
Senior Member
Рейтинг (т): 43
Цитата ЫукпШ @ 24.04.11, 17:15
А попробуй.
Ты моим кодом ловишь исключение EXCEPTION_ACCESS_VIOLATION? Там всё должно работать.
Ты хотя бы исходник кинул. Или это мой код? Если мой, то он должен печатать printfы, а он ничего не выводит. Но исключения не происходит(нет сообщения windows). Если ты убрал все printf, то тогда так и должно быть.
Мой код должен вывести примерно следующее:
In MainExceptFilter
In __finally
In __except
Или следущее(если ключ компиляции /Eha):
In catch of InitializeMainFunction
In MainExceptFilter
In __finally
In __except
Сообщение отредактировано: neokoder — 24.04.11, 17:37
Сообщ. #13 , 24.04.11, 17:46
Рейтинг (т): 241
Цитата neokoder @ 24.04.11, 17:20
Ты хотя бы исходник кинул. Или это мой код?
Немного модифицированный.
Прикреплённый файл TestHeapEx.zip (39,13 Кбайт, скачиваний: 150)
Сообщ. #14 , 24.04.11, 17:49
Senior Member
Рейтинг (т): 43
Цитата ЫукпШ @ 24.04.11, 17:46
Немного модифицированный.
Ну этот исключение не обрабатывает. Windows пишет ошибку и закрывает его.
В общем посмотрел в отладчике — всё тоже самое неоработанное 0xC0000374 heap corruption, на той же строчке.
Сообщение отредактировано: neokoder — 24.04.11, 18:03
Сообщ. #15 , 24.04.11, 19:31

Рейтинг (т): 527
Цитата neokoder @ 24.04.11, 15:42
Вот финальный стек вызовов, после этого программа просто завершается.
Таки похоже, я прав. WER выводится до исключения. Попробуй добавить себя в список исключений вызовом WerAddExcludedApplication(). Может быть в этом случае будет-таки брошено исключение.
Сообщение отредактировано: Qraizer — 24.04.11, 19:31
Сообщ. #16 , 25.04.11, 06:18
Рейтинг (т): 940
Цитата neokoder @ 24.04.11, 11:46
Цитата neokoder @ 24.04.11, 11:46
Соотв-но и никакого исключения выдать не могут (кроме AV, если вылезут за область виртуальной памяти, разрешенной для записи)
Ну так именно это и происходит: «вылезание за области невыделенной памяти». Намеренно
1) Доступ к не выделенной или запрещенной для записи странице виртуальной памяти контролируется на уровне процессора и приводит к хардварному исключению #GP (general protection), которое система транслирует в эксепшн с кодом STATUS_ACCESS_VIOLATION = 0xC0000005. Но поскольку при выполнении StringCchPrintf никакого AV не происходит, значит с точки зрения процессора и менеджера вирт.памяти ОС все нормально, т.е. запись производится в пределах выделенной (commited) страницы памяти кучи с доступом на чтение+запись.
2) Менеджер кучи может определить HEAP_CORRUPTION не непосредственно во время записи данных (через StringCchPrintf или любым другим способом), а только при обращении к его функциям RtlAllocateHeap, RtlFreeHeap и т.п., когда проверяется валидность заголовка самого выделяемого или освобождаемого блока, а также пары «соседних» с ним блоков — либо соседних по списку свободных блоков (но не обязательно соседних по адресам), либо соседних по адресам, если они помечены как свободные и менеджер предпринимает попытку объединить их в один большой свободный блок. Плюс к этому в режиме отладки виндовый менеджер кучи может юзать (и по умолчанию юзает) доп.контроль в виде заполнения свободных блоков и неиспользуемых «хвостов» выделенных блоков специальными сигнатурами, целостность которых он проверяет при тех же операциях RtlAllocateHeap, RtlFreeHeap и т.п. (см.например тут и далее по ссылке На что влияет NtGlobalFlag). Поэтому в режиме отладки проще обнаружить HEAP_CORRUPTION не при выделении нового блока через malloc, а при освобождении поврежденного блока через free
3) Поскольку куча может быть всегда в той или иной мере фрагментирована (даже на входе в main, т.к. до ее вызова может выполняться куча «невидимого» кода инициализации crt и т.п. со своими выделениями и освобождениями памяти), то нет никакой гарантии, что при двух последовательных malloc будут выделены два соседних блока памяти. Может получиться, что для первого malloc найдется «дырка» подходящего размера где-то в середине кучи, а второй будет выделен в ее конце (или наоборот). Собс-но говоря, повреждения кучи тем и опасны\неприятны, что их обнаружение может произойти не где-то вблизи кода, вызвавшего повреждение, а совершенно в непредсказуемом месте. И, как уже было сказано в 2), в отладочном режиме проще\надежнее обнаружить повреждение не на следующем malloc, а на free блока, в который производилась запись за пределы выделенного размера
Сообщение отредактировано: leo — 25.04.11, 06:25
Сообщ. #17 , 25.04.11, 13:52
Senior Member
Рейтинг (т): 43
leo, спасибо за науку
. Но главный то вопрос в другом — почему не ловится это исключение?
Если добавить код RaiseException(0xC0000374,0,0,NULL); в самое начало функции InitializeMainFunction. То код ловит это исключения, обработчики работают.
Цитата Qraizer @ 24.04.11, 19:31
Таки похоже, я прав. WER выводится до исключения. Попробуй добавить себя в список исключений вызовом WerAddExcludedApplication(). Может быть в этом случае будет-таки брошено исключение.
Попробовал. Всё равно не ловит. Единственное отличие, что при запуске не под отладчиком windows сразу же показывает 2-ое окошко «Закрыть программу», т.е. никаких WER не запускается.