14 april 1999 – I det här problemet:

  1. VAD ÄR NYTT PÅ SYSTEM INTERNALS

    • VolumeID för Windows 9x
    • EFSDump
    • ListDLLs för Compaq Alpha
    • "Inuti startprocessen, del 2"
    • Min artikel om Windows NT Magazine
    • Ingen kredit där förfallo
    • Inte så nya saker
  2. INTERNT NYHETER

    • Win2K-drivrutinsverifierare
    • Y2K-testning med Boot.ini
  3. VAD ÄR PÅ GÅNG

    • Köade spinlocks i Win2K
    • Tokenmon

SPONSOR: UNDERTIDSPROGRAMVARA

Nyhetsbrevet Systems Internals är sponsrat av Fallnals Software, på webben på http://www.winternals.com. Taraa Software är den ledande utvecklaren och leverantören av avancerade systemverktyg för Windows NT/2K. Bland software-produkterna finns FAT32 för Windows NT 4.0, ERD Commander (startdiskkapacitet för Windows NT) och NTRecover.

Hej!

Välkommen till den första installationen av nyhetsbrevet Systems Internals. Jag är glad över att kunna säga att nyhetsbrevet redan har köpt 1 000 prenumeranter sedan det tillkännagivandet för lite över en vecka sedan.

Mitt mål i nyhetsbrevet är att ge dig tidsinformation om nya verktyg och artiklar som visas på System internt, samt ge dig information om Windows internt som inte har ett lämpligt forum på webbplatsen System internt. Om du har några kommentarer eller förslag på nyhetsbrevet kan du skicka dem vidare till mig på mark@.... Vidarebefordra även nyhetsbrevet till alla som du vet kan vara intresserade av det. Anvisningar om hur du prenumererar, tar bort prenumerationen eller ändrar prenumerationen finns i slutet av nyhetsbrevet.

Tack!

-Mark

VAD ÄR NYTT PÅ SYSTEM INTERNALS

VOLUMEID FÖR WINDOWS 9X

Även om Windows NT och Windows 9x låter dig ändra etiketten på en logisk enhet eller diskett med hjälp av kommandot "label" så 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å platsen System internt i över ett år, har precis portats till Windows 9x. Med den här appleten kan du ändra volym-ID:erna på hårddiskar och disketter till vad du vill.

VolumeID använder API:er som gör att program kan läsa och skriva direkt till logiska enheter, och på Fysiska enheter (disketter) på Win9x, vilket kringgår filsystem. På Windows ANVÄNDER NT/2K VolumeID vanlig ReadFile och WriteFile för att komma åt rådata på enheten – tricket är i hur det 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 Windows NT/2K i Microsoft Knowledge Base Q100027. Om Windows 9x-åtkomst till logiska enheter kan du basera koden på exempelkod som finns i Microsoft Knowledge Base Q174569. Om du behöver utföra direkt åtkomst till diskettenheter 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 vara den första delen av Microsofts inbyggda filkrypteringsteknik, krypterande filsystem. Med EFS kommer ett antal nya API:er för att manipulera krypterade filer, inklusive en, QueryUsersOnEncryptedFile, som gör att du kan 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 program som heter EFSDump som gör att du enkelt kan se den här informationen för krypterade filer i systemet.

Jag arbetar med EFS-API:er, men det finns ett antal nya API:er som inte har dokumenterats i aprils MSDN, något som är ganska svårt i det här senare skedet i lanseringscykeln Windows 2000. Främst är OpenEncryptedFileRaw, ReadFileEncryptedRaw, WriteFileEncryptedRaw och CloseEncryptedFileRaw (alla exporteras av Win2K:s ADVAPI32.DLL) för närvarande odokumenterade. Användning 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 enbart för att välja partner eller att företag som säkerhetskopierar programvara måste skicka ut sina produkter när Microsoft så småningom dokumenterar dem offentligt. En sak är säker: utvecklarna av Windows 2000-talets NTBACKUP-program har redan åtkomst till API-dokumentationen: Win2K Beta 3:s NTBACKUP använder aktivt API:erna.

Om du är intresserad av EFS internals ska du kolla in min kommande serie i två delar om EFS i juni/juli 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 den lokala säkerhetsutfärdaren) och naturligtvis hur dekrypteringen 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 växa. Det senaste tillägget är ListDLLs, ett kommandoradsverktyg som gör att du kan visa DLL-information för processer som körs. Med verktyget HandleEx kan du se den här informationen, samt information om handtagen (filer, processer, trådar, synkroniseringsobjekt) som processer har öppnat, men HandleEx är ett grafiskt användargränssnittsverktyg så att det inte alltid är praktiskt (det kan till exempel inte köras i en batchfil).

Är du nyfiken på förhållandet mellan nedladdningar av x86-versionen av vanliga System Internals-verktyg och dess motsvarande Alpha-version? Det är cirka 20:1, vilket nära spårar branschuppskattningarna av den installerade Alpha NT-användarbasen som 5 % av den totala NT-marknaden.

Du kan ladda ned ListDLLs och andra Alpha-portar, inklusive HandleEx, på http://www.sysinternals.com/alpha.htm.

"INUTI STARTPROCESSEN, DEL 2"

Min kolumn "NT Internals" i januari Windows NT Magazine är nu tillgänglig online via Windows NT Magazines webbplats. Du hittar en länk till den, samt till kolumnerna Del 1 och äldre NT Internals på sidan Publiceringar på Systems Internals: http://www.sysinternals.com/publ.htm.

MIN APRILARTIKEL OM WINDOWS NT MAGAZINE

Se även till att ta en titt på min funktionsartikel i aprilnumret av Windows NT Magazine, "Linux and the Enterprise". Jag har flera viktiga problem med Linux 2.2-kernel- och nätverksserverprogram ("företagsprogram") som i slutändan förhindrar att den här versionen av Linux-kerneln konkurrerar med NT och andra UNIX-varianter vad gäller prestanda.

INGEN KREDIT DÄR FÖRFALLO

I ett relaterat meddelande kanske du har hört talas om den nyligen utgivna D.H. Brown (ett analytikerföretag) om Linux-funktioner som ett operativsystem för företag. Det visar sig att rapportförfattaren "lånade" mycket från ett e-postmeddelande som någon publicerade offentligt till Linux-kärnans Usenet-nyhetsgrupp 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 stor summa) och sedan läsa mitt e-postmeddelande på Deja News ser du en direkt parallell, ned till liten information.

INTE SÅ NYA SAKER

Jag använder det här avsnittet av nyhetsbrevet för att ta fram de senaste ändringarna av 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 några veckor sedan släppte vi till exempel Filemon v4.1. Den här versionen av Filemon kan övervaka både aktiviteten Named Pipe och Mail Slot under Windows NT/2K. Förbättringen av koden som krävdes för att stödja detta var relativt liten, eftersom Namngivna pipes och Mailslots implementeras som filsystemdrivrutiner. Det svåra (omständligt) 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 "Inside NT Utilities" i kolumnen February Windows NT Magazine "NT Internals". I artikeln beskrivs hur du använder Filemon, Regmon, NTFSDOS, NewSID och HandleEx, och du får lite information om hur de fungerar.

INTERNT NYHETER

WINDOWS 2000-DRIVRUTINSVERIFIERARE

Windows 2000 Beta 3 introducerar ett mycket kraftfullt utvecklingsstöd för enhetsdrivrutiner som kallas Drivrutinsverifierare. Det här verktyget använder kod i kerneln för att få kontroll över drivrutinen och använda den för att följa regler för kernelläge på ett sätt som inte tidigare var möjligt. Buggiga enhetsdrivrutiner är den överlägset viktigaste bidragen till ryktet hos många människor om att NT är ett instabilt operativsystem och det här verktyget är avsett att reparera det ryktet genom att hjälpa författarna att hitta sina buggar innan användarna gör det.

Flera typer av diskreta problem kan göra det genom informella förartestning (den vanligaste typen av testning som utförs under begränsade tid till marknad) och även passera genom allvarliga stresstester. En typ av vanligt drivrutinsproblem är en drivrutin som kommer åt det sidindelade minnet vid "upphöjd IRQL" (hög avbrottsprioritet). Om det minne som drivrutinen har åtkomst till råkar vara fysiskt närvarande vid tidpunkten för åtkomsten (den har inte bläddrats ut till växlingsfilen) kommer den ogiltiga åtkomsten att gå obemärkt förbi. Släpp en drivrutin som bryter mot den här regeln ut till användarna och dess bundna att visas, vilket resulterar i en krasch på den blå skärmen.

En annan typ av vanligt drivrutinsprogrammeringsfel är att utvecklare skriver koden med antagandet att sidindelade och/eller icke-sidindelade minne alltid är tillgängligt, dvs. att de inte kontrollerar returvärdena för allokeringar. Om poolen tar slut och drivrutinen tar emot en NULL-buffertadress så avar drivrutinen utan problem systemet till en blå skärm. Poolutmattning är en sällsynt förekomst, men det är inte något som bör ge systemadministratören en blå skärm. En relaterad minnesbugg är en buffert som överskrids eller underkörs, där en drivrutin läser eller skriver utanför en buffert som den har allokerat.

Drivrutinsverifieraren åtgärdar IRQL-problem genom att ersätta anrop till alla funktioner som manipulerar IRQLs i en drivrutin (t.ex. , ) med motsvarande kernelfunktioner för verifierare ( , ) när drivrutinen läses KeRaiseIrqlKeAcquireSpinLockVerifierKeRaiseIrqlVerifierKeAcquireSpinLock in. När IRQL höjs till eller högre anropar verifierarkoden en intern Memory Manager-funktion, , för att tvinga ut alla DISPATCH_LEVEL utsidorade data från det fysiska MmTrimAllPageableSystemMemory() minnet. Så fort en drivrutin bryter IRQL-regeln för att inte komma åt sidbara data eller kod från eller högre, identifierar Memory Manager försöket att komma åt en icke-närvarande sida och kastar en DISPATCH_LEVEL blå skärm. På så sätt kan en utvecklare snabbt fånga dessa typer av buggar innan drivrutinen kommer ut genom dörren eftersom de kan felsöka kraschen och se när drivrutinen sitter på felstacken.

Drivrutinsverifieraren utför minnesanvändningstestning med den korrigerar importtabellen för drivrutinen som ska verifieras så att drivrutinen anropar verifierarminnesfunktioner i stället för standard kernel-versionerna. Till exempel ersätts ett ExAllocatePool anrop till med ett anrop till VerifierAllocatePool . Det finns två tekniker som verifieraren använder för att hjälpa utvecklare att snabbt hitta minnesbuggar. Den första är att den använder en särskild pool med minne där en skyddssida (en säkerhetssida är en ogiltig sida) placeras precis i slutet av bufferten. Dessutom fylls den del av sidan där bufferten allokeras före bufferten med en signatur. Överkörningar som finns på en sida utanför slutet av en buffert identifieras omedelbart eftersom de leder till ogiltiga sidfel på skyddssidan. Underkörningar som inbegriper ändring av data före en buffert identifieras av verifieraren när drivrutinen friser 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 verifieraren med hjälp av dess "minnesfelsinjektion". Du kan konfigurera verifieraren så att en drivrutins poolallokeringar misslyckas slumpmässigt.

Det finns några andra feltyper som drivrutinsverifieraren söker efter, inklusive konsekvens i IRP (I/O-begärandepaket) och skrivskydd för system- och drivrutinskodsidor.

Om du utvecklar enhetsdrivrutiner kommer du att göra dig själv, ditt företag och NT-communityn en fördel genom att testa med verifieraren. Observera att du även bör testa dina NT 4.0-drivrutiner som är kompatibla med Win2K så snart du har åtkomst till drivrutinsverifieraren (de flesta utvecklare får den med MSDN:s leverans av Win2K Beta 3 i slutet av april eller maj).

Mer information om drivrutinsverifieraren finns på https://docs.microsoft.com/windows-hardware/drivers/devtest/driver-verifier

Y2K-TESTNING MED BOOT.INI

Om du ofta kontrollerar webbplatsen System internt är du förmodligen redan medveten om den nya odokumenterade Win2K-BOOT.INI växeln/ 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örfalskning av NT och all programvara i ett NT-system tänka att det är ett annat år. Till exempel skulle /YEAR=2001 göra så att systemet tror att det var 2001 i stället för 1999. Därför är växeln 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 (till exempel via klock appleten) är att ändringen är tillfällig och endast aktiv när du startar en installation som har växeln på sin BOOT.INI rad. Detta gör det enkelt att skapa en särskild Y2K-installation genom att ta en befintlig startlinje från BOOT.INI, duplicera den och lägga till växeln /YEAR.

VAD ÄR PÅ GÅNG

Förvänta dig nästa nyhetsbrev om några veckor. Det interna tipset jag har till dig nästa gång är om köade 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:

  • KiÖjatcherLock: scheduler-databaslåset
  • KiContext-SwapLock: tread-växlingslåset
  • MmPfnLock: det fysiska sidramdatabaslåset
  • MmSystemSpaceLock: adressutrymmeslåset för kernelläge
  • CcMasterSpinLock: Cachehanterarens globala spinlock
  • CcVacbSpinLock: Cachehanterarens mappningsmatrislås

I stället för att använda vanliga kernel-spinlocks (KeAcquireSpinLock, KeReleaseSpinLock) för dessa globala lås som NT 4.0 använde Windows 2000-kerneln köade spinlocks (KeAcquireQueuedSpinLock, KeReleaseQueuedSpinLock). De här låsen 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 system internt är Tokenmon, ytterligare ett övervakningsverktyg. Tokenmon visar detaljerad information om alla tokenrelaterade aktiviteter i systemet, inklusive inloggningar, utloggningar, användning av privilegier och personifiering.


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

Publicerad onsdag 14 april 1999 19:16 av sn

[Nyhetsbrevsarkiv ^][Volym 1, nummer 2 ]

[Nyhetsbrevsarkiv ^][Volym 1, nummer 2 ]

System Internals Newsletter Volume 1, Number 1

http://www.sysinternals.com