Нарушение доступа в приложении C

Question

Нарушение доступа в приложении C

0

Folks

У меня возникают сбои в приложении C/C++ (VC 6.0). Он кажется случайным, но все экземпляры относятся к новому /malloc. У меня есть обработчик minidump в моем коде, который выводится в и __except, который прерывает вызов OLDMain.

Когда я смотрю на этот дамп в WinDbg, я получаю следующий вывод: (измененный для защиты базы кода)

STACK_TEXT:  
WARNING: Stack unwind information not available. Following frames may be wrong.
001273f0 01730000 0000042b 060a8ea8 00127424 ntdll+0x122ba
00127400 7c911bdc 01730178 0000042b 01730000 0x1730000
00127424 7c91825d 0000042b 100a8ea8 0000042b ntdll+0x11bdc
00127458 7c911c76 02730000 00001038 00127c07 ntdll+0x1825d
00127688 0081bffc 01730000 00000000 00001030 ntdll+0x11c76
001276c4 0080cf52 00001030 00127c07 00b99f11 MyProgram!_heap_alloc_base+0x13c [malloc.c @ 200]
001276ec 0080cd39 00001000 00000002 00ac1fa8 MyProgram!_heap_alloc_dbg+0x1a2 [dbgheap.c @ 378]
0012772c 0080ccbf 00001000 00000000 00000002 MyProgram!_nh_malloc_dbg+0x49 [dbgheap.c @ 248]
0012774c 008202f9 00001000 00000002 00ac1fa8 MyProgram!_malloc_dbg+0x1f [dbgheap.c @ 165]
00127774 00817dfc 00b67668 00127c07 00b99f11 MyProgram!_getbuf+0x59 [_getbuf.c @ 59]
001277a0 00818d4f 00000032 00b67668 00127af1 MyProgram!_flsbuf+0x13c [_flsbuf.c @ 153]
001277b4 00818df7 00000032 00b67668 0012786c MyProgram!write_char+0x4f [output.c @ 1113]
001277cc 00818ba5 00127af1 00000009 00b67668 MyProgram!write_string+0x37 [output.c @ 1251]
00127a9c 00809785 00b67668 00b1653a 00127ae0 MyProgram!_output+0xc65 [output.c @ 1007]
00127acc 005ad453 00b67668 00b16538 00127af0 MyProgram!fprintf+0x95 [fprintf.c @ 64]
00127c08 005acfd9 00127c30 00b16398 00127d4c MyProgram!WriteStringToFile+0x150 [C:\PATH_TO_SOURCE\LIB_Methods.cpp @ 11562]
00127d2c 004c0507 00af445c 00127d4c 0012e3bc MyProgram!WriteLog+0x594 [C:\PATH_TO_SOURCE\LIB_Methods.cpp @ 11468]
00127e84 005fd45c 00b25a78 00b258f9 00b99f11 MyProgram!WriteTimingsText+0x7c [C:\PATH_TO_SOURCE\PROM_Methods.cpp @ 2711]
0012e55c 005fd210 0000008a fffff2de 0012e6c4 MyProgram!_C_S_Method+0x113 [C:\PATH_TO_SOURCE\SAL_Methods.cpp @ 8681]
0012e940 0045dd6c 0012e810 00b24d16 00000000 MyProgram!_ST_Method+0x407e [C:\PATH_TO_SOURCE\SAL_Methods.cpp @ 8581]
0012eaf4 005f7827 0012eccc 00b9b038 0012ed64 MyProgram!_K_ST_Method+0x246 [C:\PATH_TO_SOURCE\FX_Methods.cpp @ 3306]
0012edc4 005f18b1 0012f41c 0012f424 cccccccc MyProgram!_N_I_Method+0x3b6a [C:\PATH_TO_SOURCE\SAL_Methods.cpp @ 5946]
0012f418 007ba243 00b5b950 00320030 00300034 MyProgram!OLDMain+0x1dd6 [C:\PATH_TO_SOURCE\SAL_Methods.cpp @ 2489]
0012ff30 00815546 00400000 00000000 00142368 MyProgram!WinMain+0x70f [C:\PATH_TO_SOURCE\MyProgram.cpp @ 866]
0012ffc0 7c816d4f 00320030 00300034 7ffd5000 MyProgram!WinMainCRTStartup+0x126 [crt0.c @ 198]
0012fff0 00000000 00815420 00000000 00000000 kernel32+0x16d4f

Я смотрел на другие стеки от сбоев, связанных с новыми, в том случае, когда созданный clss не должен был быть таким, каким он не был настроен для этого, я добавил чек для configuratipon и reran.

Проблема, похоже, продвигается дальше.

На данный момент я не уверен, как выяснить, почему Malloc/новые не работают? Любые предложения по тому, что я могу сделать дальше?

Полный вывод Windbg

*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************

*** WARNING: Unable to verify checksum for MyProgram.exe
*** WARNING: Unable to verify timestamp for kernel32.dll
*** ERROR: Module load completed but symbols could not be loaded for kernel32.dll
***** OS symbols are WRONG. Please fix symbols to do analysis.

Unable to load image C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll, Win32 error 0n2
*** WARNING: Unable to verify timestamp for mscorwks.dll
*** ERROR: Module load completed but symbols could not be loaded for mscorwks.dll
Unable to load image C:\WINDOWS\system32\ole32.dll, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ole32.dll
*** ERROR: Module load completed but symbols could not be loaded for ole32.dll
Unable to load image C:\WINDOWS\system32\user32.dll, Win32 error 0n2
*** WARNING: Unable to verify timestamp for user32.dll
*** ERROR: Module load completed but symbols could not be loaded for user32.dll
*** WARNING: Unable to verify timestamp for wdmaud.drv
*** ERROR: Module load completed but symbols could not be loaded for wdmaud.drv
*** WARNING: Unable to verify timestamp for dsound.dll
*** ERROR: Module load completed but symbols could not be loaded for dsound.dll
*** WARNING: Unable to verify timestamp for dmime.dll
*** ERROR: Module load completed but symbols could not be loaded for dmime.dll
*** WARNING: Unable to verify timestamp for dmsynth.dll
*** ERROR: Module load completed but symbols could not be loaded for dmsynth.dll
*** WARNING: Unable to verify checksum for SOBase11.dll
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for SOBase11.dll - 
*** WARNING: Unable to verify checksum for PortMg10.dll
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for PortMg10.dll - 
*** WARNING: Unable to verify checksum for Porthcom.dll
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for Porthcom.dll - 
*** WARNING: Unable to verify timestamp for mfc42.dll
*** ERROR: Module load completed but symbols could not be loaded for mfc42.dll
*** WARNING: Unable to verify checksum for PtrIO15.dll
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for PtrIO15.dll - 
*** WARNING: Unable to verify timestamp for SoDspL13.dll
*** ERROR: Module load completed but symbols could not be loaded for SoDspL13.dll
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for GdiPlus.dll - 
Unable to load image C:\WINDOWS\system32\rpcrt4.dll, Win32 error 0n2
*** WARNING: Unable to verify timestamp for rpcrt4.dll
*** ERROR: Module load completed but symbols could not be loaded for rpcrt4.dll
*** WARNING: Unable to verify timestamp for KbwMSRDrv.dll
*** ERROR: Module load completed but symbols could not be loaded for KbwMSRDrv.dll
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
            2) the file mscordacwks.dll that matches your version of mscorwks.dll is 
                in the version directory
            3) or, if you are debugging a dump file, verify that the file 
                mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
            4) you are debugging on the same architecture as the dump file.
                For example, an IA64 dump file must be debugged on an IA64
                machine.

You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll.  .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.

If you are debugging a minidump, you need to make sure that your executable
path is pointing to mscorwks.dll as well.
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
            2) the file mscordacwks.dll that matches your version of mscorwks.dll is 
                in the version directory
            3) or, if you are debugging a dump file, verify that the file 
                mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
            4) you are debugging on the same architecture as the dump file.
                For example, an IA64 dump file must be debugged on an IA64
                machine.

You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll.  .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.

If you are debugging a minidump, you need to make sure that your executable
path is pointing to mscorwks.dll as well.
GetPageUrlData failed, server returned HTTP status 404
URL requested: http://watson.microsoft.com/StageOne/MyProgram_exe/0_0_0_0/ntdll_dll/5_1_2600_2180/000122ba.htm?Retriage=1

FAULTING_IP: 
ntdll+122ba
7c9122ba ??              ???

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 7c9122ba (ntdll+0x000122ba)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000000
   Parameter[1]: 00000000
Attempt to read from address 00000000

PROCESS_NAME:  MyProgram.exe

ADDITIONAL_DEBUG_TEXT:  
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols.

FAULTING_MODULE: 7c900000 ntdll

DEBUG_FLR_IMAGE_TIMESTAMP:  5268f887

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

EXCEPTION_PARAMETER1:  00000000

EXCEPTION_PARAMETER2:  00000000

READ_ADDRESS:  00000000 

FOLLOWUP_IP: 
MyProgram!_heap_alloc_base+13c [malloc.c @ 200]
0081bffc 8b4df0          mov     ecx,dword ptr [ebp-10h]

MOD_LIST: <ANALYSIS/>

MANAGED_STACK: !dumpstack -EE
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
            2) the file mscordacwks.dll that matches your version of mscorwks.dll is 
                in the version directory
            3) or, if you are debugging a dump file, verify that the file 
                mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
            4) you are debugging on the same architecture as the dump file.
                For example, an IA64 dump file must be debugged on an IA64
                machine.

You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll.  .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.

If you are debugging a minidump, you need to make sure that your executable
path is pointing to mscorwks.dll as well.

FAULTING_THREAD:  000007fc

BUGCHECK_STR:  APPLICATION_FAULT_NULL_POINTER_READ_WRONG_SYMBOLS

PRIMARY_PROBLEM_CLASS:  NULL_POINTER_READ

DEFAULT_BUCKET_ID:  NULL_POINTER_READ

IP_ON_HEAP:  01730000

FRAME_ONE_INVALID: 1

LAST_CONTROL_TRANSFER:  from 01730000 to 7c9122ba

STACK_TEXT:  
WARNING: Stack unwind information not available. Following frames may be wrong.
001273f0 01730000 0000042b 060a8ea8 00127424 ntdll+0x122ba
00127400 7c911bdc 01730178 0000042b 01730000 0x1730000
00127424 7c91825d 0000042b 100a8ea8 0000042b ntdll+0x11bdc
00127458 7c911c76 02730000 00001038 00127c07 ntdll+0x1825d
00127688 0081bffc 01730000 00000000 00001030 ntdll+0x11c76
001276c4 0080cf52 00001030 00127c07 00b99f11 MyProgram!_heap_alloc_base+0x13c [malloc.c @ 200]
001276ec 0080cd39 00001000 00000002 00ac1fa8 MyProgram!_heap_alloc_dbg+0x1a2 [dbgheap.c @ 378]
0012772c 0080ccbf 00001000 00000000 00000002 MyProgram!_nh_malloc_dbg+0x49 [dbgheap.c @ 248]
0012774c 008202f9 00001000 00000002 00ac1fa8 MyProgram!_malloc_dbg+0x1f [dbgheap.c @ 165]
00127774 00817dfc 00b67668 00127c07 00b99f11 MyProgram!_getbuf+0x59 [_getbuf.c @ 59]
001277a0 00818d4f 00000032 00b67668 00127af1 MyProgram!_flsbuf+0x13c [_flsbuf.c @ 153]
001277b4 00818df7 00000032 00b67668 0012786c MyProgram!write_char+0x4f [output.c @ 1113]
001277cc 00818ba5 00127af1 00000009 00b67668 MyProgram!write_string+0x37 [output.c @ 1251]
00127a9c 00809785 00b67668 00b1653a 00127ae0 MyProgram!_output+0xc65 [output.c @ 1007]
00127acc 005ad453 00b67668 00b16538 00127af0 MyProgram!fprintf+0x95 [fprintf.c @ 64]
00127c08 005acfd9 00127c30 00b16398 00127d4c MyProgram!WriteStringToFile+0x150 [C:\PATH_TO_SOURCE\LIB_Methods.cpp @ 11562]
00127d2c 004c0507 00af445c 00127d4c 0012e3bc MyProgram!WriteLog+0x594 [C:\PATH_TO_SOURCE\LIB_Methods.cpp @ 11468]
00127e84 005fd45c 00b25a78 00b258f9 00b99f11 MyProgram!WriteTimingsText+0x7c [C:\PATH_TO_SOURCE\PROM_Methods.cpp @ 2711]
0012e55c 005fd210 0000008a fffff2de 0012e6c4 MyProgram!_C_S_Method+0x113 [C:\PATH_TO_SOURCE\SAL_Methods.cpp @ 8681]
0012e940 0045dd6c 0012e810 00b24d16 00000000 MyProgram!_ST_Method+0x407e [C:\PATH_TO_SOURCE\SAL_Methods.cpp @ 8581]
0012eaf4 005f7827 0012eccc 00b9b038 0012ed64 MyProgram!_K_ST_Method+0x246 [C:\PATH_TO_SOURCE\FX_Methods.cpp @ 3306]
0012edc4 005f18b1 0012f41c 0012f424 cccccccc MyProgram!_N_I_Method+0x3b6a [C:\PATH_TO_SOURCE\SAL_Methods.cpp @ 5946]
0012f418 007ba243 00b5b950 00320030 00300034 MyProgram!OLDMain+0x1dd6 [C:\PATH_TO_SOURCE\SAL_Methods.cpp @ 2489]
0012ff30 00815546 00400000 00000000 00142368 MyProgram!WinMain+0x70f [C:\PATH_TO_SOURCE\MyProgram.cpp @ 866]
0012ffc0 7c816d4f 00320030 00300034 7ffd5000 MyProgram!WinMainCRTStartup+0x126 [crt0.c @ 198]
0012fff0 00000000 00815420 00000000 00000000 kernel32+0x16d4f


STACK_COMMAND:  ~0s; .ecxr ; kb

FAULTING_SOURCE_CODE:  
No source found for 'malloc.c'


SYMBOL_STACK_INDEX:  5

SYMBOL_NAME:  MyProgram!_heap_alloc_base+13c

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: MyProgram

IMAGE_NAME:  MyProgram.exe

BUCKET_ID:  WRONG_SYMBOLS

FAILURE_BUCKET_ID:  NULL_POINTER_READ_c0000005_MyProgram.exe!_heap_alloc_base

WATSON_STAGEONE_URL:  http://watson.microsoft.com/StageOne/MyProgram_exe/0_0_0_0/5268f887/ntdll_dll/5_1_2600_2180/411096b4/c0000005/000122ba.htm?Retriage=1

Followup: MachineOwner
---------

РЕДАКТИРОВАТЬ:

Я прокомментировал WriteStringToFile, чтобы показать, что он снова сработает, вот еще один стек вызовов: единственное, что существует в heap_alloc, теперь одно, что я вижу, это то же самое между обеими столами вызовов для указателя NULL строка ниже: IS это в _N_I_Method, где начинается указатель Null или это действительно здесь?

0012edc4 005f18b1 0012f41c 0012f424 **cccccccc** MyProgram!_N_I_Method+0x3b6a [C:\PATH_TO_SOURCE\SAL_Methods.cpp @ 5946]

Новый стек

STACK_TEXT:  
WARNING: Stack unwind information not available. Following frames may be wrong.
00127b54 0012e3bc 00b99f11 00000000 00000000 ntdll+0x3426d
00127d78 0081bffc 01730000 00000000 00000040 0x12e3bc
00127db4 0080cf52 00000040 0012e3bc 00b99f11 MyProgram!_heap_alloc_base+0x13c [malloc.c @ 200]
00127ddc 0080cd39 00000014 00000001 00000000 MyProgram!_heap_alloc_dbg+0x1a2 [dbgheap.c @ 378]
00127e1c 0080cce6 00000014 00000001 00000001 MyProgram!_nh_malloc_dbg+0x49 [dbgheap.c @ 248]
00127e38 008089bf 00000014 00000001 00b86f20 MyProgram!_nh_malloc+0x16 [dbgheap.c @ 197]
00127e4c 0052966a 00000014 00b99f11 cccccccc MyProgram!operator new+0xf [new.cpp @ 24]
00127e88 005ff32c 00b258f9 00b99f11 00000000 MyProgram!CMessaging::SendMsg_Finished+0x43 [C:\PATH_TO_SOURCE\CMessaging.cpp @ 1703]
0012e55c 005fd210 0000008a fffff2de 0012e6c4 MyProgram!_C_S_Method+0x1fe3 [C:\PATH_TO_SOURCE\SAL_Methods.cpp @ 9824]
0012e940 0045dd6c 0012e810 00b24d16 00000000 MyProgram!_ST_Method+0x407e [C:\PATH_TO_SOURCE\SAL_Methods.cpp @ 8581]
0012eaf4 005f7827 0012eccc 00b9b038 0012ed64 MyProgram!_K_ST_Method+0x246 [C:\PATH_TO_SOURCE\FX_Methods.cpp @ 3306]
0012edc4 005f18b1 0012f41c 0012f424 cccccccc MyProgram!_N_I_Method+0x3b6a [C:\PATH_TO_SOURCE\SAL_Methods.cpp @ 5946]
0012f418 007ba243 00b5b950 80000001 01b5d678 MyProgram!Oldmain+0x1dd6 [C:\PATH_TO_SOURCE\SAL_Methods.cpp @ 2489]
0012ff30 00815546 00400000 00000000 00142368 MyProgram!WinMain+0x70f [C:\PATH_TO_SOURCE\MyProgram.cpp @ 866]
0012ffc0 7c816d4f 80000001 01b5d678 7ffdf000 MyProgram!WinMainCRTStartup+0x126 [crt0.c @ 198]
0012fff0 00000000 00815420 00000000 00000000 kernel32+0x16d4f

KF-SoftwareDev 24 окт. 2013, в 14:25

Источник

0

Попробуйте использовать какой-нибудь детектор утечки памяти. На линуксе рекомендую valgrind ....
Basile Starynkevitch 24 окт. 2013, в 12:05
4

@BasileStarynkevitch Этот вопрос имеет Microsoft Windows, написанную на всем протяжении этого ...
Lundin 24 окт. 2013, в 12:09
0

Я знаю, что в этом вопросе упоминается Windows (но я не знаю Windows и не использую ее), но я не знаю, что эквивалентно valgrind в Windows. Много лет назад вы могли купить Purify . Я не знаю, существует ли этот продукт. Тем не менее, ОП должен найти эквивалентный детектор утечки памяти.
Basile Starynkevitch 24 окт. 2013, в 12:15
1

как код выглядит в вашей функции WriteStringToFile? кажется, вы получаете ошибку при вызове fprintf там
Anders 24 окт. 2013, в 12:32
0

Метод не имеет значения, если честно, я мог бы закомментировать его, как я это делал в других случаях, и ошибка просто возникнет где-то еще в коде. Этого не происходит, когда вы в первый раз запускаете приложение, его случайный путь к одному и тому же коду кода может выполняться с использованием одного и того же сценария тестирования тысячи раз и не вызывает проблем, или в других случаях может выполняться только один тест
KF-SoftwareDev 24 окт. 2013, в 13:01
0

Обновлено оригинальное сообщение
KF-SoftwareDev 24 окт. 2013, в 13:25
0

Если это C++ , не помечайте как C Нет такой вещи, как C / C ++ «код».
crashmstr 24 окт. 2013, в 13:47
0

Этот код является устаревшим, исходная кодовая база была на C, когда он был перемещен в VC6.0, расширения файлов принимают форму .cpp, но код остается простым C, добавляемый новый код в основном делается как C ++ OOP
KF-SoftwareDev 24 окт. 2013, в 13:53

Показать ещё 6 комментариев

Теги:

c++

c

memory

memory-management

out-of-memory

2 ответа

Ещё вопросы

Попробуйте использовать какой-нибудь детектор утечки памяти. На линуксе рекомендую valgrind ....
@BasileStarynkevitch Этот вопрос имеет Microsoft Windows, написанную на всем протяжении этого ...
Я знаю, что в этом вопросе упоминается Windows (но я не знаю Windows и не использую ее), но я не знаю, что эквивалентно valgrind в Windows. Много лет назад вы могли купить Purify . Я не знаю, существует ли этот продукт. Тем не менее, ОП должен найти эквивалентный детектор утечки памяти.
как код выглядит в вашей функции WriteStringToFile? кажется, вы получаете ошибку при вызове fprintf там
Метод не имеет значения, если честно, я мог бы закомментировать его, как я это делал в других случаях, и ошибка просто возникнет где-то еще в коде. Этого не происходит, когда вы в первый раз запускаете приложение, его случайный путь к одному и тому же коду кода может выполняться с использованием одного и того же сценария тестирования тысячи раз и не вызывает проблем, или в других случаях может выполняться только один тест
Обновлено оригинальное сообщение
Если это C++ , не помечайте как C Нет такой вещи, как C / C ++ «код».
Этот код является устаревшим, исходная кодовая база была на C, когда он был перемещен в VC6.0, расширения файлов принимают форму .cpp, но код остается простым C, добавляемый новый код в основном делается как C ++ OOP

Matt · Answer 1 · 2013-10-24T10-52-00.000Z

Malloc/new терпят неудачу, обычно это происходит из-за того, что куча уже повреждена. Для вашего случая возможны две причины:

Куча испорчена вашим собственным кодом.
Рассогласование библиотек времени выполнения. Вы все еще используете VC 6++ для кодирования, но другие DLL, я думаю, большинство из них скомпилировано с более высокой версией VC, поэтому в вашем процессе должно быть несколько библиотек времени выполнения (msvcrt.dll). Если одна память разделяется одной библиотекой времени выполнения и освобождается другой библиотекой времени выполнения, что может привести к повреждению кучи, потому что у другой библиотеки времени выполнения может быть разная реализация malloc и бесплатная.

Спасибо, Мэтт, да, я понял, что проблема в кучи - это проблема, посмотри мое редактирование - возможно ли, что cccccccc в стеке для _N_I_Method является источником проблемы, это часто встречается в обоих сбоях?
Это просто означает, что куча повреждена перед этой строкой кода. Когда куча повреждена, обычно происходит сбой при следующей загрузке памяти, поскольку библиотека времени выполнения обычно проверяет кучу перед выделением новой памяти. Одним из инструментов является DebugDiag, он бесплатный и может помочь вам отладить проблемы с памятью, вы можете попробовать это. Другой инструмент - это верификатор приложений.
Спасибо, Мэтт, просто так, у меня есть это право, куча повреждена, прежде чем я вызову _N_I_Method, из MiniDump я могу понять, почему куча была повреждена, или мне нужно запустить снова, используя DebugDiag или AppVerify?
Да, это уже испорчено. Вам нужно снова запустить программу.

Klas Lindbäck · Answer 2 · 2013-10-24T09-57-00.000Z

At this point i am unsure how to figure out why Malloc / new are failing? Any suggestions for what i can do next?

Если вы получаете исключения фрейма стека, то у вас, скорее всего, есть переполнение буфера в вашем коде.

Если у вас нет подходящего инструмента, который поможет вам, я предлагаю вам использовать комбинацию обзора кода (с акцентом на указатели и переполнение буфера) и классической отладкой.

С классической отладкой я имею в виду выявить проблему, сначала запустив код один раздел за раз, пока вы не получите крах или не увидите перезаписанную переменную. Затем повторно запустите последний раздел по строкам, пока не найдете, где он не работает. Исправьте ошибку. Повторяйте до тех пор, пока все ваши тестовые примеры не будут работать.

Спасибо Клас, я выполнил это через тестового партнера, он не выходит из строя при отладке, что, вероятно, связано с заполнением буферов отладчиком. Devpartner не показывает никаких проблем, кроме нескольких висячих указателей