Ошибки при переводе проекта из Visual Studio 2008 в 2010

Question

Я работал с Visual Studio 2008 в C-проекте без проблем.Теперь я добавил те же исходные файлы в Visual Studio 2010, скомпилировал его без проблем, но при отладке программы получаю:

Необработанное исключение в 0x00417257 в da34.exe: 0xC0000005: Место чтения нарушения доступа 0x00030000.

Глядя на код, я просто вижу это:

    ; Find next lower page and probe
cs20:
        sub     eax, _PAGESIZE_         ; decrease by PAGESIZE
        test    dword ptr [eax],eax     ; probe page.
        jmp     short cs10

_chkstk endp

        end

и он указывает на строку "пробной страницы"

Знаете ли вы, в чем может быть причина?Моя программа очень проста.

Спасибо

ОБНОВЛЕНИЕ:

Я нашел "причину" ошибки, сначала прокомментировав содержимое основных функций, затем прокомментировав половину и т. Д.Программа состоит из одного .c и одного .h файла.В файле .h тип определяется следующим образом:

typedef FLOAT_TYPE d_elem[NMAX][NMAX][3];

, в файле .c в основной функции, только когда переменные определены, есть строка вроде:

    d_elem d_m; 

Если я прокомментирую эту строку, ошибка исчезнет.Я нахожу это странным, что здесь происходит?Конечно, вся программа компилируется и запускается с GCC в Linux без этих проблем.

UPDATE2: Решение (глупое) состоит в том, чтобы увеличить размер стека резервных копий для параметров проекта, компоновщика и т. Д. Кстати, идиот.VS 2008 с теми же опциями по умолчанию запускает программу ok

Answer 1

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

Редактировать: Сама природа UB заключается в том, что результаты вашей программы становятся непредсказуемыми.Это работало в VS2008?И что?Это один из способов проявить UB.Значит сбой уходит, когда вы делаете случайные изменения?Ну, это непредсказуемо для вас.Посмотрите на этот старый ответ от меня относительно UB.(Это только немного преувеличено. Действительно.)

Признайтесь: Пока ваша программа где-то каким-то образом вызывает неопределенное поведение, в любой момент может произойти что угодно. Попробуйтечтобы найти актуальную проблему и решить ее, вместо внесения случайных изменений, которые приводят к случайным результатам.
Когда происходит сбой, прорвитесь в отладчик и посмотрите на стек вызовов, переменные, что пыталась сделать программа, когдаон потерпел крах, как он туда попал, какие значения - чепуха, и почему они - чепуха.
Это выстрел в темноте, но из-за того, как выглядит этот 3D-массив, вы можете отскочить слишком глубоко, тем самым взорвав стек.тем не менее, чтобы сказать, что вы показали слишком мало кода.