[Nyhetsbrev arkiv ^][Volym 1, nummer 2 >]
System Internals Newsletter Volym 1, Nummer 1
14 april 1999 – I det här problemet:
NYHETER PÅ SYSTEM INTERNALS
- VolumeID för Windows 9x
- EFSDump
- Lista DLL:er för Compaq Alpha
- "Inuti startprocessen, del 2"
- Min april Windows NT Magazine artikel
- Ingen kredit där den förfaller
- Inte så nya saker
INTERNALS NEWS
- Win2K-drivrutinsverifierare
- Y2K-testning med Boot.ini
VAD KOMMER UPP
- Köade spinlocks i Win2K
- Tokenmon
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 första delen av System Internals Newsletter. Jag är glad att kunna säga att nyhetsbrevet redan har förvärvat 1000 prenumeranter sedan tillkännagivandet för drygt en vecka sedan.
Mitt mål i nyhetsbrevet är att ge dig aktuell information om nya verktyg och artiklar som visas på System Internals, plus ge dig tidbitar av information om Windows interna som inte har ett lämpligt forum på System Internals webbplats. Om du har några kommentarer eller förslag om nyhetsbrevet kan du skicka dem till mig på mark@.... Vidarebefordra även nyhetsbrevet till alla som du känner som kan vara intresserade av det. Instruktioner om hur du prenumererar, avregistrerar eller ändrar din prenumeration finns i slutet av nyhetsbrevet.
Tack!
-Markera
NYHETER PÅ SYSTEM INTERNALS
VOLUMEID FÖR WINDOWS 9X
Medan Windows NT och Windows 9x låter dig ändra etiketten på en logisk enhet eller diskett med hjälp av kommandot "etikett", ger de inget sätt för dig att kunna ändra de volym-ID:n som de godtyckligt tilldelar när du formaterar enheter. VolumeID-programmet, som har varit tillgängligt för Windows NT på webbplatsen System internals i över ett år, har just portats till Windows 9x. Med den här appleten kan du ändra volym-ID:t på hårddiskar och disketter till vad du vill.
VolumeID använder API:er som gör det möjligt för program att läsa och skriva direkt till logiska enheter och på Win9x, fysiska enheter (diskettdiskar) som kringgår filsystem. I Windows NT/2K Använder VolumeID vanlig ReadFile och WriteFile för att få åtkomst till rådata – tricket är hur den anger namnet på den volym som den vill komma åt. Du kan ta reda på hur du kommer åt fysiska eller logiska enheter från ett program under Artikeln Windows NT/2K i Microsoft Knowledge Base Q100027. För Windows 9x-åtkomst till logiska enheter kan du basera koden på exempelkod som finns i Microsoft Knowledge Base-artikeln Q174569. Om du behöver utföra direkt diskettenhetsåtkomst från ditt program på Windows 9x använder du Win32 IOCTL-VWIN32_DIOC_DOS_INT13, som dokumenteras i MSDN.
Ladda ned VolumeID på http://www.sysinternals.com/misc.htm.
EFSDUMP
Windows 2000 kommer att bli debuten för Microsofts inbyggda filkrypteringsteknik, Encrypting File System. Med EFS kommer ett antal nya API:er för att manipulera krypterade filer, inklusive en, QueryUsersOnEncryptedFile, som låter dig se vilka användare som är registrerade för att ha åtkomst till krypterade filer och vilka användare som är registrerade som återställningsagenter för dessa filer. Jag har skrivit ett litet program som heter EFSDump som gör att du enkelt kan se denna information för krypterade filer i systemet.
Medan jag är på frågan om EFS API:er finns det antal nya API:er som inte har dokumenterats från och med aprils MSDN, något ganska störande i detta sena skede i Windows 2000-versionscykeln. Framför allt är OpenEncryptedFileRaw, ReadFileEncryptedRaw, WriteFileEncryptedRaw och CloseEncryptedFileRaw (alla exporteras av Win2K:s ADVAPI32.DLL) alla för närvarande odokumenterade. Användningen av dessa API:er krävs av alla program som vill säkerhetskopiera krypterade filer, vilket innebär att microsoft antingen skickar information om dem bara för att välja partner, eller att företag med säkerhetskopieringsprogramvara måste skynda sig för att få ut sina produkter när Microsoft så småningom dokumenterar dem offentligt. En sak är säker, utvecklarna av Windows 2000:s NTBACKUP-program har redan haft åtkomst till API-dokumentationen: Win2K Beta 3:s NTBACKUP använder aktivt API:erna.
Om du är intresserad av EFS internals kan du kolla in min kommande tvådelade serie i juni/juli på EFS i kolumnen "NT Internals" i Windows NT Magazine. I artikeln beskriver jag exakt var FEK:er (filkrypteringsnycklar) och användarens EFS-nycklar lagras, hur krypteringsprocessen utförs av NTFS, EFS-drivrutinen och LSASRV (undersystemservern för lokal säkerhetsmyndighet) och naturligtvis hur dekryptering fungerar.
Ladda ned EFSDump med fullständig källkod på http://www.sysinternals.com/misc.htm.
LISTDLLS FÖR COMPAQ ALPHA
Antalet tillgängliga verktyg för Alpha at Systems Internals fortsätter att öka. Det senaste tillägget är ListDLLs, ett kommandoradsverktyg som gör att du kan visa DLL-information för processer som körs. Med mitt HandleEx-verktyg kan du se den här informationen, samt information om de referenser (filer, processer, trådar, synkroniseringsobjekt) som processerna har öppnat, men HandleEx är ett GUI-verktyg så det är inte alltid praktiskt (det kan till exempel inte köras i en batchfil).
Är du nyfiken på förhållandet mellan nedladdningar av x86-versionen av typiska System Internals-verktyget till motsvarande Alpha-version? Dess cirka 20:1, som noggrant spårar branschens uppskattningar av den installerade Alpha NT-användarbasen som 5% av den totala NT-marknaden.
Du kan ladda ned list-DLL:er och andra Alpha-portar, inklusive HandleEx, på http://www.sysinternals.com/alpha.htm.
"INUTI STARTPROCESSEN, DEL 2"
Min "NT Internals"-kolumn i januari från Windows NT Magazine är nu tillgänglig online via Webbplatsen för Windows NT Magazine. Du hittar en länk till den, samt till del 1 och äldre "NT Internals"-kolumner, på sidan Publikationer på System Internals: http://www.sysinternals.com/publ.htm.
MIN APRIL WINDOWS NT MAGAZINE ARTIKEL
Se också till att ta en titt på min funktionsartikel i aprilnumret av Windows NT Magazine, "Linux och Enterprise". Jag avslöjar flera viktiga problem med linux 2.2-kernel- och nätverksserverprogram ("företagsprogram") som i slutändan kommer att förhindra att den här versionen av Linux-kerneln konkurrerar med NT och andra UNIX-varianter när det gäller prestanda.
INGEN KREDIT DÄR DEN FÖRFALLER
I ett relaterat meddelande kanske du har hört talas om den nyligen släppta D.H. Brown (ett analytikerföretag) om Linux-funktioner som ett företagsoperativsystem. Det visar sig att författaren till rapporten kraftigt "lånat" från ett e-postmeddelande till mig som någon offentligt publicerade till Linux-kerneln Usenet-diskussionsgruppen redan i januari. Om du har åtkomst till rapporten och läser sidorna (44 och 45) som diskuterar Linux och flera processorer (rapporten är inte offentligt tillgänglig - du måste köpa den för en rejäl summa) och sedan läsa mitt e-postmeddelande på Deja News, ser du en direkt parallell, ner till små detaljer.
INTE SÅ NYA SAKER
Jag använder det här avsnittet i nyhetsbrevet för att ta upp de senaste ändringarna på webbplatsen System internals som du kanske inte känner till och/eller för att ge mer information om ett verktyg än vad som är tillgängligt på webbplatsen. För ett par veckor sedan släppte vi till exempel Filemon v4.1. Den här versionen av Filemon kan övervaka både namngivna pipe- och e-postfackaktiviteter under Windows NT/2K. Förbättringen av den kod som krävdes för att stödja detta var relativt liten, eftersom Namngivna pipes och Mailslots implementeras som filsystemdrivrutiner. Den svåra delen (omständlig) var att räkna ut de privata IOCTLs (I/O-kontrollkommandon) som dessa särskilda filsystem stöder så att Filemon kan visa dem. Du kan ladda ned Filemon (som fungerar på Windows NT/2K och Windows 9x) på http://www.sysinternals.com/filemon.htm.
Om du vill veta mer om hur Filemon fungerar internt kan du läsa kolumnen Windows NT Magazine "NT Internals" i februari, som har titeln "Inside NT Utilities". Artikeln beskriver hur du använder Filemon, Regmon, NTFSDOS, NewSID och HandleEx och berättar lite om hur de fungerar.
INTERNALS NEWS
WINDOWS 2000 DRIVER VERIFIER
Windows 2000 Beta 3 introducerar ett mycket kraftfullt utvecklingshjälpmedel för enhetsdrivrutiner som kallas drivrutinsverifierare. Det här verktyget fungerar med kod i kerneln för att få kontroll över drivrutinen och använda den för att följa kernellägesregler på ett sätt som inte tidigare var möjligt. Buggy-enhetsdrivrutiner är det överlägset viktigaste bidraget till ryktet bland många människor att NT är ett instabilt operativsystem, och det här verktyget syftar till att reparera det ryktet genom att hjälpa förarförfattare att hitta sina buggar innan användarna gör det.
Flera typer av subtila problem kan göra det genom tillfällig förartestning (den vanligaste typen av testning som utförs under snäva begränsningar för tid till marknad) och till och med glida igenom allvarliga stresstester. En typ av vanligt drivrutinsproblem är en drivrutin som får åtkomst till sidminnet vid "förhöjd IRQL" (hög avbrottsprioritet). Om minnet som drivrutinen kommer åt råkar vara fysiskt närvarande vid tidpunkten för åtkomsten (den har inte blivit utsidesad till växlingsfilen) kommer den olagliga åtkomsten att gå obemärkt förbi. Släpp en drivrutin som bryter mot den här regeln i vilda användare och dess bindning att dyka upp, vilket resulterar i en blåskärmskrasch.
En annan typ av vanligt drivrutinsprogrammeringsfel är att en utvecklare skriver koden med antagandet att sid- och/eller icke-sidbaserat minne alltid är tillgängligt, dvs. de kontrollerar inte returvärdena för allokeringar. Om poolen tar slut och drivrutinen tar emot en NULL-buffertadress avrefererar drivrutinen glatt systemet till en blå skärm. Även om poolöverbelastning är en sällsynt händelse är det inte något som bör ge en systemadministratör en blå skärm. En relaterad minnesbugb är en buffertöverskridning eller underkörning, där en drivrutin läser eller skriver utanför en buffert som den har allokerat.
Drivrutinsverifieraren hanterar IRQL-problem genom att ersätta anrop till alla funktioner som manipulerar IRQLs i en drivrutin (t.ex. KeRaiseIrql, KeAcquireSpinLock) med motsvarande kontrollantkärnningsfunktioner (VerifierKeRaiseIrql, VerifierKeAcquireSpinLock) när drivrutinen läses in. När IRQL höjs till DISPATCH_LEVEL eller högre anropar kontrollantkoden en intern Memory Manager-funktion, MmTrimAllPageableSystemMemory(), för att tvinga bort alla sidsidiga data från det fysiska minnet. Så fort en drivrutin bryter IRQL-regeln om att inte komma åt växlingsbara data eller kod från DISPATCH_LEVEL eller högre, identifierar Minneshanteraren försöket att komma åt en icke-närvarande sida och kasta en blå skärm. Detta gör att en utvecklare snabbt kan fånga dessa typer av buggar innan drivrutinen kommer ut genom dörren eftersom de kan felsöka kraschen och se sin drivrutin sitta på felstacken.
Drivrutinsverifieraren utför minnesanvändningstestning där importtabellen för drivrutinen korrigeras så att drivrutinen anropar kontrollantminnesfunktioner i stället för standardkärnornas versioner. Ett anrop till ersätts till ExAllocatePool exempel med ett anrop till VerifierAllocatePool. Det finns två tekniker som kontrollanten använder för att hjälpa en utvecklare att snabbt hitta minnesbuggar. Den första är att den använder en särskild minnespool där en skyddssida (en skyddssida är en ogiltig sida) placeras precis efter buffertens slut. Dessutom fylls den del av sidan där bufferten allokeras som före bufferten med en signatur. Överskridanden som finns på en sida utanför slutet av en buffert identifieras omedelbart eftersom de resulterar i ogiltiga sidfel på skyddssidan. Underkörningar som omfattar ändringar av data som föregår en buffert identifieras av kontrollanten när drivrutinen frigör minnet, eftersom signaturen kommer att ha ändrats.
Drivrutiner som alltid förväntar sig en icke-tom pool kommer att luras att generera krascher av kontrollanten med hjälp av dess "minnesfelinmatning". Du kan konfigurera verifieraren så att den slumpmässigt misslyckas med en drivrutins poolallokering.
Det finns en handfull andra feltyper som drivrutinsverifieraren söker efter, inklusive IRP-konsekvens (I/O-begärandepaket) och skrivskydd för system- och drivrutinskodsidor.
Om du är en enhetsdrivrutinsutvecklare kommer du att göra dig själv, ditt företag och NT-communityn en tjänst genom att testa med kontrollanten. Observera att du också bör testa dina NT 4.0-drivrutiner som är kompatibla med Win2K så snart du har åtkomst till drivrutinsverifieraren (de flesta utvecklare kommer att få den med MSDN:s leverans av Win2K Beta 3 i slutet av april eller maj).
Mer information finns i Drivrutinsverifierare.
Y2K-TESTNING MED START. INI
Om du ofta kontrollerar webbplatsen System internals är du förmodligen redan medveten om den nya Win2K-odokumenterade BOOT. INI-växel, /YEAR. Jag nämnde inte på webbplatsen att växeln också stöds av NT 4.0 Service Pack 4. Med den här växeln kan du förfalska NT och all programvara i ett NT-system för att tro att det är ett annat år. Till exempel skulle /YEAR=2001 få systemet att tro att det var 2001 i stället för 1999. Växeln är därför perfekt för testning av Y2K-problem på valfri programvarunivå, och fördelen med att använda den i stället för att manuellt återställa BIOS-klockan (via t.ex. klockäpplet) är att ändringen är tillfällig och endast aktiv när du startar till en installation som har växeln närvarande i sin BOOT. INI-rad. Detta gör det enkelt att skapa en speciell Y2K-installation genom att helt enkelt ta en befintlig startlinje från BOOT. INI, duplicera den och lägga till /YEAR-växeln.
VAD KOMMER UPP
Förvänta dig nästa nyhetsbrev om några veckor. Det interna tipset jag kommer att ha för dig nästa gång handlar om Queued Spinlocks, en ny typ av spinlock som Windows 2000 använder för sina globala spinlocks. Här är de globala spinlocks som finns i Windows 2000:
- 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: Cache Manager:s globala spinlock
- CcVacbSpinLock: CacheHanterarens mappningsmatrislås
I stället för att använda vanliga kernelspinlocks (KeAcquireSpinLock, KeReleaseSpinLock) för dessa globala lås som NT 4.0 gjorde använder Windows 2000-kerneln köade spinlocks (KeAcquireQueuedSpinLock, KeReleaseQueuedSpinLock). Dessa lås har några intressanta egenskaper som minimerar bussaktiviteten på SMP:er. Nästa gång ska jag berätta hur köade spinlocks implementeras.
Kommer snart på System Internals är Tokenmon, ännu ett övervakningsverktyg. Tokenmon visar detaljerad information om all tokenrelaterad aktivitet i systemet, inklusive inloggningar, utloggningar, användning av privilegier och personifiering.
Tack för att du läser System Internals Newsletter.
Publicerad onsdag 14 april 1999 19:16 av ottoh