Tuon Hiikerin aloituksessa linkkaaman artikkelin idea oli siis se, että jos Windows kaatuu toistuvasti ja sininen ruutu / WhoCrashed tms. kertoo syylliseksi "Memory_Management", silloin on epäilys että jokin Windowsin järjestelmätiedosto on rikki ja virheen takia esim. jokin ajuri yrittää lukea/kirjoittaa sellaista muistialuetta josta sen kuuluisi pitää näppinsä erossa, tai pahimmassa tapauksessa rikkinäinen Windowsin ydintiedosto jossain tapauksessa kirjoittelisi prosessorin muistinhallintataulukkoon puutaheinää.
Muistinhallinnan järkevyyttä valvoo koko ajan rautatasolla prosessorin muistinhallintayksikkö (Memory Management Unit eli MMU), käyttöjärjestelmän tekemien taulukkojen perusteella. Jos mikä tahansa prosessi koneessa yrittää tehdä jotain mikä ei ole näiden taulukkojen mukaan juuri siinä tilanteessa OK, MMU aiheuttaa keskeytyksen, jolloin ko. prosessoriydin hyppää käyttöjärjestelmän rutiiniin jossa tutkitaan tilannetta vähän tarkemmin. Kyseessä voi olla vaikka normaali tilanne jossa aikaisemmin muistissa ollutta dataa on siirretty käytön vähyyden ja akuutimman muistintarpeen takia sivutustiedostoon, ja silloin keskeytysrutiini käynnistää datan haun sivutustiedostosta takaisin muistiin, ja vasta sen jälkeen päästää prosessin jatkamaan keskeytynyttä toimintoa.
Mutta jos käyttöjärjestelmän muistinhallintakeskeytyksen käsittelyrutiini ei löydä mitään "kelvollista" syytä muistinhallintakeskeytykselle, tilanne käsitellään virheenä, ja jos keskeytyksen aiheuttaja on jokin selkeästi tunnistettava prosessi, sen ajoa ei jatketa vaan ilmoitetaan käyttäjälle että "prosessi x teki muistinkäsittelyvirheen ja kaatui" ja siivotaan prosessin jämät muistista. Jos näin "kaadettu" prosessi oli käyttöjärjestelmään kuuluva ajuri tai palvelu, Windows voi joissain tapauksissa käynnistää sen automaattisesti uudelleen ja toiminta voi jatkua.
Mutta jos muistinhallintavirheelle ei löydy selkeästi osoitettavaa syyllistä, tai syy on käyttöjärjestelmän ytimen ohjelmakoodissa, silloin koko käyttöjärjestelmän tila on epäilyksenalainen: ei voida tietää yrittikö ohjelmakoodi tehdä jotain päätöntä, vai oliko koodi itse asiassa täysin järkevää mutta muistinhallintataulukoissa itsessään virhe? Silloin mennään toiseksi viimeiseen vaihtoehtoon, eli tuotetaan "Memory_Management" bluescreen-virheilmoitus ja kaadetaan koko käyttöjärjestelmä.
Jos sekään ei onnistu vaan aiheuttaa uuden muistinhallintakeskeytyksen jota ei pystytä selvittämään, vihoviimeinen vaihtoehto on sitten se, että MMU resetoi koko prosessorin rautatasolla, jolloin kone vain yksinkertaisesti boottaa ilman varsinaista virheilmoitusta tai ennakkovaroitusta (ns. triple fault handler joka on sisäänrakennettu prosessorin rautaan). Uudelleen käynnistyessään Windows sitten huomaa että edellisellä kierroksella jotain meni ilmeisesti pahasti pieleen.
Tästä kaikesta seuraa se, että muistinhallintataulukot käytännössä "elävät" jatkuvasti niin, että jonkinlaisen ylimääräisen tarkastuksen tekeminen niille edellyttäisi kaiken muun toiminnan jäädyttämistä vähintään siksi aikaa että koneen muistin tilasta saadaan otettua täydellinen kopio. Nykyisissä koneissa on useita prosessoriytimiä, joten ne voivat ihan oikeasti tehdä useita asioita yhtä aikaa: jos tarkistusta yritettäisiin ilman täysjäädytystä, jokin toinen ydin voisi samaan aikaan tehdä jotakin muuta joka aiheuttaa muutoksen taulukon loppupäähän samalla kun alkupäätä vielä tarkastetaan, ja lopputulos olisi aina "tässä on jotakin pielessä".
Ja siksi ajatus "muistinhallinnan rakenteen tarkastamisesta" noin vain ilman esim. toista konetta ja rautatason debuggeria on aika hankala toteuttaa. Tuo linkitetty artikkelikin lähtee siitä ajatuksesta, että itse virheen etsimisen sijasta käydään läpi "muistinhallinnan rakenteen virheiden" todennäköiset alkusyyt ja tarkistetaan ne.
Juuri siitä on "sfc /scannow"-komennossa kysymys: se tarkistaa järjestelmätiedostojen kunnon, jotta voidaan sulkea pois se mahdollisuus että viallisessa järjestelmätiedostossa oleva rikkinäinen ohjelmakoodin pätkä aiheuttaisi muistinhallintavirheitä.
