Dela via

  • Artikel

[Nyhetsbrev arkiv ^][< Volym 1, nummer 1][Volym 1, nummer 3 >]

System Internals Newsletter Volym 1, Nummer 2

http://www.sysinternals.com

15 maj 1999 – I det här problemet:

  1. NYHETER PÅ SYSTEM INTERNALS

    • Sdelete
    • Win2K-uppdatering för BlueScreen-skärmsläckare
    • "Linux och Enterprise"
    • "Inuti NT-verktyg"
    • Min maj Windows NT Magazine Kolumn
    • Inte så nya saker

  2. INTERNALS NEWS

    • Dr GUI's Poor Bedside Manners
    • WinDev '99, östra
    • Numega Driver Works Release Överhängande
    • Beta 3 DDK släppt
    • Win2K-köade spinlocks

  3. VAD KOMMER UPP

    • Win2K System File Protector (SFP)

SPONSOR: WINTERNALS SOFTWARE

Nyhetsbrevet System Internals sponsras av Winternals Software, på webben på http://www.winternals.com. Winternals Software är den ledande utvecklaren och leverantören av avancerade systemverktyg för Windows NT/2K. Winternals Software-produkter inkluderar 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 Systems Internals nyhetsbrev. Nyhetsbrevet har för närvarande 2700 prenumeranter, och prenumerationerna är fortfarande starka.

Sedan det senaste nyhetsbrevet har Microsoft officiellt släppt Windows 2000 Beta 3. Versionsnumret för Beta 3-kerneln är 2031, medan NT 4.0:s ursprungliga versionskärna var 1381 och NT 3.51 hade ett versionsnummer 1025. . Vad jag tycker är konstigt (och något irriterande), är att Microsoft ökar byggnumret varje gång de gör en fullständig version av operativsystemet (varje arbetsdag), men det rapporterade byggnumret för kerneln återspeglar den ursprungliga offentliga versionen. Även om det faktiska versionsnumret för NT 4.0 Service Pack 5-kerneln är mycket högre än 1381 rapporterar kerneln fortfarande 1381 som versionsnummer.

Beta 3-versionen av Windows 2000 är avsedd att vara en väckarklocka för utvecklarcommunityn. Microsoft har meddelat att det kommer att leverera Windows 2000 i oktober, och att Beta 3 representerar den funktions kompletta versionen av vad som kommer att levereras, så utvecklare kan börja skriva nya produkter utan rädsla för att saker kommer att förändras under dem.

Windows 2000 levereras med en mängd nya API:er, lagertjänster och kernelförbättringar. En ändring som kommer att vara 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änktids- 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 endast stoppkoden och associerade adressrader (adressrader översätter en eller flera av stoppkodsparametrarna till platser inom enhetsdrivrutinerna) tillsammans med ett utförligt meddelande. Supportmeddelandet antyder att du kontrollerar dina BIOS- och hårddiskinställningar och inaktiverar defragmentering av programvara och virusskannrar för att försöka undvika att få kraschen igen. Microsoft Premier Support Services (PSS) fastställde, baserat på deras erfarenhet och kundfeedback, att BSOD i NT 4-format inte är användbart för att fastställa orsaken till en krasch.

Jag hittade personligen den inlästa drivrutinslistan, och i synnerhet stackdumpen, att vara användbar när du får rapporter om drivrutinsfel från användare, det är mycket enklare och snabbare att få denna information än att ha användare att skicka en kraschdump på flera megabyte. Jag har ofta isolerat orsaken till krasch baserat på stackdumpen och verifierat drivrutinsversioner som användarna har läst in baserat på versionsinformationen som visas i drivrutinslistan. Jag är nyfiken på att veta vad du tycker: vill du se NT 4-stil BSOD förs vidare till Windows 2000, eller är det nya BSOD-formatet tillräckligt? Skicka mig ett e-postmeddelande om du har en åsikt. Jag ska rapportera resultatet av denna informella omröstning i nästa nyhetsbrev. Medan jag är på ämnet för BSODs, se till att kolla in Windows 2000-uppdateringen av den ständigt populära System Internals BlueScreen Skärmsläckare, som beskrivs i det här problemet.

Tack!

-Markera

NYHETER PÅ SYSTEM INTERNALS

SDELETE

Som en del av windows NT 4.0 som uppfyller kraven för C2-säkerhetsklassificering implementeras "skydd mot återanvändning av objekt". Det innebär att NT nollar fil- och minnesresurser som program allokerar när programmen kommer åt resurserna för första gången. Detta förhindrar till exempel att ett program skapar en stor fil och undersöker dess innehåll för att se vad som tidigare lagrats på disken. Skydd mot återanvändning av objekt handlar dock inte om att skydda 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 tillhörde 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 syns av verktyg som kringgår operativsystemets skyddsanläggningar. Tillkomsten av EFS (Encrypting File System) har belyst behovet av en säker borttagningsanläggning 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 råkar skrivas över av nya fildata som NTFS tilldelar 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 också 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 komprimerade, krypterade och glesa Windows NT/2000-filer, något som kräver användning av defragmenterings-API:et. SDelete följer försvarsdepartementets clearing och sanering av standard-DOD 5220.22-M, så att du kan vara säker på att när du tar bort data är det borta för alltid.

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, så att du kan verifiera mina påståenden om att det förhindrar att känsliga borttagna data kan återställas.

Du hittar dokumentationen i Defragmenterings-API:et för 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 Microsoft har gjort på NT-startskärmen och BSOD-layouten (Blue Screen of Death) i Windows 2000 gjorde att System Internals BlueScreen Screen Saver krävde en större uppdatering. För att fortsätta att ge dig det yttersta i BSOD-realism, har jag släppt version 2.0 av skärmsläckaren. Det återspeglar inte bara ändringarna i BSOD-formatet, utan efterliknar också exakt Startskärmen för Windows 2000, komplett med roterande förloppsremsa och uppdateringar av förloppsindikatorn. Det är så verkligt att skärmsläckaren kommer att lura även Windows 2000 expertanvändare och utvecklare. Naturligtvis, under NT 4.0 BlueScreen Skärmsläckare fortfarande presenterar NT 4.0 BSOD och startskärmar.

Hur återskapade jag Startskärmen för Windows 2000 så perfekt och samtidigt inte bryter mot upphovsrättslagarna? Jag inkluderar inte bitmappsgrafiken för Windows 2000-start 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 bitmappsresurserna 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 att datoroperativsystem 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 humoristisk historia relaterad till att lura någon med skärmsläckaren, skicka den vidare.

Du kan ta reda på mer information om hur och varför är bsods i min december 1997 Windows NT Magazine NT Internals kolumn, "Inuti den blå skärmen". En länk på sidan System interna publikationer, , http://www.sysinternals.com/publ.htmtar dig till den on-line versionen av den kolumnen. Sidan innehåller också länkar till andra onlinepresentationer av artiklar och kolumner som jag har skrivit.

"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 fått tidningen att publicera den on-line 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. Artikeln beskriver flera begränsningar för den aktuella versionen av Linux-kerneln (2.2x), inklusive brist på en effektiv mekanism för händelsevänte, betydande systemanropsserialisering, ingen asynkron I/O och en dålig implementering av sendfile-socket-API:et (i NT kallas TransmitFile). Kombinationen av dessa begränsningar hindrar Linux från att konkurrera med NT och andra UNIX-datorer, vad gäller prestanda, för företagsprogram 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, kommer du att vara intresserad av min Windows NT Magazine-kolumn i februari, "Inside NT Utilities". Den här kolumnen beskriver de interna funktionerna i dessa verktyg, och för Regmon och Filemon berättar du lite om felkoderna och begärandetyperna som de loggar när de samlar in register- eller filsystemaktivitet. En länk till onlineversionen av den här artikeln, som just har blivit tillgänglig, finns på http://www.sysinternals.com/publ.htm.

MIN MAJ WINDOWS NT MAGAZINE KOLUMN

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

INTE SÅ NYA SAKER

Inte långt efter att Windows 2000 Beta 2 släpptes tog jag den kontrollerade (felsöka) versionen av kernelavbildningsfilen (ntoskrnl.exe), gjorde en strängsökning på kerneln och kom med en lista över namnen på källfiler som används för att bygga kerneln. Den kontrollerade versionen av NT/2000-kerneln innehåller många Assert-instruktioner (konsekvenskontroller) som innehåller filnamnet för filen där Assert finns. Förutsatt att nästan varje fil av någon betydelse i kernelkällan har minst en Assert i den, är listan ganska omfattande. Dumpning av listan i ett Java-skript gav mig en fin Explorer-liknande trädvy av katalogstrukturen i Windows 2000-källträdet. Kolla in det på http://www.sysinternals.com/nt5src.htm.

INTERNALS NEWS

DR. GUI:S DÅLIGA SÄNGSKICK

I mars-/april-numret av Microsoft Developer Network News anger Dr. GUI en fråga från en läsare som frågar hur en drivrutin kan mappa sina trådar (framtvinga att använda en specifik PROCESSOR). 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 berätta vilken processor den körs på. Tyvärr, Dr GUI blåste denna diagnos (kanske Dr GUI bör hålla sig till GUIs).

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 ordinerade fel medicinering för denna sjukdom, så jag låter artigt Dr. veta via ett artigt e-postmeddelande. Förvånansvärt nog erkände Dr. GUI aldrig ens e-postmeddelandet. Vi får se om den gode dr fesses upp till felet i nästa problem...

WINDEV '99 EAST

1999 års östkustutgåva av den främsta konferensen för Windows-utvecklare närmar sig snabbt. WinDev '99 East äger rum 14-18 juni på Boston Cambridge Marriot. Ett antal stora namn inom Windows-utveckling talar, inklusive Jeff Richter, Jeff Prosise och Don Box. Jag kommer att vara där med Jamie Hanrahan och Brian Catlin i enhetsdrivrutinens spår. Mina presentationer innehåller en dagslång självstudie om interna NT-filer, samt en om hur du skriver windows NT/2K-filsystemdrivrutiner och en om problem med utveckling av avancerade enhetsdrivrutiner. Kom och säg hej!

NUMEGA DRIVER WORKS RELEASE IMMINENT

Compuware NuMega Labs är på väg att släppa ett kraftfullt nytt Windows 9x/NT/2K enhetsdrivrutinsutvecklingspaket, DriverStudio. DriverStudio kombinerar alla NuMegas befintliga verktyg för enhetsdrivrutiner, inklusive DriverAgent, DriverWorks, SoftICE och VtoolsD, och lägger till den nya BoundsChecker för drivrutiner och FieldAgent (endast Windows NT/2K).

Enhetsdrivrutinsversionen av BoundsChecker ger omfattande övervakning av varje kernel-API som din drivrutin använder, och du kan använda den för att övervaka din drivrutins 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 en gratis uppdatering för DriverStudio kunder är TrueTime för drivrutiner, och TrueCoverage för drivrutiner, verktyg som gör att du enkelt prestanda tune och täckning testa dina enhetsdrivrutiner.

Detta paket är det ultimata drivrutinsutvecklingspaketet, och jag rekommenderar det hjärtligt (jag är på Beta-programmet). Läs mer på http://www.numega.com.

BETA 3 DDK SLÄPPT

I samband med lanseringen av Windows 2000 Beta 3 har Microsoft gjort tillgänglig för gratis nedladdning av Windows 2000 Beta 3 DDK (Device Driver Kit). Du kan hämta DDK:en 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 och med 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: växlingslåset för slitbanan
  • MmPfnLock: databaslåset för den fysiska sidramen
  • MmSystemSpaceLock: adressutrymmeslåset i kernelläge
  • CcMasterSpinLock: CacheHanterarens globala spinlock
  • CcVacbSpinLock: Cachehanterarens mappningsmatrislås

På en uniprocessor i kö fungerar spinlocks precis som vanliga spinlocks. I multiprocessorversionen av NT skiljer sig dock köade spinlocks avsevärt. Precis som standardspinlock implementeras köade spinlocks i HAL. Kerneln anropar HAL-funktionen KeAcquireQueuedSpinlock för att hämta en i kö spinlock och anropar KeReleaseQueuedSpinlock för att släppa en i kö spinlock. KeAcquireSpinlock och KeReleaseSpinlock, de HAL-funktioner som kerneln använder för att hämta och släppa standardspinlocks, kräver adressen till den angivna spinlocken som en parameter. Däremot tar de köade spinlockfunktionerna indexnumret för en global spinlock. Kerneln initierar de globala spinlockarna i en matris, där varje spinlock har ett fördefinierat indexnummer som kerneln använder för att identifiera dem för HAL. Därför kan inte köade spinlocks definieras och användas av enhetsdrivrutiner, eftersom det inte finns något sätt att utöka den globala köade spinlockmatrisen.

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 den som det finns i köade spinlocks. Varje matrispost innehåller två fält: en pekare till den i köade spinlock som den motsvarar (fältet "spinlock" och "kö". I följande beskrivning, när jag refererar till spinlock- och köfälten, pratar jag om fälten som är associerade med matrisposten för spinlocket som förvärvas eller släpps.

KeAcquireQueuedSpinlock fungerar så här: funktionen försöker hämta spinlocket med hjälp av den sammankopplade processorinstruktionen för utbyte för att placera adressen till den aktuella processorns PCR i spinlocken. Om spinlocket hålls 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 biten av spinlockfältet i sin egen PCR. Därefter placerar den sin egen PCR-adress i köfältet i den PCR som den hämtade från spinlocket. Slutligen väntar den i en upptagen-loop tills den låga biten växlas av i dess spinlock-fält när biten är av, sedan har den aktuella processorn beviljats spinlocket och så återgår den till anroparen för den förvärvande funktionen.

När en processor har hämtat en i kö spinlock och slutfört bearbetningen som den ville göra medan låset hålls, 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 "köat" sin PCR där. KeReleaseQueuedSpinlock rensar den låga biten 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: s spinlockfält har den just signalerat nästa CPU i linje att den kan ha låset. Om köfältet var noll väntar ingen annan processor på låset och KeReleaseQueuedSpinlock utför helt enkelt en sammanflätad exchange-åtgärd för att rensa den globala spinlocken.

Driften av köade spinlocks är en där processorer "radar upp" väntar på en spinlock som hålls. Varje processor köar sig själv genom att tala om för den framför den i rad att den väntar. Detta ger en deterministisk ordning till förvärvet av en köad spinlock-processorer som hämtar spinlocket i den ordning som de begär det. För standardspinlock finns det ingen sådan beställning. Köade spinlocks har en annan större fördel. När en processor snurrar i väntan på att spinlockfältet ska få den låga biten rensad snurrar den på minnet privat till sin egen processor. När en processor som är upptagen väntar på en vanlig spinlock snurrar den på själva den globala spinlocken, som delas av alla processorer. Därför har köade spinlocks bättre bussegenskaper för flera processorer eftersom det inte finns någon delad cacheradsåtkomst under den upptagna väntan. Dessutom finns det vanligtvis färre busslåsåtgärder än för vanliga spinlocks när ett lås är under konkurrens från flera processorer på grund av kökaraktären hos köade spinlocks.

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

VAD KOMMER UPP

Windows 2000 innehåller många funktioner som gör det mer motståndskraftigt mot operatörsfel och felaktiga program. En av dem är att många av DLL:er och drivrutiner under %systemroot%\system32 katalogen och %systemroot%\system32\drivers skyddas av en vakthund som kallas System File Protector (SFP). Du kan kontrollera dess existens genom att gå in i katalogen system32 och byta namn på ntoskrnl.exe. Vakthunden vaknar och meddelar dig att den har upptäckt manipulering av en skyddad systemfil och reparerar den. Om du kontrollerar katalogen igen upptäcker ntoskrnl.exe du att den har ersatts magiskt. Nästa gång ska jag berätta hur det fungerar.

Tack för att du läser System Internals Newsletter.

Publicerad lördag 15 maj 1999 19:15 av ottoh

[Nyhetsbrev arkiv ^][< Volym 1, nummer 1][Volym 1, nummer 3 >]