Добрый день.

Суть:
-есть DLL, написанная на С, Visual Studio (номер точно не знаю, уточнить можно);
-DLL статически связана с проектом на Delphi;
-вызывается функция Decoder(idx:ULONG; pInp_burst, pOut_frame:pointer; pConfigDecoder:PDecoderStruct):HRESULT;stdcall;
-все параметры функции — локальные переменные в процедуре;
-вызов функции "портит" некоторые поля структуры PDecoderStruct но не всегда!!!
-вернее будет сказать так:
-я отслеживаю 6-8 первых полей структуры, назовем их A1..A8 (ULONG);
-при неком определенном значении указателя стека эти поля не искажаются в результате вызова функции Decoder;
-если я добавляю перед вызовом функции Decoder несколько push-ей — то какое-то из полей A1...A8 будет испорчено, т.е. конструкция
...
rez :=Decoder(...);

отрабатывает нормально (при неком значении ESP для начала функции) а конструкция

asm
push eax;
push eax;
push eax;
...
push eax;
end;
rez :=Decoder(...);

приводит к "порче" полей структуры.

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

Я считаю, что в реализации функции Decoder(...) есть какая-то ошибка но я не могу найти объяснение такому её поведению, соответственно,
не понятно-как её локализовывать разработчику DLL: другая среда, другие значения стека.... и т.д.

Собственно-вопрос: что может теоретически в реализации функции Decoder(...) (или в её использовании мною) приводить к такомe эффекту?
Неициализированная переменная в DLL, которая "попадает" на разный адрес (при сдвижке стека), а там-какой-то "мусор", который интерпретируется соответственно?
Была такая мысль, но не подтверждается: если, к примеру, нужно добавить 5 push-ей, чтобы начал портится поле A8, то при 6 push-ах — портится поле А7,
7 push-А6 и т.д.

Всем спасибо заранее

PS: Размерность и тип входных параметров функции проверили.