Коротко: проблема почти наверняка не в «глубине стека» и не в том, что функция вызывает функцию. В P/Invoke падения из-за стека почти всегда приходят от несовпадения соглашения о вызовах/сигнатур на границе .NET ↔ native, а не от внутренних вызовов в самой DLL.

Ниже — целевой чек-лист и конкретные правки.

---

Что проверить в первую очередь

1. Соглашение о вызовах (x86!)
   Если вызываете 32-битную DLL:

• По умолчанию в С++ свободные функции → __cdecl.
• В C# у [DllImport] по умолчанию CallingConvention.Winapi (на x86 это чаще __stdcall).
  → Несовпадение даёт «PInvokeStackImbalance»/краши.

Сделайте явно и согласованно:

C++ (экспорт):

cpp
extern "C" __declspec(dllexport)
float __cdecl Rastrigin(float x1, float x2) noexcept {
    return RastriginFunc(x1, x2);
}

C# (импорт):

csharp
[DllImport("MyDll", ExactSpelling=true, CallingConvention=CallingConvention.Cdecl)]
internal static extern float Rastrigin(float x1, float x2);

На x64 одна конвенция, но я всё равно советую прописывать явно — код станет переносимее и очевиднее.

2. Типы параметров/возврата — строго совпадают.
   float ↔ float, double ↔ double. Никаких «а тут float, а там double». Это критично именно на x86.

3. Имя функции, прототип и линковка.
   В вашем примере вы определили fabe13_cos1, а вызываете fabe13_cos(...). Если в реальном коде тоже так — легко получить вызов другой функции/прототипа (или вообще не того ABI) → UB/краш. Убедитесь, что:

• имя точно совпадает (без «1» / без перегрузок),
• прототип объявлен в том же заголовке, что и определение,
• все внутренние матфункции static inline и видны компилятору в том же TU.

4. Не экспортируйте C++-референсы.
   В вашем экспорте — только «plain C ABI»: простые скаляры, указатели на буферы, структуры с явной раскладкой. Внутри DLL можете использовать float&/double& сколько угодно, но наружу — ни в коем случае.

5. Не меняйте FPU-контрольные слова, или восстанавливайте.
   Если где-то включили маски исключений (_controlfp, _mm_setcsr, /fp:except) и схлопотали INVALID/OVERFLOW, то управляемая сторона может падать. Без надобности не трогайте; либо сохраните/восстановите:

cpp
#include <float.h>
#include <immintrin.h>

struct FpuGuard {
    unsigned int cw{};
    unsigned int mxcsr{};
    FpuGuard() {
        _controlfp_s(&cw, 0, 0);
        mxcsr = _mm_getcsr();
    }
    ~FpuGuard() {
        _controlfp_s(&cw, cw, _MCW_IC | _MCW_RC | _MCW_PC | _MCW_EM);
        _mm_setcsr(mxcsr);
    }
};

И на входе экспортируемой функции создайте FpuGuard guard;.

6. Уберите экзотику — для диагностики.
   На время отладки уберите __forceinline, __declspec(noalias), __restrict. Постройте без LTO/IPO. Так легче увидеть источник.

---

По вашим примерам

• LCG_rand + ShekelFunc «работают» не потому, что там «меньше стека». Просто компилятор почти всё держит в регистрах/инлайнит, и на границе P/Invoke ничего не отличается.

• RastriginFunc c вашим fabe13_cos1 «не работает» — очень вероятно из-за ошибки имени/прототипа (fabe13_cos vs fabe13_cos1) или из-за рассинхронизации float/double в объявлениях. Это даёт именно те симптомы, о которых вы пишете, и проявляется «вдруг» при замене cosf на свою реализацию.

• «Сделать ещё одну DLL» или «сделать внутреннюю функцию экспортируемой» не решит проблему стека. Граница .NET↔native одна; внутренняя вложенность на стек P/Invoke не влияет.

• «Передавать по ссылкам/умным указателям» — внутри DLL делайте как хотите; на экспорт — только C-совместимые типы. Умные указатели/ссылки — нельзя.

---

Рекомендуемая «эталонная» обвязка

Экспорт:

cpp
extern "C" __declspec(dllexport)
float __cdecl Rastrigin(float x1, float x2) noexcept
{
    // (опционально) защитим состояние FPU
    // FpuGuard guard;

    return RastriginFunc(x1, x2);
}

// внутренняя реализация — только internal linkage:
static inline float fabe13_cos1(float x) noexcept {
    const float ax = fabsf(x);
    if (ax < 7.450580596923828125e-9f) return 1.0f;
    const float k_dd = x * 0.6366197723675814f;
    const int   k_int = int(k_dd + (k_dd > 0.0 ? 0.5 : -0.5));
    const float k = (float)k_int;
    const float r = fmaf(-1.5707963267948966f, k, x);
    const float r2 = r * r;
    const float sin_r = fmaf(fmaf(0.0083333318f, r2, -0.16666666f), r2, 1.0f) * r;
    const float cos_r = fmaf(fmaf(fmaf(-0.0013888398f, r2, 0.041666638f), r2, -0.5f), r2, 1.0f);
    return (k == 0.0f) ?  cos_r :
           (k == 1.0f) ? -sin_r :
           (k == 2.0f) ? -cos_r :  sin_r;
}

static inline float RastriginFunc(float x1, float x2) noexcept {
    const float term1 = fmaf(x1, x1, x2 * x2);
    const float c = 6.28318530717958647692f;
    // ВНИМАНИЕ: имя функции должно совпадать!
    const float osc = fabe13_cos1(c * x1) + fabe13_cos1(c * x2);
    return (term1 - fmaf(osc, 10.0f, -14.6f)) * fmaf(-term1, 0.25f, 18.42f);
}

Импорт в C#:

csharp
[DllImport("MyDll", ExactSpelling=true, CallingConvention=CallingConvention.Cdecl)]
internal static extern float Rastrigin(float x1, float x2);

---

Диагностика за 5 минут

1. Соберите x64 и запустите — если всё ок, на x86 почти наверняка конвенция вызова была не той.
2. Включите /GS /sdl /Wall, временно уберите __forceinline.
3. Проверьте dumpbin /exports MyDll.dll — убедитесь, что экспорт без @N (это был бы stdcall), имя строго Rastrigin.
4. Добавьте __declspec(noinline) к RastriginFunc/fabe13_cos1 — если краш не меняется, дело точно не в глубине стека/инлайне.

---

Если после выравнивания конвенций и сигнатур проблема сохранится — пришлите, пожалуйста, точную сигнатуру экспортируемой функции (как в C++ экспорте, так и в [DllImport]), битность процесса (x86/x64) и текст ошибки/MDAs. Но с высокой вероятностью всё решится на шагах выше.