• Artikel

[Nyhetsbrev arkiv ^][< Volym 1, nummer 4][Volym 2, nummer 1 >]

System Internals Newsletter Volym 1, Nummer 5

http://www.sysinternals.com
Copyright 1999 Mark Russinovich

12 oktober 1999 – I det här problemet:

  1. NYHETER PÅ SYSTEM INTERNALS

    • NTFS för Windows 98/NTFSDOS Professional
    • FelsökView v3.21
    • Filemon och Regmon v4.21
    • Diskmon v1.1
    • System internals på www.microsoft.com
    • Oktober "NT Internals"
    • Inte så nya saker

  2. INTERNALS NEWS

    • Win2K RC2 DDK släppt
    • Nya Win2K RC Kernel-API:er
    • Software Development '99 East
    • Använda DiskEdit

  3. VAD KOMMER UPP

    • Win2K API-explosion

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.

Med Winternals Softwares Remote Recover kan du komma åt enheterna på en dator som inte kan startas via TCP/IP var som helst i företaget. Spara tid och stöd för dollar genom att fjärrkorrigering av drivrutin, filsystem och konfigurationsproblem som håller NT- eller Win9x-system utanför linjen. Du kan till och med utföra fjärr-chkdsk- eller partitioneringsåtgärder med hjälp av Fjärråterställning, vilket gör det till ett mångsidigt haveriberedskapsverktyg. Ladda ned en kostnadsfri skrivskyddad utvärderingsversion på http://www.sysinternals.com/rrecover.htmoch köp läs-/skrivversionen på http://www.winternals.com.

Hej!

Välkommen till nyhetsbrevet System Internals. Nyhetsbrevet har för närvarande 10 000 prenumeranter.

Lanseringen av Windows 2000 (Win2K) verkar följa ett mönster för att bli nära förestående och sedan skjutas tillbaka. De senaste ryktena är att det kommer att bli tillgängligt i februari. Och den enda informationen om Win2K-leveransdatumet är i rykten, eftersom Microsoft inte ens berättar för OEM-tillverkare eller partners när det kommer att levereras. Tja, de är: "det kommer att skickas när det är klart" (jag kommer inte att tvinga daterat talesätt om att sälja vin på dig här).

Det irriterande med Microsoft är att pressen de genererar om sina produkter alltid får det att verka som om de är på väg att levereras även när produkterna är vaporware. Det senaste exemplet är Millennium, efterföljare till Windows 98. Microsoft gjorde för inte så länge sedan en stor push i pressen för det som om det var en färdig produkt, redo att konvertera alla dina hushållsapparater till intelligenta enheter. Ironin är att artiklar en kort tid senare avslöjade att Microsoft inte ens helt har definierat produkten ännu, och det kommer förmodligen att ta ett år eller mer innan vi ser den på butikshyllorna.

Det här mönstret är inte nytt och jag är inte den första att skriva om det. Men det hindrar mig inte från att spekulera om hur mycket av sågningen som är en noggrant orkestrerad plan, och hur mycket är resultatet av en total brist på huvudnamn för programvaruteknik. Om du köper in i den tidigare vinkeln, som konspirationsteoretiker gör, kväver Microsoft briljant konkurrensen genom att locka kunder med den otroliga produkten som, om de väntar bara lite längre, kommer att göra deras väntan värdefull och undanröja alla behov av att vända sig till en produkt som inte är Microsoft. Den senare vinkeln säger att Microsoft aldrig kommer att lära sig programutvecklingsprocessen, och underskattar kontinuerligt den tekniska ansträngningen och överskattar kvaliteten på betakoden.

Jag sitter på staketet om vilken teori jag tillskriver. Jag tror faktiskt att mönstret beror på lite av båda. Jag tror att det har hjälpt Microsoft att agera som Active Directory har nästan varit redo i två år nu. Det finns säkert kunder som skulle ha vänt sig till Novell Directory Services för länge sedan om de hade vetat i förväg hur länge de skulle behöva vänta på Win2K. Å andra sidan har Microsoft fått upprepade svarta ögon i pressen från lovande produktleverans och sedan fördröjning. Jag tror att Microsofts hantering bara inte förstår hur svårt det är att reproducera, isolera och åtgärda de sista 5% av buggarna.

På tal om Microsofts utvecklingsmetoder är deras namngivningsschema före lanseringen ett av de mest förbryllande jag har sett. Deras betaversioner är egentligen Alfa och deras releasekandidater är faktiskt betaversioner. Och även att använda dessa definitioner är en sträcka: Microsoft har inga problem med att rippa funktioner ur sin programvara för att gå från en Release Candidate till nästa, eller till och med lägga till nya. De gjorde det med NT 4.0 och de gör det med Win2K. Den metoden påskyndar verkligen inte en lanseringscykel.

Kommer Win2K att skickas i februari? Jag tror att vi ser ljuset i slutet av tunneln. Det finns trots allt bara en handfull nya API:er i RC2...

Som en uppföljning till det senaste nyhetsbrevet där jag talade om akronym förvirring på Microsoft, läsare George Janczuk hittade ett annat exempel. I avsnittet "Utöka till stordatorns transaktionsbearbetningsvärld" refererar artikeln till http://msdn.microsoft.com/library/backgrnd/html/msdn_windnapps.htm CISC – Komplex instruktionsuppsättningsberäkning. Det är uppenbart för alla som är bekanta med stordatorprogram att den avsedda förkortningen är CICS – Customer Information Control System. En omvänd bokstavssekvens och du befinner dig i ett helt annat teknikområde.

Som vanligt skickar du nyhetsbrevet vidare till vänner som du tror kan tycka att det är intressant.

Tack!

-Markera

NYHETER PÅ SYSTEM INTERNALS

NTFS FÖR WINDOWS 98/NTFSDOS PROFESSIONAL

Vi har äntligen gjort det. Ända sedan Bryce och jag släppte NTFSDOS 1.0 tillbaka i våren 1996 har vi varit på jakt efter den heliga graalen i Windows filsystemkompatibilitet: läs- och skrivåtkomst för NTFS från Windows 9x och DOS. Vi har för länge sedan fastställt att omvänd konstruktion av NTFS-formatet och att skriva en drivrutin för det här komplexa journalningsfilsystemet skulle vara ett svårt och riskabelt förslag. Även om man exakt avgör varje nyans i formatet, kräver en uppdatering av formatet, som Win2K:s NTFS v5.0, en helt ny omvänd teknik- och utvecklingsinsats. Dessutom är validering av korrektheten hos en filsystemdrivrutin för ett format som är lika invecklat som NTFS ett skrämmande förslag.

Så vi fuskade.

NTFS för Windows 98 ger fullständig läs-/skrivåtkomst till NTFS-enheter från Windows 95 eller Windows 98, och NTFSDOS Professional ger fullständig läs-/skrivåtkomst för NTFS från DOS. Varken NTFS för Windows 98 eller NTFSDOS Professional har någon kunskap om NTFS-filsystemformatet. I stället förlitar de sig på NTFS-drivrutinen från en Windows NT- eller Windows 2000-installation för att implementera den kunskapen. Båda verktygen använder samma kodbas som fungerar som en miljöomslutning för NTFS-filsystemdrivrutinen. NTFS för Windows 98 tillhandahåller ett gränssnitt till Windows 9x-filsystem-API:et ovanför NTFS och Windows 9x-disktjänsterna under NTFS. Gränssnittet NTFS för Windows 98 presenterar för NTFS ser ut som NTFS interna Windows NT/2K-miljö, komplett med IRPs, I/O Manager, Cache Manager, NT-liknande diskenheter och andra NT/2K-undersystem som NTFS interagerar med.

NTFSDOS Professional fungerar på samma sätt som NTFS för Windows 98, förutom att det gränssnitt NTFS till DOS-tjänster ovan och BIOS Avbrott 13 disktjänster nedan. För att skapa den NT/2K-liknande miljön förlitar vi oss på många funktioner i NTOSKRNL, NT/2K-kernelfilen. Båda verktygen läser in NTOSKRNL tillsammans med NTFS, så att NTFS kan använda kernelns interna tjänster direkt.

Vi hade så roligt när vi byggde NTFS-miljön att vi gick ett steg längre: vi gjorde samma sak med NT:s chkdsk-verktyg för starttid, Autochk. NTFSDOS Professional och NTFS för Windows 98 levereras med ett NTFS chkdsk-verktyg med namnet NTFSCHK. NTFSCHK fungerar på samma huvudnamn som NTFS-filsystemomslutningen, där den skapar en NT-liknande miljö för Autochk-programmet så att Autochk körs under Windows 95/98 och DOS. Resultatet av det här tricket är fullständigt läs-/skrivstöd för NTFS för Windows 95/98 och för DOS.

Du kan ladda ned en kostnadsfri skrivskyddad version av NTFS för Windows 98 på http://www.sysinternals.com/ntfs98.htm och en kostnadsfri skrivskyddad version av NTFSDOS Professional på http://www.sysinternalscom/ntfspro.htm. Du kan köpa de fullständiga läs-/skrivversionerna av båda verktygen på Winternals Software, http://www.winternals.com.

FELSÖKA V3.21

DebugView är en övervakning av felsökningsutdata som samlar in både kernel- och Win32-felsökningsutdata under Windows 95, Windows 98, NT 4.0 och Windows 2000. Den har avancerade funktioner för filtrering, markering och loggning och kan till och med samla in felsökningsutdata från ett system i ett nätverk. Den senaste versionen, 3.21, introducerar möjligheten att övervaka 16-bitars OutputDebugString-utdata under Windows 95 och Windows 98.

Du kan ladda ned DebugView v3.21 på http://www.sysinternals.com/dbgview.htm.

FILEMON OCH REGMON V4.21

Filemon och Regmon är filsystem och register spioneri verktyg för Windows 95, 98, NT 4.0 och Win2K. De fortsätter att utvecklas med nya användbarhetsfunktioner och med version 4.21 (Filemon och Regmon har synkroniserat versionsnummer) introducerar de mer avancerad filtrering med listor med senaste filter, möjligheten att definiera ett markeringsfilter (med anpassade färger till och med), anpassningsbart teckensnitt, Stöd för Urklipp och fler CUI-kompatibla snabbtangenter. Drivrutins källkoden har också omarbetats och innehåller mer robust parameterverifiering i GUI-gränssnittsfunktionerna.

Ladda ned Filemon v4.21 på http://www.sysinternals.com/filemon.htm och Regmon v4.21 på http://www.sysinternals.com/regmon.htm.

DISKMON V1.1

Diskmon är ett verktyg som övervakar och visar logisk och fysisk diskaktivitet. Version 1.1 uppdaterar Diskmon så att den fungerar med Windows 2000 och introducerar nya förbättringar av användbarhet. Dessutom tolkar Diskmon nu ett stort antal I/O-kontrollkoder för diskar och masslagring och översätter sina hexadecimala koder till textrepresentationer i diskmonutdatafönstret.

Diskmon v1.1 fungerar inte bara som en diskövervakare, utan du kan även använda den som en programvarubaserad disklampa. När du ställer in den i diskljusläge minimerar Diskmon sig själv i systemfältet som en lampa som är grön när det finns diskläsningsåtkomst och röd när det finns diskskrivningsåtkomst.

Ladda ned Diskmon v1.1 på http://www.sysinternals.com/diskmon.htm.

SYSTEM INTERNALS AT WWW.MICROSOFT.COM

Med tanke på historiken för System Internals (tidigare NT Internals) är det verkligen mycket smickrande att Microsoft refererar till sysinternals.com som en resurs för sina kunder. Det finns ett växande antal Microsoft Knowledge Base-artiklar som pekar på System Internals-verktyg. Här är de senaste:

  • Q183060 INFO: Felsökningsguide för 80004005 och andra felmeddelanden http://support.microsoft.com/support/kb/articles/Q183/0/60.ASP
    I den här artikeln beskrivs hur du kan använda Filemon för att söka efter orsaken till dataåtkomstfel i OLE DB, ActiveX Data Objects och Remote Data Service.

  • Q196453 – Felsöka NTVDM- och WOW-startfel http://support.microsoft.com/support/kb/articles/Q196/4/53.ASP
    Den här artikeln pekar också på Filemon som ett verktyg för att avgöra vilka filer som saknas som orsakar startfel för NTVDM (Win16/DOS-kompatibilitetsmiljön i NT).

  • Q216368 – PRB: Åtkomstfel under programkonfigurationen när filen används http://support.microsoft.com/support/kb/articles/Q216/3/68.ASP
    HandleEx och DLLView är rekommenderade verktyg för att fastställa orsaken till fel vid körning av installationsprogram som genereras av guiden och distributionsguiden för Visual Basic.

  • Q232830 – HOWTO: Fastställa filhandtagsägarskap http://support.microsoft.com/support/kb/articles/Q232/8/30.ASP
    HandleEx hämtar återigen hänvisningen i den här artikeln som diskuterar hur du tar reda på vilken process som har en fil eller katalog öppen.

OKTOBER "NT INTERNALS"

Min "NT Internals"-kolumn i oktobernumret av Windows NT Magazine är "Inside Win2K Reliability Enhancements, Part 3". Den tredje i en serie i tre delar beskriver två kraftfulla Win2K-funktioner som hjälper utvecklare och administratörer att hitta buggiga drivrutiner: skrivskyddat kernelminne och drivrutinsverifieraren.

Ryska läsare kan nu läsa mina artiklar på sitt modersmål. Gå över till den ryska utgåvan av Windows NT Magazine på http://www.osp.ru/win2000/ och kolla in den första översatta kolumnen NT Internals, Inside the Boot Process (http://www.osp.ru/win2000/1999/10/59.htm). Tack till Ivan Rouzanov för att jag fick veta det här.

Från och med början av augusti är onlineversioner av Windows NT Magazine-artiklar endast tillgängliga för prenumeranter och artiklar publiceras online med varje nytt problem. Om du inte har prenumererat går du igenom prenumerationslänken på http://www.sysinternals.com/publ.htm för att få rabatten för System Internals-prenumerationen.

INTE SÅ NYA SAKER

WinObj är ett kraftfullt verktyg för att utforska Windows NT/2K-objektnamnområdet. Objektnamnområdet är ett av tre namnområden i NT/2K: objektnamnområdet, registernamnområdet och filsystemets namnområde. Du kommer till namnrymderna Register och filsystem via objekt i objektnamnområdet. När ett Win32-program till exempel öppnar registernyckeln HKEY_LOCAL_MACHINE\Software\Microsoft omvandlar ADVAPI32.DLL-biblioteket namnet till \Registry\Machine\Software\Microsoft innan kerneltjänsten NtCreateKeyanropas. Om du tittar på roten för objektnamnområdet i WinObj visas ett objekt av typen "nyckel" med namnet Registry. Registernamnet matchar den första komponenten i nyckelnamnet och därför skickar NT/2K Object Manager resten av namnet, \Machine\Software\Microsoft, till det undersystem som definierar nyckelobjektet. Configuration Manager-kernelundersystemet underhåller register- och nyckelobjekten, så att resten av namnet parsas för att hitta önskad nyckel.

Du kan utforska objektnamnområdet och visa eller ange objektsäkerhetsegenskaper med WinObj. Ladda ned Winobj på http://www.sysinternals.com/winobj.htm. Jag diskuterar Object Manager-namnområdet och WinObj i kolumnen NT Internals i oktober 1997, "Inside the Object Manager". Följ en länk till on-line-versionen av kolumnen på http://www.sysinternals.com/publ.htm.

INTERNALS NEWS

WIN2K RC2 DDK SLÄPPT

Du kan ladda ned Win2K RC2-versionen av Microsofts Device Driver Development Kit (DDK) nu på http://www.microsoft.com/ddk/ddkRC2.htm. Du kan ladda ned paketet kostnadsfritt eller bläddra i dokumentationen online.

NYA WIN2K RC2 KERNEL API:AR

Saker och ting ser ut att stabiliseras i den senaste Win2K-kärnan. Det finns bara fyra nya, exporterade kernel-API:er i RC3, i motsats till ett dussin som dök upp (och ytterligare ett halvdussin som försvann) från Beta 3 till RC1. Flera av de nya funktionerna är något intressanta, så jag har bestämt mig för att dokumentera dem åt dig. Den första är MmGetSystemRoutineAddress, och även om den är odokumenterad ingår prototypen i rubrikfilen ntddk.h i RC2 DDK:

NTKERNELAPI
PVOID
MmGetSystemRoutineAddress (
    IN PUNICODE_STRING SystemRoutineName
    );

Dess användning är så enkel som den ser ut. Skicka in namnet på en funktion som finns antingen i NTOSKRNL.EXE eller HAL.DLL så får du tillbaka dess startpunktsadress. Den här funktionen är faktiskt värdelös i den första versionen av Win2K, men kan bli mycket användbar på vägen, och det är en funktion som Microsoft borde ha inkluderat i den första versionen av NT (3.1). Precis som GetProcAddress i användarutrymmet för Win32-program låter den här funktionen en drivrutin dynamiskt fastställa tillgängligheten för ett API. Om Microsoft lägger till nya API:er i Win2K-servicepaket (och jag är säker på att de kommer att göra det) kan drivrutiner skrivas för att dra nytta av API:erna, men även för att antingen misslyckas korrekt på äldre versioner av Win2K eller för att köras i ett läge där de inte använder API:erna. Nyckeln till att en drivrutin kan göra detta är möjligheten att söka efter förekomsten av API:erna efter inläsning. Utan den här funktionen måste en drivrutin statiskt länka till funktioner som används, och om funktionerna inte finns när drivrutinen läses in rapporterar kernelinläsaren ett fult fel till användaren och kan inte läsa in drivrutinen.

Det andra nya API:et är MmGetPhysicalMemoryPages. Återigen är dess prototyp i RC2 ntddk.h men det är inte dokumenterat. Prototypen är:

NTKERNELAPI
PPHYSICAL_MEMORY_RANGE
MmGetPhysicalMemoryRanges (
    VOID
    );

Var PHYSICAL_MEMORY_RANGE är:

typedef struct _PHYSICAL_MEMORY_RANGE {
    PHYSICAL_ADDRESS BaseAddress;
    LARGE_INTEGER NumberOfBytes;
} PHYSICAL_MEMORY_RANGE, *PPHYSICAL_MEMORY_RANGE;

Den här funktionen returnerar en matris PHYSICAL_MEMORY_RANGE med poster med slutet av matrisen markerad med en post som har 0 för både BaseAddress och NumberOfBytes. Precis som MmGetSystemRoutineAddressär det ett ganska enkelt API. Den returnerar en beskrivning av allt fysiskt minne som Win2K känner till. Win2K stöder tillägg och borttagning av minne i farten med API:erna MmAddPhysicalMemory och MmRemovePhysicalMemory . Det motiverar orsaken till att det finns ett API som gör att du kan fråga efter minnesintervall. MmAddPhysicalMemory lades till i RC1 och MmRemovePhysicalMemory RC2. Båda dessa funktioner är också prototyper i ntddk.h.

Vilka är de andra nya RC2-API:erna? PoShutdownBugCheck och RtlInvertRangeList. PoShutdownBugCheck låter dig krascha systemet och utföra en energirelaterad åtgärd som att pausa. Den används på ett par platser av RC2-kerneln. Intervall är allmänna start-end-specifikationer som är användardefinierade och stöds av ett antal kernel-API:er för att hantera, sortera och iterera över dem. Win2K Plug-and-Play-resurssmugglare använder dem för att spåra och organisera maskinvaruresurskrav. Även om api:erna för intervalllistan inte dokumenteras ingår alla deras prototyper och strukturdefinitioner i ntddk.h, så du kan förmodligen använda API:et för att hantera dina egna start-end-orienterade data.

Håll utkik efter roligare med odokumenterade API:er i efterföljande nyhetsbrev.

PROGRAMVARUUTVECKLING 99 ÖSTRA

1999 års östkustutgåva av Software Development äger rum i Washington D.C. 8-12 november. Jag presenterar tre föredrag den senaste dagen: Nyheter i Windows 2000 för utvecklare, Inuti Windows NT/2000 Blue Screen och Inuti Windows NT/2000-nätverk. Dessutom Dave Solomon, författare till Inside Windows NT 2nd Edition och en granne (han bor bara 20 minuter från mig i, av alla platser, Danbury, CT), och jag är värd för en Windows NT / 2K interna runda bord. Vi kommer att vara tillsammans för att besvara dina tuffaste frågor om Windows NT/2K internt. Säg hej och nämna nyhetsbrevet och jag ska ge dig en gratis System Internals t-shirt!

Besök webbplatsen för programvaruutveckling på http://www.sdexpo.com.

ANVÄNDA DISKEDIT

Du kanske inte vet det, men det finns ett verktyg för diskredigeraren för Windows NT i stil med den ärevördiga Norton Disk Edit för DOS. Dessutom förstår verktyget FAT och NTFS och det är gratis. Microsoft levererade tydligen DiskEdit av misstag, ett verktyg som måste vara ett internt felsökningsverktyg för deras filsystemteam, på Windows NT 4.0 Service Pack 4 CD. DiskEdit har ett märkligt gränssnitt som skulle ta en liten handbok att dokumentera, men jag ska komma igång med en enkel genomgång. Jag ska fokusera på att använda DiskEdit för att riva upp NTFS-filsystemformatet, eftersom DiskEdit är det enda offentligt tillgängliga verktyget jag känner till som förstår NTFS.

Först måste du hämta DiskEdit från Service Pack 4 (SP4) CD-ROM. Kopiera den helt enkelt från katalogen \i386 till hårddisken. Om du vill använda DiskEdit under Win2K måste du skapa en privat katalog för den och kopiera följande DLL:er från en SP4 winnt\system32-katalog (eller SP4 CD) till samma katalog som DiskEdit: IFSUTIL.DLL, ULIB.DLL, UNTFS.DLL och UFAT.DLL. Nu kan du starta DiskEdit.

För den här genomgången skapar du en katalog med namnet TEMP i roten på en NTFS-enhet och skapar en fil med namnet OUT.TXT i katalogen genom att skriva följande kommando i ett kommandotolkfönster med TEMP som aktuell katalog: echo hello > out.txt. Välj enheten med den nya OUT.TXT filen i DiskEdit genom att välja Filen|Öppna menyalternativet och ange enhetens bokstav i fältet Volymnamn i den resulterande dialogrutan. Se till att du inkluderar kolonet t.ex. "d:". I stort sett alla DiskEdits funktioner kräver att du har öppnat en enhet.

Vi ska hitta filen OUT.TXT genom att börja i rotkatalogen på NTFS-enheten. Välj menyposten Läs|NTFS-filpost för att öppna en dialogruta där du kan visa alla MFT-postposter bara genom att ange dess nummer. De första 16 MFT-postposterna för varje NTFS-enhet är reserverade och motsvarar fördefinierade NTFS-metadatafiler. Här är nummertilldelningarna (observera att DiskEdit tolkar alla indata som hexadecimala):

        0: $MFT - MFT
        1: $MFTMirr - MFT Mirror (a copy of the first 4 entries of the MFT)
        2: $LogFile - NTFS LogFile
        3: $Volume - volume information file
        4: $AttrDef - the attribute definition file
        5: . - the root directory
        6: $Bitmap - the volume allocation bitmap file
        7: $Boot - the boot sector
        8: $BadClus - the bad cluster database file
        9: $Secure - new to SP4, the security attribute database
        A: $UpCase - the lower-to-upper case mapping file
        B: $Extend - new to Win2K, the directory that contains
                             the reparse, object ID, and quota metadata files
        C-F: Unused as of NTFS v5.0 (Win2K)

Gå vidare och titta på några av dessa MFT-poster. Du börjar märka ett vanligt tema: alla består av attribut som $INDEX_ROOT, $FILE_NAMEoch $DATA. Det finns i attribut där data som är specifika för en fil lagras. När attributdata är små lagrar NTFS data i filens MFT-post som "residenta" data, och när data är stora lagrar NTFS data utanför posten i kluster på disk som "icke-residenta" data.

Ange nu "5" som filnummer så visar du rotkatalogens fil. Vi ska titta på de filer och kataloger som finns i rotkatalogen genom att visa katalogens $INDEX_ALLOCATION attribut, ett attribut som är specifikt för kataloger som registrerar en katalogs innehåll. Om du vill göra det väljer du Läs|Menypost för NTFS-attribut, som öppnar en annan dialogruta. DiskEdit är känsligt för skiftläge så ange följande exakt som jag har listat det:

        Base Frs Number: 5

Base Frs (base file record segment) är ett annat namn för MFT-nummer. Du anger till 5 för att ange att du vill läsa ett attribut från rotkatalogen.

        Attribute Type: $INDEX_ALLOCATION

Detta anger för DiskEdit att du vill läsa katalogens innehållsdata. Jag rekommenderar att du använder den nedrullningsbara menyn för att välja det attribut du vill ha eftersom DiskEdit är mycket kräsen om hur attributtypen anges.

        Attribute Name: $I30

Om du visar $INDEX_ALLOCATION attributet för rotkatalogen ser du att "$I30" visas som dess namn på raden "Type code, name", så det är det du anger som attributnamn.

Tryck på OK så visas en hexadecimal dump av attributets innehåll. Vi vill se något mer begripligt så välj Visa|Menypost för NTFS-indexbuffert. Du kommer att få en lista över katalogens innehåll. Bläddra igenom listan tills du ser posten med namnet "TEMP". Om du inte ser den kan posten finnas i rotkatalogens $INDEX_ROOT attribut, en attributtyp som också är associerad med kataloger och som alltid har sitt värde lagrat i MFT-posten. Indexera rotposter och allokeringsposter bildar tillsammans en B+-trädstruktur som lagrar alla en katalogs poster. Om du måste visa $INDEX_ROOT attributet följer du bara samma steg för att visa attributet som du gjorde för att visa $INDEX_ALLOCATION attributet. När du bläddrar igenom en indexbuffert kan du stöta på dubbla rader med asterisker: dessa anger slutet på en indexbuffert och början av nästa.

När du har hittat temp-katalogens post antecknar du dess filreferens (FRS). Välj Läs|NTFS-filpost och ange TEMP:s FRS. Nu tittar du på MFT-posten för TEMP-katalogen. Vi vill hitta OUT.TXT-filen, så vi måste titta igenom TEMP:s innehåll för att hitta den. $INDEX_ALLOCATION Visa attributet (eller $INDEX_ROOT) för TEMP-katalogen, växla till att visa data som en NTFS-indexbuffert och leta upp filen OUT.TXT. Kom ihåg att ange TEMP:s FRS som bas-FRS-nummer i dialogrutan för attributval. Om du precis har skapat TEMP har den bara en $INDEX_ROOT (om du skriver något fel får du nöjet att se på DiskEdits tomma feldialogrutor).

När du har hittat OUT.TXT och fastställt dess FRS använda Read|NTFS-filpost för att titta på dess MFT-post. Rulla nedåt tills du hittar attributet $DATA. Nu tittar du på platsen för OUT. TXT:s data. Eftersom vi har skapat en liten fil lagras data i MFT-posten. Om du försöker visa OUT. TXT-attributet $DATA med DiskEdit ser du ingenting eftersom DiskEdit inte visar data korrekt (en av DiskEdits många buggar). Kopiera därför en largish -textfil (> 2 KB) till \TEMP\ OUT.TXT. Nu kan du visa OUT.TXT data på något av två sätt: du kan undersöka början av data (eller allt om de lagras sammanhängande på disken) med hjälp av Read|NTFS-kluster och ange det första "lcn"-värdet som du ser i OUT. TXT-attributet "Omfattningslista $DATA " eller så kan du använda Read|NTFS-attribut och ange "$DATA" som attributtyp och ingenting (som i skriv ingenting i det fältet) som attributnamn.

I omfattningslistor beskrivs platsen för ett attributs icke-inhemska data. Varje sammanhängande datablock med upp till 16 kluster i längd beskrivs av en post i en omfattningslista. En post i en omfattningslista anger ett virtuellt klusternummer (vcn), logiskt klusternummer (lcn) och körningslängd. En Vcn är klustret i filen där data som beskrivs av posten startar. En Lcn anger det logiska kluster där data lagras på disken, och runlength är antalet byte med attributdata på den platsen (kom ihåg att DiskEdit visar hexadecimala värden).

Jag gick igenom den långa vägen för att hitta OUT.TXT filens MFT-post genom att visa dig hur du skannar kataloginnehåll. Det finns dock en genväg: välj Crack|NTFS-sökväg och ange TEMP\OUT.TXT. Du kommer att presenteras med OUT. TXT:s FRS och du kan använda Read|NTFS-filpost för att gå direkt till den.

Det för mig till slutet av min DiskEdit primer. Jag uppmuntrar dig att leka med detta fiffiga verktyg genom att bläddra i dina FAT- eller NTFS-enheter. Det är högst osannolikt att du någonsin kommer att få tillfälle att använda DiskEdit för att ändra data för att få disken ur en sylt, men om du är nyfiken på NTFS på diskformatet (FAT-formatet är väldokumenterat) är detta det perfekta verktyget för att undersöka.

VAD KOMMER UPP

WIN2K API EXPLOSION

Även om det bara finns 4 nya exporterade API:er i kernelläge som gjorde debut i RC2 har antalet totala API:er som Microsoft har introducerat sedan NT 4.0, både i kerneln och i centrala Win32-DLL:er, exploderat. Nästa månad ska jag berätta exakt hur många nya API:er som finns och var de har dykt upp, och tyvärr samtidigt ge människor som tror att Win2K är ett uppblåst monster några bra ammunition för deras alt.advocacy.linux Usenet rants.

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

Publicerad onsdag 20 oktober 1999 19:10 av ottoh

[Nyhetsbrev arkiv ^][< Volym 1, nummer 4][Volym 2, nummer 1 >]