• Cikk

[Hírlevelek archívuma ^][< 1. kötet, 1. szám][1. kötet, 3. >szám ]

The Systems Internals Newsletter Volume 1, Number 2

http://www.sysinternals.com

1999. május 15. – Ebben a kérdésben:

  1. A SYSTEMS INTERNALS ÚJDONSÁGAI

    • SDelete
    • BlueScreen Screen Saver Win2K Update
    • "Linux és az Enterprise"
    • "NT-segédprogramokban"
    • Saját májusi Windows NT Magazin oszlop
    • Nem annyira új dolgok

  2. BELSŐ HÍREK

    • Dr. GUI's Poor Bedside Manners
    • WinDev '99 Kelet
    • A Numega Driver Works kiadásának közelgő dátuma
    • Béta 3 DDK megjelent
    • Win2K várólistás spinlockok

  3. MI VÁRHATÓ?

    • Win2K system file protector (SFP)

SZPONZOR: WINTERNALS SZOFTVER

A Systems Internals Hírlevél által szponzorált Winternals Software, a weben a http://www.winternals.com. A Winternals Software a Windows NT/2K fejlett rendszereszközök vezető fejlesztője és szolgáltatója. A Winternals szoftvertermékek közé tartozik a FAT32 a Windows NT 4.0-hoz, az ERD Commander (a Windows NT rendszerindító lemezes képessége) és az NTRecover.

Üdvözlök mindenkit!

Üdvözöljük a Systems Internals hírlevél második kiadásában. A hírlevél jelenleg 2700 előfizetővel rendelkezik, és az előfizetések továbbra is erősek.

A Microsoft az utolsó hírlevél óta hivatalosan is kiadta a Windows 2000 3. bétaverziót. A Béta 3 kernel buildszáma 2031, míg az NT 4.0 kezdeti kiadási kernelé 1381, az NT 3.51 buildszáma pedig 1025. . Amit furcsának találok (és kissé bosszantó), hogy a Microsoft minden alkalommal növeli a buildszámot, amikor az operációs rendszer teljes buildjét végzik (minden munkanap), azonban a kernel jelentett buildszáma tükrözi a kezdeti nyilvános kiadás értékét. Például annak ellenére, hogy az NT 4.0 Service Pack 5 kernel tényleges buildszáma sokkal magasabb, mint 1381, a kernel továbbra is 1381-et jelent buildszámként.

A Windows 2000 3. bétaverziója a fejlesztői közösség ébresztési hívása. A Microsoft bejelentette, hogy októberben fogja szállítani a Windows 2000-et, és hogy a 3. bétaverzió a szállítandó termék funkció-teljes verzióját jelenti, így a fejlesztők anélkül kezdhetnek új termékeket írni, hogy ne kelljen attól tartaniuk, hogy a dolgok megváltoznak az alattuk lévőktől.

A Windows 2000 számos új API-t, rétegzett szolgáltatást és kernelfejlesztést tartalmaz. Az eszközillesztő-fejlesztők számára különösen látható változás, hogy a Halál kék képernyője (BSOD) megváltozott. Az NT korábbi verzióiban a BSOD a rendszer összes illesztőprogramjának hivatkozási idejét és betöltési címadatait, valamint a verem memóriaképét jeleníti meg az összeomlás időpontjában. Windows 2000 rendszerben csak a leállítási kód és a hozzá tartozó címsor(ok) (címsorok a stop-code paraméterek egy vagy több paraméterét az eszközillesztők helyére fordítják) jelenik meg, valamint egy részletes üzenet jelenik meg. A támogatási üzenet azt javasolja, hogy ellenőrizze a BIOS és a merevlemez beállításait, és tiltsa le a töredezettségmentesítő szoftvereket és vírusolvasókat, hogy elkerülje az összeomlást. A Microsoft Premier támogatási szolgáltatások (PSS) a tapasztalataik és az ügyfelek visszajelzései alapján megállapították, hogy az NT 4-stílusú BSOD nem hasznos az összeomlás okának meghatározásához.

Én személy szerint találtam a betöltött illesztőprogram-listát, és különösen a veremképet, hogy hasznos legyen, amikor illesztőprogram-hibajelentéseket kap a felhasználóktól, sokkal egyszerűbb és gyorsabb beszerezni ezeket az információkat, mint hogy a felhasználók több megabájtos összeomlási memóriaképet küldjenek. Gyakran izoláltam az összeomlás okát a veremkép alapján, és a felhasználók által az illesztőprogram-listában megjelenített verzióinformációk alapján betöltődő ellenőrzött illesztőprogram-verziókat. Kíváncsi vagyok, hogy mit gondol: szeretné látni az NT 4-stílusú BSOD továbbított a Windows 2000, vagy az új BSOD formátum elegendő? Küldjön nekem egy e-mailt, ha van véleménye. A következő hírlevélben jelentem be ennek az informális szavazásnak az eredményeit. Bár én vagyok a téma BSOD-k, győződjön meg róla, hogy nézd meg a Windows 2000 frissítést az egyre népszerű Systems Internals BlueScreen képernyőkímélő, amely foglalkozik ebben a kérdésben.

Köszönjük!

-Mark

A SYSTEMS INTERNALS ÚJDONSÁGAI

SDELETE

A C2 biztonsági minősítési követelményeknek megfelelő Windows NT 4.0 részeként megvalósítja az "objektum-újrafelhasználási védelmet". Ez azt jelenti, hogy az NT nullára állítja a fájl- és memóriaerőforrás-alkalmazásokat, amikor az alkalmazások első alkalommal férnek hozzá az erőforrásokhoz. Ez megakadályozza, hogy egy alkalmazás például nagyméretű fájlt hozzon létre, és megvizsgálja annak tartalmát, hogy lássa, mit tároltak korábban a lemezen. Az objektum-újrahasználat elleni védelem azonban nem terjed ki az olyan erőforrások védelmére, amelyek a standard erőforrásokkal kapcsolatos API-kat megkerülő vagy az operációs rendszert teljesen megkerülő alkalmazások által hozzáférhetők. Használhat például egy lemezszerkesztőt, például a Resource Kit DiskProbe-t a lemez nem áthelyezett részeinek tartalmának vizsgálatához. Így megtekintheti azokat az adatokat, amelyek korábban törölt fájlokhoz tartoztak.

Számos környezethez "biztonságos törlési" képesség szükséges. Ez a funkció lehetővé teszi a felhasználók számára a bizalmas adatok végleges törlését, hogy azok ne látszanak az operációs rendszer védelmi létesítményeit megkerülő eszközökkel. A titkosítási fájlrendszer (EFS) megjelenése kiemelte a Windows 2000 biztonságos törlési eszközének szükségességét. A korábban titkosítatlan fájlok titkosításakor az EFS nem törli a fájl titkosítatlan adatait tartalmazó lemezfoglalások tartalmát, amikor felszabadítja a lemezfoglalásokat. Így annak ellenére, hogy a titkosított fájl aktív verziója biztonságos, a fájl régi verziója továbbra is létezik a lemez nem áthelyezett részeiben, amíg az NTFS által az adott részekhez hozzárendelt új fájladatok felülírják.

Annak érdekében, hogy töltse ki ezt a lyukat, írtam SDelete (Secure Delete). Ez egy parancssori eszköz, amely lehetővé teszi nem csak a standard fájlok biztonságos törlését, hanem a lemez nem áthelyezett részeiben található, korábban törölt adatok biztonságos törlését is. Emellett a Windows NT/2000 tömörített, titkosított és ritkán használt fájljaival is működik, ami megköveteli a töredezettségmentesítési API használatát. A SDelete betartja a Védelmi Minisztérium szabványos DOD 5220.22-M-s megtisztítását és fertőtlenítését, így biztos lehet abban, hogy az adatok törlése után az örökre eltűnt.

Megadom a SDelete teljes forráskódját és annak működését, hogy láthassa, hogyan használja a töredezettségmentesítési API-t, és így ellenőrizheti a jogcímeimet, hogy megakadályozza a bizalmas törölt adatok helyreállítását.

A Windows NT/2000 töredezettségmentesítési API dokumentációját itt találja: http://www.sysinternals.com/defrag.htm. Töltse le a SDelete-t teljes forráskóddal a http://www.sysinternals.com/sdelete.htm.

BLUESCR ENTERPRISE KIADÁS N SCR ENTERPRISE KIADÁS N SAVER WIN2K UPDATE

A Microsoft által a Windows 2000 NT indítási képernyőjén és a Blue Screen of Death (BSOD) elrendezésen végzett módosítások miatt a Systems Internals BlueScreen Képernyőkímélő jelentős frissítést igényelt. Annak érdekében, hogy továbbra is a lehető legnagyobb mértékben a BSOD realizmus, én már kiadott verzió 2.0 a képernyőkímélő. Ez nem csak a BSOD formátum változásait tükrözi, hanem pontosan utánozza a Windows 2000 indítási képernyőjét is, a folyamatjelző sáv és a folyamatjelző sáv frissítéseivel kiegészítve. Annyira valós, hogy a képernyőkímélő még a Windows 2000 szakértő felhasználóit és fejlesztőit is megtéveszti. Az NT 4.0 BlueScreen Screen Saver alatt természetesen továbbra is látható az NT 4.0 BSOD és az indítási képernyő.

Hogyan hoztam létre újra a Windows 2000 indítóképernyőjét olyan tökéletesen, ugyanakkor nem sértve a szerzői jogi törvényeket? Nem tartalmazza a Windows 2000 indítási bitkép ábráját a képernyőkímélővel. Ehelyett a DirectX-et használom, hogy a grafikus módot a Windows 2000 által az indítási sorrendben használtra váltsam, majd hivatkozom a Windows 200 kernelfájl bitkép erőforrásaira, ntoskrnl.exe. Ezek az erőforrások (az ntoskrnl.exe erőforrásainak Visual Studióban való megnyitásával tekinthetők meg) azok, amelyeket a kernel jelenít meg, ami a Windows 9x-hez hasonló módon történik, ahol az indítási grafikus elemek valójában különálló fájlok. Nem úgy tűnik, hogy a számítógép oem-jeinek lehetősége lesz testre szabni a Windows 2000 indítási felületét...

A BlueScreen képernyőkímélőt a következő címen töltheti le: http://www.sysinternals.com/bluescreen.htm. Ha van egy humoros történet arról, hogy becsap valakit a képernyőkímélővel, kérjük, adja át.

Az 1997. decemberi Windows NT Magazine NT Internals (Belső windowsos NT Magazin) 1997. decemberi NT Internals oszlopában,"Inside the Blue Screen" (A kék képernyőn belül) további információt talál a BSOD-k módjáról és miértjeiről. A Systems Internals Publications (Belső rendszerek kiadványai) lapon http://www.sysinternals.com/publ.htmtalálható hivatkozás az oszlop on-line verziójára viszi. Az oldal más online bemutatókra mutató hivatkozásokat is tartalmaz az általam készített cikkekről és oszlopokról.

"LINUX ÉS AZ ENTERPRI Standard kiadás"

A Linux-közösség hatalmas válasza a Cikkemre a Windows NT Magazine áprilisi számában a Linux kernel méretezhetőségi hiányosságairól, arra késztette a magazint, hogy az ütemterv előtt tegye közzé a cikk online verzióját. A "Linux and the Enterprise" című cikkre mutató hivatkozást a "Cikkek" szakaszban találja: http://www.sysinternals.com/publ.htm. A cikk a Linux kernel (2.2x) jelenlegi kiadásának számos korlátozását ismerteti, beleértve a hatékony esemény-várakozási mechanizmus hiányát, a jelentős rendszerhívás-szerializálást, az aszinkron I/O-t, valamint a sendfile (az NT-ben a TransmitFile nevű) szoftvercsatornás API gyenge implementációját. Ezeknek a korlátozásoknak a kombinációja megakadályozza, hogy a Linux fejről-fejre versengjen az NT-vel és más UNIX-ekkel a teljesítmény szempontjából nagyvállalati szintű alkalmazásokon, például webkiszolgálókon, adatbázis-kiszolgálókon és e-mail-kiszolgálókon.

"NT-SEGÉDPROGRAMOKBAN"

Ha a Filemon, a Regmon vagy a HandleEx alkalmazást használta, és többet szeretne tudni arról, hogy mit mondanak Önnek és hogyan implementálják őket, akkor érdekelni fogja a Februári Windows NT Magazine-oszlopom, az "Inside NT Utilities" (NT-segédprogramok belső) oszlopa. Ez az oszlop ismerteti ezeknek az eszközöknek a belső elemeit, a Regmon és a Filemon esetében pedig egy kicsit tájékoztat azokról a hibakódokról és kéréstípusokról, amelyeket a beállításjegyzék- vagy fájlrendszer-tevékenység rögzítésekor naplóznak. A cikk online verziójára mutató hivatkozás, amely most vált elérhetővé, a következő helyen található: http://www.sysinternals.com/publ.htm.

A MÁJUSI WINDOWS NT MAGAZIN OSZLOPOM

Gondolkozott már azon, hogy a Windows NT/2000 hogyan rendszerezi a beállításjegyzék tartalmát a memóriában vagy a lemezen? A Windows NT Magazine aktuális (májusi) száma tartalmazza az "Inside the Registry" (A beállításjegyzéken belül) című oszlopomat, amely ezt és még sok mást is elárul. Megtudhatja például, hogy a Configuration Manager kernel módú alrendszere (a beállításjegyzék kezeléséért felelős alrendszer) hogyan keres kulcsokat, tárolja az értékadatokat, optimalizálja a keresést, és hogyan védi a lemezen lévő beállításjegyzék-fájlok integritását. Windows NT Magazine, http://www.winntmag.comelérhető a Borders és Barnes and Nobles.

NEM ÚJ DOLGOK

Nem jóval a Windows 2000 Beta 2 kiadása után vettem a kernel képfájljának (ntoskrnl.exe) Ellenőrzött (hibakeresési) buildét, sztringkeresést végeztem a kernelen, és összeállítottam a kernel létrehozásához használt forrásfájlok nevét. Az NT/2000 kernel ellenőrzött buildje számos olyan helyességi utasítást (konzisztencia-ellenőrzést) tartalmaz, amelyek tartalmazzák annak a fájlnak a fájlnevét, amelyben az Érvényesség található. Feltételezve, hogy a kernelforrásban gyakorlatilag minden bármilyen jelentőséggel bíró fájl legalább egy Érvényességgel rendelkezik, a lista meglehetősen átfogó. A lista Java-szkriptbe való kiírásával szép Explorer-szerű fanézetet kaptam a Windows 2000 forrásfájának könyvtárszerkezetéről. Itt tekintheti meg: http://www.sysinternals.com/nt5src.htm.

BELSŐ HÍREK

DR. A GUI ROSSZ ÁGY MELLETTI MODORA

A Microsoft Developer Network News Dr. GUI márciusi/áprilisi számában a dr. grafikus felhasználói felület olyan kérdést tesz fel egy olvasótól, amely azt kérdezi, hogy az illesztő hogyan képes affinitani (egy adott CPU használatára kényszeríteni) a szálakat. Dr. GUI válaszol, hogy nem lehet meghatározni a processzorok számát a rendszer egy illesztőprogram, és hogy egy illesztőprogram szál nem tudja megmondani, milyen processzoron fut. Sajnos, Dr. GUI fújta ezt a diagnózist (talán Dr. GUI kell ragaszkodni a GUI-k).

Az NT kernel (ntoskrnl.exe) exportál egy KeNumberProcessors nevű változót, amely az NTDDK-ban van definiálva. H mint:

extern PCCHAR KeNumberProcessors;

Közvetlenül hivatkozhat rá egy illesztőben, mint a következő:

CHAR    i;

for( i = 0; i < *KeNumberProcessors; i++ ) {

    // do processor specific stuff
}

Annak megállapításához, hogy melyik processzoron fut egy illesztőszál, használja a KeGetCurrentProcessorNumber() nevű kernelexportálást, amely nem csak az NTDDK-ban van definiálva. H, de valójában dokumentálva van a DDK-ban!

Dr. GUI rossz gyógyszert írt fel erre a bajra, ezért udvariasan értesítettem a Dr. Meglepő módon, Dr. GUI soha nem is nyugtázta az e-mail. Majd meglátjuk, hogy a jó Dr. esses fel a hiba a következő probléma ...

WINDEV '99 KELET

A Windows-fejlesztők számára tartott premier konferencia 1999-ben megjelent keleti parti kiadása gyorsan közeledik. WinDev '99 East kerül sor június 14-18-án a Boston Cambridge Marriot. A Windows-fejlesztésben számos nagy név beszél, köztük Jeff Richter, Jeff Prosise és Don Box. Ott leszek Jamie Hanrahannal és Brian Catlinnel az eszközvezető nyomában. A bemutatóim között szerepel egy egész napos oktatóanyag az NT belső elemeiről, valamint egy Windows NT/2K fájlrendszer-illesztőprogramok írásáról, valamint egy speciális eszközillesztő-fejlesztési problémákról. Gyere és köszönj!

NUMEGA DRIVER WORKS RELEA STANDARD KIADÁS IMMINENT

A Compuware NuMega Labs egy hatékony új Windows 9x/NT/2K eszközillesztő-fejlesztői készlet, a DriverStudio kiadásának szélén áll. A DriverStudio egyesíti a NuMega összes meglévő eszközillesztő eszközét, beleértve a DriverAgent, a DriverWorks, a SoftICE és a VtoolsD eszközt, és hozzáadja az új BoundsCheckert az illesztőprogramokhoz és a FieldAgenthez (csak Windows NT/2K).

A BoundsChecker eszközillesztő-verziója átfogó monitorozást biztosít az illesztőprogram által használt összes kernel API-ról, és segítségével figyelheti az illesztőprogram és a rendszer bármely más eszközillesztője közötti interakciókat. A FieldAgent lehetővé teszi a BoundsChecker illesztőprogram-verziójának üzembe helyezését az ügyfélrendszerekben, hogy az ügyfelek nyomkövetéseket gyűjthessenek Önnek, amelyeket elemezhet. A DriverStudio-ügyfelek számára hamarosan elérhető ingyenes frissítés a TrueTime az illesztőprogramokhoz, a TrueCoverage pedig illesztőprogramokhoz, olyan eszközökhöz, amelyek lehetővé teszik az eszközillesztők egyszerű teljesítményhangolását és lefedettségi tesztelését.

Ez a csomag a végső illesztőprogram-fejlesztési készlet, és szívből ajánlom (a bétaprogramban vagyok). További információ: http://www.numega.com.

BÉTA 3 DDK RELEA STANDARD KIADÁS D

A Windows 2000 Beta 3 kiadásával együtt a Microsoft ingyenesen letölthetővé tette a Windows 2000 Beta 3 DDK-t (eszközillesztő készlet). A DDK-t a következő helyen érheti el: http://www.microsoft.com/ddk/ddk2kb3.htm. Remélem, hogy az SDK hamarosan követni fogja, mivel számos Win32 API van a 3. bétaverzióban, amelyek nincsenek dokumentálva az MSDN áprilisi kiadásától.

WIN2K VÁRÓLISTÁS SPINLOCKS

A Windows 2000 egy új típusú spinlockot, úgynevezett "üzenetsoros spinlockot" használ a globális zárolásokhoz. A Windows 2000 globális zárolásai megegyeznek a Windows NT 4.0-s és a következőkkel:

  • KiDispatcherLock: az ütemező adatbázisának zárolása
  • KiContext-SwapLock: a futófelület felcserélésének zárolása
  • MmPfnLock: a fizikai lapkeret adatbázisának zárolása
  • MmSystemSpaceLock: a kernel módú címtér zárolása
  • CcMasterSpinLock: a Cache Manager globális spinlockja
  • CcVacbSpinLock: a Cache Manager leképezési tömbjének zárolása

Az egyprocesszoros várólistás spinlockok pontosan úgy működnek, mint a normál spinlockok. Az NT többprocesszoros buildjén azonban az üzenetsoros spinlockok jelentősen eltérnek. A standard spinlockokhoz hasonlóan az üzenetsoros spinlockok is implementálva vannak a HAL-ban. A kernel meghívja a HAL függvényt KeAcquireQueuedSpinlock egy üzenetsoros spinlock beszerzésére, és meghív KeReleaseQueuedSpinlock egy üzenetsoros spinlock kiadására. KeAcquireSpinlock és KeReleaseSpinlock, a HAL függvények, amelyet a kernel a standard spinlockok beszerzésére és kiadására használ, a megadott spinlock címét kell paraméterként megadni. Ezzel szemben az üzenetsoros spinlock függvények a globális spinlock indexszámát veszik át. A kernel inicializálja a globális spinlockokat egy tömbben, ahol minden spinlock előre definiált indexszámmal rendelkezik, amelyet a kernel a HAL-hoz való azonosításra használ. Így az üzenetsoros spinlockokat nem lehet definiálni és használni az eszközillesztők, mivel a globális várólistás spinlock tömb nem bővíthető.

A Windows 2000-ben az SMP minden processzorvezérlő régiója (PCR) rendelkezik egy tömbbel, amelyben annyi bejegyzés található, mint a várólistán lévő spinlockok. Minden tömbbejegyzés két mezőt tartalmaz: egy mutatót az üzenetsorhoz tartozó spinlockhoz (a "spinlock" mező) és az "üzenetsor" mezőt. Az alábbi leírásban a spinlock és az üzenetsor mezőire hivatkozva a beolvasandó vagy felszabadított spinlock tömbbejegyzéséhez tartozó mezőkről beszélek.

KeAcquireQueuedSpinlock Így működik: a függvény az interlocked-exchange CPU utasítással megkísérli megszerezni a spinlockot, hogy az aktuális processzor PCR-jének címét a spinlockba helyezze. Ha a spinlockot tartják, a függvény a csereművelet részeként egy másik processzor PCR-jének címét tartalmazza. Ezután a függvény "várakozásként" azonosítja magát a spinlock mező kis bitjének a saját PCR-ben való összevonásával. Ezután a saját PCR-címét a spinlockból lekért PCR üzenetsor mezőjébe helyezi. Végül egy forgalmas hurokban vár, amíg az alacsony bit ki nem kapcsol a spinlock mezőjében, amikor a bit ki van kapcsolva, akkor az aktuális processzor megkapta a spinlockot, és így visszatér a beolvasási függvény hívójához.

Miután a processzor beszerezte a várólistára helyezett spinlockot, és befejezte a kívánt feldolgozást a zárolás megtartása közben, meghívja KeReleaseQueuedSpinlocka . KeReleaseQueuedSpinlock Az aktuális processzor PCR-jében a megadott spinlock üzenetsormezőjét tekinti meg. Ha az üzenetsor mező nem nulla, akkor egy másik processzor is "várólistára helyezett" a PCR-jét. KeReleaseQueuedSpinlock Törli a várakozó PCR spinlock mezőjének kis részét, majd törli a saját üzenetsor-mezőjét, és visszaadja azt. A várakozó PCR spinlock mezőjének kis bitjének törlésével az imént jelezte a következő processzort a sorban, hogy rendelkezhet a zárolással. Ha az üzenetsor mezője nulla volt, akkor nem vár más processzor a zárolásra, és KeReleaseQueuedSpinlock egyszerűen hajt végre egy összekapcsolt exchange-műveletet a globális spinlock törléséhez.

Az üzenetsoros spinlockok művelete az, ahol a processzorok "sorba állnak" a tárolt spinlockra várva. Minden processzor önmagát üzenetsorba állítja úgy, hogy sorban közli az előtte állóval, hogy várakozik. Ez determinisztikus sorrendet biztosít az üzenetsoros spinlock-processzorok beszerzéséhez a spinlock kérésének sorrendjében. A standard spinlockok esetében nincs ilyen rendezés. Az üzenetsoros spinlockok további jelentős előnyt élveznek. A processzor pörgetés közben arra vár, hogy a spinlock mezője az alacsony bitet törölje, a saját processzora felé pörög a memóriában. Amikor egy processzor foglalt egy szabványos spinlockra vár, az a globális spinlockon pörög, amelyet az összes processzor megoszt. Így az üzenetsoros spinlockok jobb többprocesszoros busztulajdonságokkal rendelkeznek, mivel a forgalmas várakozás során nincs megosztott gyorsítótár-vonal hozzáférés. Emellett az üzenetsoros spinlockok sorbanállási jellege miatt általában kevesebb buszzárolási művelet van, mint a standard spinlockok esetében, ha egy zárolás több processzorból áll.

Az üzenetsoros spinlockok egyike annak a számos fejlesztésnek, amelyet a Microsoft a Windows 2000 többprocesszoros méretezhetőségét tette elérhetővé.

MI VÁRHATÓ?

A Windows 2000 számos olyan funkciót tartalmaz, amelyek ellenállóbbá teszik az operátori hibákkal és a hibásan viselkedő alkalmazásokkal szemben. Az egyik az, hogy az és a %systemroot%\system32 könyvtár alatt található DLL-ek és %systemroot%\system32\drivers illesztőprogramok közül sokat a System File Protector (SFP) nevű watchdog véd. A létezését a könyvtárba lépve system32 és átnevezve ntoskrnl.exeellenőrizheti. A watchdog felébred, és értesíti Önt arról, hogy illetéktelen beavatkozást észlelt egy védett rendszerfájlban, és javítja azt. Ha újra ellenőrzi a könyvtárat, azt fogja találni ntoskrnl.exe , hogy varázslatosan lecserélték. Legközelebb elmondom, hogyan működik ez.

Köszönjük, hogy elolvasta a Systems Internals Hírlevél.

Közzétéve: 1999. május 15. szombat, 19:15 ottoh

[Hírlevelek archívuma ^][< 1. kötet, 1. szám][1. kötet, 3. >szám ]