15 maj 1999 – I det här problemet:

  1. VAD ÄR NYTT PÅ SYSTEM INTERNALS

    • Sdelete
    • Win2K-uppdatering för BlueScreen-skärmsläckare
    • "Linux och Enterprise"
    • "Inuti NT Utilities"
    • Kolumnen Min Windows NT Magazine
    • Inte så nya saker
  2. INTERNT NYHETER

    • Dr. GUI's Poor Poolside Manners
    • WinDev –99, östra
    • Numega Driver Works Release Eng.
    • Beta 3 DDK har släppts
    • Win2K-köade spinlocks
  3. DET HÄR ÄR VAD SOM HÄNDER

    • Win2K System File Protector (SFP)

SPONSRING: UNDERSPONSOR: UNDERSENTLIG PROGRAMVARA

Nyhetsbrevet Systems Internals är sponsrat av Winternals Software, på webben på http://www.winternals.com. Undertidsprogramvaran är den ledande utvecklaren och leverantören av avancerade systemverktyg för Windows NT/2K. Undertidsprogramvaran innehåller FAT32 för Windows NT 4.0, ERD Commander (startdiskkapacitet för Windows NT) och NTRecover.

Hej!

Välkommen till den andra utgåvan av nyhetsbrevet Systems Internals. Nyhetsbrevet har för närvarande 2 700 prenumeranter, och prenumerationerna är fortfarande starka.

Sedan det senaste nyhetsbrevet har Microsoft officiellt publicerat Windows 2000 Beta 3. Build-numret för Beta 3-kerneln är 2031, medan kerneln för NT 4.0-versionen var 1381 och NT 3.51 hade build-nummer 1025. . Det jag tycker är udda (och något konstigt) är att Microsoft ökar build-numret varje gång de gör en fullständig version av operativsystemet (varje arbetsdag), men det rapporterade byggnumret för kerneln återspeglar det för den första offentliga versionen. Även om det faktiska build-numret för NT 4.0 Service Pack 5-kerneln till exempel är mycket högre än 1381, rapporterar kerneln fortfarande 1381 som build-nummer.

Beta 3-versionen av Windows 2000 är avsedd att vara ett uppvakningssamtal för utvecklarna. Microsoft har tillkännagivit att den kommer att leverera Windows 2000 i oktober och att Beta 3 representerar den funktions fullständiga versionen av det som levereras, så att utvecklare kan börja skriva nya produkter utan att vara orolig att saker och ting kommer att ändras under dem.

Windows 2000 levereras med en mängd nya API:er, skiktade tjänster och kernelförbättringar. En ändring som är särskilt synlig för utvecklare av enhetsdrivrutiner är att BSOD (Blue Screen of Death) har ändrats. I tidigare versioner av NT visade BSOD länktid och inläsningsadressinformation för alla drivrutiner i ett system, samt en dump av stacken som den finns vid tidpunkten för kraschen. I Windows 2000 visas bara stoppkoden och associerade adressrader (adressrader översätter en eller flera av stoppkodsparametrarna till platser inom enhetsdrivrutiner) tillsammans med ett utförligt meddelande. Supportmeddelandet föreslår att du kontrollerar inställningarna för BIOS och hårddisken och inaktiverar defragmenteringsprogramvara och virusskannrar för att försöka undvika att kraschen kraschar igen. Microsoft Premier Support Services (PSS) fastställde, baserat på deras erfarenhet och kundfeedback, att NT 4-formats BSOD inte är användbart för att fastställa orsaken till en krasch.

Personligen upptäckte jag att den inlästa drivrutinslistan, och särskilt stackdumpen, är användbar när jag hämtar buggrapporter från användare. Det är mycket enklare och snabbare att hämta den här informationen än att användarna skickar en kraschdump på flera megabyte. Jag har ofta isolerat orsaken till kraschen baserat på stackdumpen och verifierade drivrutinsversioner som användarna har läst in baserat på versionsinformationen som visas i drivrutinslistan. Jag är nyfiken på vad du tycker: vill du se hur BSOD i NT 4-format går vidare till Windows 2000 eller räcker det nya BSOD-formatet? Skicka mig ett e-postmeddelande om du har en uppfattning. Jag kommer att rapportera resultatet av den här informella undersökningen i nästa nyhetsbrev. När jag är på ämnet BSODs, se till att kolla in Windows 2000-uppdateringen av den ständigt populära System Internals BlueScreen Skärmsläckaren, som tas upp i det här problemet.

Tack!

-Mark

VAD ÄR NYTT PÅ SYSTEM INTERNALS

SDELETE

Som en del Windows NT 4.0 uppfyller C2-säkerhetsklassificeringskraven implementeras "skydd för återanvändning av objekt". Det innebär att NT nollställer fil- och minnesresurser som program allokerar när programmen får åtkomst till resurserna för första gången. Detta förhindrar att ett program till exempel skapar en stor fil och undersöker innehållet för att se vad som tidigare lagrades på disken. Skydd mot återanvändning av objekt skyddar dock inte resurser som är tillgängliga för program som kringgår standardresursrelaterade API:er eller som kringgår operativsystemet helt och hållet. Du kan till exempel använda en diskredigerare, till exempel Resource Kits DiskProbe, för att undersöka innehållet i oallokerade delar av en disk. På så sätt kan du se data som tidigare hör till borttagna filer.

Många miljöer kräver en "säker borttagning"-funktion. Den här funktionen gör det möjligt för användare att permanent ta bort känsliga data så att de inte visas av verktyg som kringgår operativsystemets skydd. Framväxten av krypterande filsystem (EFS) har visat på behovet av en säker borttagningsfunktion i Windows 2000. När du krypterar en tidigare okrypterad fil raderar EFS inte innehållet i diskallokeringar som innehöll filens okrypterade data när diskallokeringarna frigörs. Även om den aktiva versionen av en fil som du krypterar är säker finns den gamla versionen av filen fortfarande i de oallokerade delarna av en disk tills den skrivs över av nya fildata som NTFS tilldelar till dessa delar.

För att fylla det här hålet har jag skrivit SDelete (Säker borttagning). Det är ett kommandoradsverktyg som gör det möjligt att inte bara ta bort standardfiler på ett säkert sätt, utan även att på ett säkert sätt ta bort tidigare borttagna data som finns i de oallokerade delarna av en disk. Dessutom fungerar det med Windows NT/2000 komprimerade, krypterade och glesa filer, något som kräver användning av defragmenterings-API:et. SDelete följer usa:s försvarsdepartements rensnings- och rensningsstandard DOD 5220.22-M, så att du kan vara säker på att den är borta för alltid när du tar bort data.

Jag ger SDelete fullständig källkod och en beskrivning av hur det fungerar, så att du kan se hur det använder defragmenterings-API:et och så att du kan verifiera mina anspråk att det förhindrar att känsliga borttagna data kan återställas.

Du hittar dokumentation om defragmenterings-API Windows NT/2000 påhttp://www.sysinternals.com/defrag.htm. Ladda ned SDelete med fullständig källkod på http://www.sysinternals.com/sdelete.htm.

WIN2K-UPPDATERING FÖR BLUESCREEN-SKÄRMSLÄCKARE

De ändringar som Microsoft har gjort i NT-startskärmen och BSOD-layouten (Blue Screen of Death) i Windows 2000 gjorde att System Internals BlueScreen Screen Saver kräver en större uppdatering. Jag har släppt version 2.0 av skärmsläckaren för att kunna fortsätta att ge dig den största delen i BSOD- och BSOD-programmet. Det återspeglar inte bara ändringarna i BSOD-formatet, utan efterliknar även exakt Windows 2000-startskärmen, komplett med roterande förloppsstrimla och uppdateringar av förloppsfältet. Det är så verkligt att skärmsläckaren kommer att lura även Windows 2 000 expertanvändare och utvecklare. Under NT 4.0 Visar BlueScreen-skärmsläckaren naturligtvis fortfarande NT 4.0 BSOD- och startskärmarna.

Hur återskapade jag Windows 2000-startskärmen så perfekt och samtidigt inte bryter mot upphovsrättslagar? Jag inkluderar inte grafiken Windows 2000 startup med skärmsläckaren. I stället använder jag DirectX för att växla grafikläget till samma som används av Windows 2000 under startsekvensen och sedan refererar jag till bitmappresurserna i Windows 200-kernelfilen, ntoskrnl.exe. Dessa resurser (du kan visa dem genom att öppna resurserna för ntoskrnl.exe i Visual Studio) är de som kerneln visar, vilket är en ändring från Windows 9x-sättet att göra saker där startgrafik faktiskt är separata filer. Det ser inte ut som om dator-OEM-tillverkare får möjlighet att anpassa startupplevelsen i Windows 2000...

Du kan ladda ned BlueScreen-skärmsläckaren på http://www.sysinternals.com/bluescreen.htm. Om du har en fantastisk berättelse som handlar om att lura någon med skärmsläckaren kan du skicka vidare den.

Du kan ta reda på mer information om hur och varför är BSOD:er i min kolumn Windows NT Magazine NT Internals i december 1997, "Inside the Blue Screen". En länk på sidan Systems Internals Publications http://www.sysinternals.com/publ.htm ,, tar dig till den onlinebaserade versionen av kolumnen. Sidan innehåller också länkar till andra onlinepresentationer av artiklar och kolumner som jag har skapat.

"LINUX OCH ENTERPRISE"

Det enorma svaret från Linux-communityn på min artikel i aprilnumret av Windows NT Magazine om skalbarhetsbristerna i Linux-kerneln har uppmanat bladet att publicera den onlinebaserade versionen av artikeln i förväg. Du hittar en länk till artikeln "Linux och Enterprise" i avsnittet "Artiklar" på http://www.sysinternals.com/publ.htm. I artikeln beskrivs flera begränsningar i den aktuella versionen av Linux-kerneln (2.2x), inklusive brist på en effektiv mekanism för händelseväntetid, betydande systemanropsserialisering, ingen asynkron I/O och en dålig implementering av sendfile(i NT dess kallas TransmitFile) socket-API. Kombinationen av dessa begränsningar hindrar Linux från att konkurrera med NT och andra UNIX:er när det gäller prestanda i program i företagsklass som webbservrar, databasservrar och e-postservrar.

"INSIDE NT UTILITIES"

Om du har använt Filemon, Regmon eller HandleEx och vill veta mer om vad de berättar för dig och hur de implementeras är du intresserad av kolumnen February Windows NT Magazine, "Inside NT Utilities". I den här kolumnen beskrivs de interna verktygen, och för Regmon och Filemon får du lite information om de felkoder och begärandetyper som de loggar när register- eller filsystemaktiviteten fångas. En länk till den onlinebaserade versionen av den här artikeln, som precis har blivit tillgänglig, finns på http://www.sysinternals.com/publ.htm.

KOLUMNEN MIN MAY WINDOWS NT MAGAZINE

Har du någonsin funderat Windows hur NT/2000 organiserar registrets innehåll i minnet eller på disk? Det aktuella (maj)-problemet med Windows NT Magazine innehåller min kolumn , "Inside the Registry", som visar detta och mycket mer. Du kan till exempel lära dig hur Konfigurationshanteraren-undersystemet i kernelläge (det undersystem som ansvarar för att hantera registret) söker efter nycklar, lagrar värdedata, optimerar sökning och skyddar integriteten för registrets filer på disk. Windows NT Magazine, http://www.winntmag.com , finns på Borders and Barnes and Nobles.

INTE SÅ NYA SAKER

Inte så lång tid efter att Windows 2000 Beta 2 släpptes tog jag den kontrollerade (felsöknings) versionen av kernelavbildningsfilen (ntoskrnl.exe), gjorde en strängsökning på kerneln och tog fram en lista över namnen på källfilerna som användes för att skapa kerneln. Den kontrollerade versionen av NT/2000-kerneln innehåller flera Assert-instruktioner (konsekvenskontroller) som innehåller filnamnet för filen där Assert finns. Om vi antar att praktiskt taget alla filer av betydelse i kernelkällan kommer att ha minst en Assert i sig, är listan ganska omfattande. Att dumpa listan i ett Java-skript gav mig en fin Explorer-liknande trädvy över katalogstrukturen för Windows 2000-källträdet. Kolla in det på http://www.sysinternals.com/nt5src.htm.

INTERNT NYHETER

DR. GUI:S DÅLIGA SÄTT PÅ SIDAN

I mars/april-problemet med Microsoft Developer Network News Dr. GUI visas en fråga från en läsare som frågar hur en drivrutin kan tillhörighetsisera (tvinga att använda en specifik PROCESSOR) dess trådar. Dr. GUI svarar att det inte finns något sätt att fastställa antalet processorer i ett system från en drivrutin och att en drivrutinstråd inte kan se vilken processor den körs på. Tyvärr har dr GUI utser den här diagnosen (dr. GUI kanske bör hålla sig till GRAFISKA).

NT-kerneln (ntoskrnl.exe) exporterar en variabel med namnet KeNumberProcessors som definieras i NTDDK. H som:

extern PCCHAR KeNumberProcessors;

Den kan refereras direkt i en drivrutin så här:

CHAR    i;

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

    // do processor specific stuff
}

För att avgöra vilken processor en drivrutinstråd körs på använder du KeGetCurrentProcessorNumber(), en annan kernelexport som inte bara definieras i NTDDK. H, men dokumenteras faktiskt i DDK!

Dr. GUI skrev ut fel för den här frågan, så jag berättar för dr.et via ett e-postmeddelande. Överraskande nog bekräftade dr GUI aldrig ens e-postmeddelandet. Vi ska se om den gode Dr. fesses fram till felet i nästa problem...

WINDEV '99 EAST

1999 års east coast-utgåva av Premier Conference för Windows utvecklare närmar sig snabbt. WinDev '99 East äger rum den 14–18 juni på Boston Marariot. Ett antal stora namn i Windows utveckling talar, däribland Jeff Richter, Jeff Prosise och Don Box. Jag kommer att vara där med Brian Hanrahan och Brian Catlin i enhetsdrivrutinens spår. Mina presentationer innehåller en dag lång självstudie om NT internt, samt en om att skriva Windows NT/2K-filsystemdrivrutiner och en om avancerade problem med utveckling av enhetsdrivrutiner. Kom och säg hej!

NUMEGA DRIVER WORKS FRISLÄPPNING

Compuware NuMega Labs är på väg att lansera en kraftfull ny Windows 9x/NT/2K-enhetsdrivrutin development kit, DriverStudio. DriverStudio kombinerar alla NuMega-verktyg för enhetsdrivrutiner, inklusive DriverAgent, DriverWorks, SoftICE och VtoolsD, och lägger till nya BoundsChecker för drivrutiner och FieldAgent (endast Windows NT/2K).

Enhetsdrivrutinsversionen av BoundsChecker ger omfattande övervakning av varje kernel-API som drivrutinen använder, och du kan använda den för att övervaka drivrutinens interaktioner med andra enhetsdrivrutiner i systemet. Med FieldAgent kan du distribuera drivrutinsversionen av BoundsChecker till klientsystem så att klienter kan samla in spårningar åt dig som du kan analysera. Kommer snart som en kostnadsfri uppdatering för DriverStudio-kunder är TrueTime för drivrutiner och TrueCoverage för drivrutiner, verktyg som gör att du enkelt kan finjustera prestanda och täckning testa dina enhetsdrivrutiner.

Det här paketet är den ultimata development kit och jag rekommenderar det starkt (jag är med i betaprogrammet). Läs mer på http://www.numega.com.

BETA 3 DDK UTGIVEN

I samband med lanseringen av Windows 2000 Beta 3 har Microsoft gjort tillgängligt för kostnadsfri nedladdning av Windows 2000 Beta 3 DDK (Device Driver Kit). Du kan hämta DDK på http://www.microsoft.com/ddk/ddk2kb3.htm. Jag hoppas att SDK kommer att följa snart, eftersom det finns ett antal Win32-API:er i Beta 3 som inte dokumenteras från aprilversionen av MSDN.

WIN2K-KÖADE SPINLOCKS

Windows 2000 använder en ny typ av spinlock som kallas en "köad spinlock" för sina globala lås. De globala låsen i Windows 2000 är desamma som för Windows NT 4.0 och inkluderar:

  • KiDispatcherLock: scheduler-databaslåset
  • KiContext-SwapLock: tread-växlingslåset
  • MmPfnLock: det fysiska sidramdatabaslåset
  • MmSystemSpaceLock: adressutrymmets lås i kernelläge
  • CcMasterSpinLock: cachehanterarens globala spinlock
  • CcVacbSpinLock: Cachehanterarens mappningsmatrislås

På en enprocessor i kö fungerar spinlocks precis som vanliga spinlocks. I nt-versionen med flera processorer skiljer sig dock köade spinlocks avsevärt åt. Precis som standard-spinlocks implementeras köade spinlocks i AREA. Tthe kernel anropar FUNCTION-funktionen för att hämta en köad spinlock, och den anropar för KeAcquireQueuedSpinlock att släppa en KeReleaseQueuedSpinlock köad spinlock. KeAcquireSpinlock och , DE FUNKTIONER som kerneln använder för att hämta och släppa standard-spinlocks, kräver adressen för KeReleaseSpinlock det angivna spinlocket som en parameter. Däremot tar de köade spinlock-funktionerna indexnumret för ett globalt spinlock. Kerneln initierar de globala spinlocks i en matris, där varje spinlock har ett fördefinierat indexnummer som kerneln använder för att identifiera dem förREG. Därför kan inte köade spinlock definieras och användas av enhetsdrivrutiner, eftersom det inte finns något sätt att utöka den globala spinlockmatrisen i kö.

I Windows 2000 har varje processorkontrollregion (PCR) i en SMP (det finns en PCR för varje processor) en matris med så många poster i sig som det finns köade spinlocks. Varje matrispost innehåller två fält: en pekare till den köade spinlock som den motsvarar (fältet "spinlock" och "queue". När jag refererar till spinlock- och köfälten i följande beskrivning pratar jag om de fält som är associerade med matrisposten för det spinlock som förvärvas eller släpps.

KeAcquireQueuedSpinlock fungerar så här: funktionen försöker hämta spinlock genom att använda cpu-instruktionen för interlocked-exchange för att placera adressen till den aktuella processorns PCR i spinlocket. Om spinlocket hålls kvar har funktionen, som en del av utbytesåtgärden, adressen till en annan processors PCR. Sedan identifierar sig funktionen som "väntar" genom att växla den låga delen av spinlockfältet i sin egen PCR. Därefter placerar den sin egen PCR-adress i köfältet för den PCR som den hämtade från spinlock. Slutligen väntar den i en upptagen loop tills den låga biten toggleds av i sitt spinlock-fält när biten är avstängd, sedan har den aktuella processorn beviljats spinlock och därför återgår den till anroparen av funktionen acquire.

När en processor har köpt en köad spinlock och slutfört bearbetningen som den ville göra medan den håller låset anropas KeReleaseQueuedSpinlock . KeReleaseQueuedSpinlock tittar på köfältet för den angivna spinlocken i den aktuella processorns PCR. Om köfältet inte är noll har en annan processor "i kö" sin PCR där. KeReleaseQueuedSpinlock rensar den låga delen av spinlockfältet för den väntande PCR:n och rensar sedan sitt eget köfält och returnerar. Genom att rensa den låga biten i den väntande PCR:ns spinlockfält har den precis signalerat till nästa processor i rad att den kan ha låset. Om köfältet var noll väntar ingen annan processor på låset och utför bara en sammanflätad utbytesåtgärd för att rensa det KeReleaseQueuedSpinlock globala spinlocket.

Driften av köade spinlocks är en där processorer "radas upp" och väntar på ett spinlock som hålls kvar. Varje processor köar sig själv genom att tala om för den som ligger före den på rad att den väntar. Detta ger en deterministisk ordning för förvärv av en köade spinlockprocessorer som hämtar spinlock-låset i den ordning som de begär det. För standard-spinlocks finns det ingen sådan ordning. Köade spinlocks har en annan större fördel. När en processor snurrar och väntar på att dess spinlockfält ska få den låga biten rensad, snurrar den på minne privat till sin egen processor. När en processor är upptagen väntar på en standard-spinlock, så sätts den igång på själva det globala spinlocket, som delas av alla processorer. Därför har köade spinlocks bättre egenskaper för buss med flera processorer eftersom det inte finns någon delad cacheradsåtkomst under den upptagen väntan. På grund av köande spinlocks köer finns det dessutom vanligtvis färre busslåsåtgärder än för standard-spinlocks när ett lås är under contention från flera processorer.

Köade spinlocks är en av flera förbättringar som Microsoft har gjort skalbarheten för flera processer Windows 2000.

DET HÄR ÄR VAD SOM HÄNDER

Windows 2000 innehåller flera funktioner som gör den mer motståndskraftig mot operatörsfel och program som inte fungerar som de ska. En av dem är att många av DLL:erna och drivrutinerna under katalogen och skyddas av en watchdog med namnet %systemroot%\system32%systemroot%\system32\drivers System File Protector (SFP). Du kan kontrollera att den finns genom att gå till system32 den katalogen och byta namn på ntoskrnl.exe . Watchdog aktiveras och meddelar dig att den har upptäckt manipulering av en skyddad systemfil och reparerar den. Om du tittar i katalogen igen ser du att ntoskrnl.exe har ersatts av ett magiskt sätt. Nästa gång ska jag berätta hur det fungerar.


Tack för att du läser nyhetsbrevet Systems Internals.

Publicerad lördag 15 maj 1999 19:15 av mör

[Newsletters Archive ^][ Volume 1, Number 1][Volume 1, Number 3 ]

[Newsletters Archive ^][ Volume 1, Number 1][Volume 1, Number 3 ]

Systems Internals Newsletter Volym 1, nummer 2

http://www.sysinternals.com