В подавляющем большинстве случаев причина такого поведения ("в дебаге работало, в релизе ломалось") — неинициализированная переменная.

Он же сообщает о использовании неинициализированной переменной. (по моему мнению)

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

Хотел тут у себя воспроизвести, сделать скрин и разоблачить, что дотнет под массив память сразу выделяет всю и с нулями! Начал проверять — и что-то как-то резко передумал это делать...

С другой стороны такое ощущение, что это винда молодец, а не дотнет. Дотнет коммитит сразу весь гигабайт, а потребление постепенно растет (Private bytes):

using System;

namespace ConsoleApp17
{
    class Program
    {
        static void Main(string[] args)
        {
            int[] bytes = new int[int.MaxValue/8];
            Console.ReadKey();
            for (int i = 0; i < bytes.Length; i+=1000)
            {
                bytes[i] = i;
                Console.WriteLine(i);
            }
            Console.WriteLine(bytes);
        }
    }
}

Не понимаю, при чем тут .Net, если это стандартный сишный calloc. Не знаю ни одного примера ни одного рантайма, которое бы делалло malloc + ручную инициализацию вместо этого.

Существует неплохая эвристика, реализованная в языке C#, которая несмотря на свою простоту закрывает большинство случаев.

В C# просто не решает проблему остановки, потому что анализ флоу производится локально. Он не позволяет передать неинициализированную переменную по ref например, чтобы её внутри кто-то проинициализировал. В большинстве случаев оно и не нужно, но собственно это единственный способ решать нерешаемые задачи — на уровне семантики обрубать случаи, когда анализ слишком усложняется, и реализовать тривиальную проверку "до первого использования идентификатора в качестве rvalue он используется в качестве lvalue"

поскольку на программу, собранную в Update 3, внезапно стал ругаться антивирус, причём именно тот, который мы устанавливаем клиентам

Вот так ругаться? (собирал CoreCLR)

#include <stdio.h>

#define TRIGGER_BUG
// Tested with:
// cl.exe ver 16.00.40219.01 for 80x86
// cl.exe ver 16.00.40219.01 for x64
// compile: cl /O2 /Ob2 vc2010_bug.cpp
// correct ouptut: 001001000
// actual  ouptut: 001001100

volatile int val = 36;

static unsigned char *mkbits(unsigned int Inp, unsigned char *buf, unsigned int BitNum)
{
    unsigned int i;
    for (i = 0; i < BitNum; i++)
    {
#ifndef TRIGGER_BUG
        buf[i] = (Inp & (1 << i)) ? 1 : 0;
#else
        buf[i] = (Inp & 1);
        Inp >>= 1;
#endif
    }
    return buf + BitNum;
}

void Pack()
{
    unsigned char buf[10];
    unsigned char *pbuf = buf;

    pbuf = mkbits(val, pbuf, 7);
    pbuf = mkbits(0, pbuf, 2);

    for (int i = 0; i < 9; i++)
        printf("%c", buf[i] ? '1' : '0');
    printf("\n");
}

int main(int argc, char** argv)
{
    Pack();
    return 0;
}

Вся линейка компиляторов от Microsoft содержала баги. Всегда.