Ad s chybou RAM som sa uz stretol tiez, ta ale bola vzdy do istej miery deterministicka; napriklad pokus o kompletny rebuild Release skoncil modrou smrtou systemu - pokud píšete, že chyba RAM musí "deterministicky" způsobit BSOD, tak je to doufám pokus o vtip. Pro ilustraci se koukněte na row hammer. Pokud do RAM zapisujete "správné" vzory, můžete "propsat" hodnotu nebo její část do přilehlých buněk, což je způsobené probémem s izolací buněk (resp. typicky řádků). Může se to stát cíleně, ale také blbou náhodou. Potom můžete pozorovat pěkný efekt: při "míchání dat" se vám nedeterministicky poškodí obsah paměti, ale pokud v ní máte relativně statický obsah (executable), tak se problém neprojeví. Podobné problémy (disturbance errors) můžete v některých případech pozorovat, i když je paměťový modul poškozený.
https://en.wikipedia.org/wiki/Row_hammer
Ad Vzhladom k tomu, ze ta ista binarka pred rebootom nefungovala a po reboote ano, pripisujem toto nejakemu nedeterministickemu heisenbugu priamo vo Windowse / dynamickom linkeri / standardnej alebo nestandardnej kniznici ktora je s nasou aplikaciou linkovana - LOL. Chcete ukázku kódu, který nefunguje po nějaké době běhu OS?
if (GetTickCount()>86400000) DoCrash();
Nebo:
HANDLE hFile;
hFile = CreateFile(argv[1], GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL | FILE_FLAG_OVERLAPPED, NULL);
if ((DWORD64)hFile % 1024 == 0) DoCrash();
Variací na tohle téma jistě vymyslíte spoustu, a pokud máte dost velký projekt, tak se v něm může snadno vyskytnout problém z podobné kategorie. Mimochodem po rebootu se vám nejspíš naskládají executables i data do paměti trochu jinak, a pokud máte problém s RAM, tak se věci mohou chovat jinak. Jinými slovy to co popisujete může mít řadu různých důvodů, a připisovat to automaticky chybě OS je nesmysl.
Ad hladanim problemu, ktory skoncil stack tracom niekde v standardnej kniznici - předpokládám že víte, že pokud předáte knihovně například invalid pointer, tak aplikace spadne v knihovně, ale problém je u vás.