12 oktober 1999 – I det här problemet:

  1. VAD ÄR NYTT PÅ SYSTEM INTERNALS

    • NTFS för Windows 98/NTFSDOS Professional
    • DebugView v3.21
    • Filemon och Regmon v4.21
    • Diskmon v1.1
    • System som är interna på www.microsoft.com
    • Oktober "NT Internals"
    • Inte så nya saker
  2. INTERNT NYHETER

    • Win2K RC2 DDK har släppts
    • Nya Win2K RC Kernel-API:er
    • Programvaruutveckling '99, östra
    • Använda DiskEdit
  3. VAD ÄR PÅ GÅNG

    • Win2K API Explosion

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.

Med Remote Recover för Software kan du komma åt enheter på en dator som inte kan startas via TCP/IP var du än befinner dig i företaget. Spara tid och support dollar genom att fjärrkonfigurera drivrutins-, filsystem- och konfigurationsproblem som håller NT- eller Win9x-system off-line. Du kan även utföra fjärr-chkdsk- eller partitioneringsåtgärder med fjärråterställning, vilket gör det till ett flexibelt haveriberedskapsverktyg. Ladda ned en kostnadsfri skrivskyddad utvärderingsversion http://www.sysinternals.com/rrecover.htm på och köp läs-/skrivversionen på http://www.winternals.com.

Hej!

Välkommen till nyhetsbrevet Systems 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 hos oss och sedan pushas tillbaka. De senaste nyheterna är att den blir tillgänglig i februari. Och den enda informationen om Win2K-transportdatum finns i satser, eftersom Microsoft inte ens talar om för OEM-tillverkare eller partner när det kommer att levereras. De är: "det levereras när det är klart" (jag tvingar inte daterat att säga om att sälja vin på dig här).

Det som är retrativt med Microsoft är att den press de skapar om sina produkter alltid gör att det verkar som om de levereras även när produkterna är produktprogram. Det senaste exemplet är Ent, efterföljaren till Windows 98. Microsoft gjorde för inte så länge sedan en stor push-tryckning för den som om det vore en färdig produkt, redo att konvertera alla hushållsapparater till intelligenta enheter. Ironin är att artiklar en kort tid senare visar att Microsoft inte ens har definierat produkten fullständigt ännu, och att det förmodligen kommer att vara 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 som skriver om det. Men det stoppar inte mig från att spekulera om hur mycket av see-sawing som är en noggrant orkestrerad plan och hur mycket är resultatet av en total brist på huvudnamn för programvaruutveckling. Om du köper in dig i den tidigare vinkeln, precis som theorists gör, så hjälper Microsoft på ett utmärkt sätt konkurrenterna genom att lockande kunder med den fantastiska produkten som, om de väntar lite längre, gör att deras väntan blir värt och gör att de inte behöver använda en produkt som inte kommer från Microsoft. Den senare vinkeln säger att Microsoft aldrig kommer att lära sig programutvecklingsprocessen och kontinuerligt underskatta tekniska insatser och överskatta betakodens kvalitet.

Jag sitter vid gränsen för 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 varit nästan klart i två år nu. Det finns säkert kunder som skulle ha gått över 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 svarta ögon upprepade gånger i press från att ha utlovat produktleverans och sedan fördröjt. Jag tror att Microsofts ledning inte förstår hur svårt det är att återskapa, isolera och åtgärda de senaste 5 % av buggarna.

På tal om Microsofts utvecklingsmetoder är deras namngivningsschema i förväg en av de mest förvirrande jag har sett. Deras betaversion är egentligen Alfa och deras lanseringskandidater är faktiskt betaversion. Och även att använda dessa definitioner är en stretch: Microsoft har inga problem med att ta bort funktioner från sin programvara till att gå från en lanseringskandidat 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 här övningen påskyndar verkligen inte en lanseringscykel.

Kommer Win2K att levereras i februari? Jag tror att vi ser lampan i slutet av tunneln. Trots allt finns det bara ett fåtal nya API:er i RC2...

Som en uppföljning till det senaste nyhetsbrevet, där jag talade om förkortningsförväxling på Microsoft, hittade läsaren På så vis Ett annat exempel. I avsnittet " Utöka till stordatordatorn Transaction-Processing World" refererar artikeln till http://msdn.microsoft.com/library/backgrnd/html/msdn_windnapps.htm CISC – Complex Instruction Set Computing. Det är uppenbart för alla som är bekanta med stordatorprogram att den avsedda förkortningen är CICS – Customer Information Control System. En sekvens med omvänd bokstav och du är i ett helt annat teknikområde.

Som vanligt skickar du nyhetsbrevet vidare till vänner som du tror kan vara intressanta.

Tack!

-Mark

VAD ÄR NYTT PÅ SYSTEM INTERNALS

NTFS FÖR WINDOWS 98/NTFSDOS PROFESSIONAL

Vi har slutligen gjort det. Sedan Bryce och jag släppte NTFSDOS 1.0 på våren 1996 har vi varit på jakt efter den väg som finns för Windows-filsystemkompatibilitet: läs-/skrivåtkomst för NTFS från Windows 9x och DOS. För länge sedan kom vi fram till att en omvänd utveckling av NTFS-formatet och att skriva en drivrutin för det här komplexa journalfilsystemet skulle vara ett svårt och riskabelt alternativ. Även om en exakt avgör varje nyanser av formatet kräver en uppdatering av formatet, som t.ex. Win2K:s NTFS v5.0, ett helt nytt projekt för omvänd teknik och utveckling. Att verifiera korrektheten hos en filsystemdrivrutin för ett format som är så invecklat som NTFS är dessutom en svår lösning.

Så vi var oskadd.

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 NTFS-läs-/skrivåtkomst från DOS. Varken NTFS för Windows 98 eller NTFSDOS Professional har några kunskaper om NTFS-filformatet. 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öomserare för NTFS-filsystemdrivrutinen. NTFS för Windows 98 tillhandahåller ett gränssnitt för API:et för Windows 9x-filsystemet ovanför NTFS och disktjänsterna Windows 9x under NTFS. Gränssnittet NTFS för Windows 98 visar för NTFS ser ut som NTFS ursprungliga Windows NT/2K-miljö, komplett med IRPs, I/O Manager, Cache Manager, DISKenheter i NT-format 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 den gränssnitt NTFS till DOS-tjänster ovan och BIOS Interrupt 13 disktjänster nedan. För att hjälpa till 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 direkt kan använda av kernelns interna tjänster.

Vi hade så kul med att skapa 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 har ett NTFS chkdsk-verktyg som heter NTFSCHK. NTFSCHK fungerar på samma huvudnamn som NTFS-filsystemomslutningen, där det 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 stöd för NTFS-läsning/skrivning Windows 95/98 och för DOS.

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

DEBUGVIEW V3.21

DebugView är en övervakare för 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 även 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 registerspionverktyg för Windows 95, 98, NT 4.0 och Win2K. De fortsätter att utvecklas med nya funktioner för användbarhet och med version 4.21 (Filemon och Regmon har synkroniserade versionsnummer) introducerar de mer avancerad filtrering med senaste filterlistor, möjligheten att definiera ett markeringsfilter (med anpassade färger även), anpassningsbart teckensnitt, stöd för Urklipp och mer CUI-kompatibla snabbtangenter. Drivrutinens källkod har också omarbetats och innehåller mer robust parametervalidering 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 användbarhetsförbättringar. Dessutom tolkar Diskmon nu ett stort antal I/O-kontrollkoder för disk och masslagring, och översätter sina hexadecimala koder till textrepresentationer i utdatafönstret för Diskmon.

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

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

SYSTEMS INTERNALS AT WWW.MICROSOFT.COM

Med tanke på historiken för System internals (tidigare NT Internals) är det mycket plattare 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, interna verktyg. Här är de senaste:

  • Q183060 INFO: Felsökningsguide för 80004005 & 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 kontrollera orsaken till dataåtkomstfel i OLE DB, ActiveX dataobjekt och Remote Data Service.

  • Q196453 – Felsökning av 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 vad filer som saknas orsakar startfel för NTVDM (Win16/DOS-kompatibilitetsmiljön i NT).

  • Q216368 – PRB: Åtkomstöverträdelse under programinstallationen 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 tillfel under körning av installationsprogram som genereras av Visual Basic Installationsguiden och distributionsguiden.

  • Q232830 – HOWTO: Fastställa ägarskap för filhanterare http://support.microsoft.com/support/kb/articles/Q232/8/30.ASP
    HandleEx hämtar återigen hänvisningen i den här artikeln som beskriver 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 här 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 i sitt ursprungliga språk. Gå till den ryska utgåvan av Windows NT Magazine på och kolla in den första översatta http://www.osp.ru/win2000/ NT Internals-kolumnen Inside the Boot Process (http://www.osp.ru/win2000/1999/10/59.htm). Tack till Rouzanov för att du berätta för mig om detta.

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 ärende. Om du inte har prenumererat går du via prenumerationslänken på för http://www.sysinternals.com/publ.htm att få prenumerationsrabatten System internals.

INTE SÅ NYA SAKER

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

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

INTERNT NYHETER

WIN2K RC2 DDK UTGIVEN

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 läsa dokumentationen online.

NYA WIN2K RC2 KERNEL-API:ER

Det ser ut att vara stabilt i den senaste Win2K-kerneln. Det finns bara fyra nya, exporterade kernel-API:er i RC3, till skillnad från ett dussintal som visades (och ytterligare ett halvdussin som försvann) som går från Beta 3 till RC1. Flera av de nya funktionerna är lite intressanta, så jag har bestämt mig för att dokumentera dem åt dig. Den första är , och även om prototypen är odokumenterad ingår den i MmGetSystemRoutineAddress huvudfilen ntddk.h i RC2 DDK:

NTKERNELAPI
PVOID
MmGetSystemRoutineAddress (
    IN PUNICODE_STRING SystemRoutineName
    );

Användningen ä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 oanvändbar 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 GetProcAddress som i användarutrymme för Win32-program kan en drivrutin dynamiskt fastställa tillgängligheten för ett API med den här funktionen. Om Microsoft lägger till nya API:er i Win2K Service Pack(och jag är säker på att de kommer) kan drivrutiner skrivas för att dra nytta av API:erna, men också för att antingen misslyckas på ett smidigt sätt i ä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 kontrollera förekomsten av API:erna efter inläsningen. Utan den här funktionen måste en drivrutin statiskt länka till funktioner som den använder, 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 finns prototypen i RC2 ntddk.h, men den dokumenteras inte. Prototypen är:

NTKERNELAPI
PPHYSICAL_MEMORY_RANGE
MmGetPhysicalMemoryRanges (
    VOID
    );

Var PHYSICAL_MEMORY_RANGE finns:

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

Den här funktionen returnerar en matris med poster med slutet av matrisen markerad med PHYSICAL_MEMORY_RANGE en post som har 0 för både och BaseAddressNumberOfBytes . Precis MmGetSystemRoutineAddress som ä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 MmAddPhysicalMemoryMmRemovePhysicalMemory och . Det motiverar orsaken till att det finns ett API som gör att du kan köra frågor mot 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 specifikationer för start och slut som är användardefinierade och som stöds av ett antal kernel-API:er för att hantera, sortera och iterera över dem. Win2K Plug-and-Play-resursdebiterarna använder dem för att spåra och organisera maskinvaruresurskrav. Även om intervalllistans API:er inte är dokumenterade inkluderas alla deras prototyper och strukturdefinitioner i ntddk.h, så du kan förmodligen använda API:et för att hantera dina egna start- och slutorienterade data.

Håll ögonen öppna för roligare med odokumenterade API:er i efterföljande nyhetsbrev.

PROGRAMVARUUTVECKLING 99, ÖSTRA

1999 års east Coast-utgåva av Software Development äger rum i Washington D.C. från 8 till 12 november. Jag presenterar tre föredrag den sista dagen: What's New in Windows 2000 For Developers, Inside the Windows NT/2000 Blue Screen och Inside Windows NT/2000 Networking. Dessutom är Dave Edition, författare av Inside Windows NT 2nd Edition och en granne (han bor bara 20 minuter från mig på, av alla platser, Danhost, CT) och jag är värd för en Windows NT/2K internt round-table. Vi kommer att vara tillsammans för att besvara dina svåraste frågor om Windows NT/2K internt. Säg hej och nämn nyhetsbrevet så ger jag dig en kostnadsfri t-shirt för Systems Internals!

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

ANVÄNDA DISKEDIT

Du kanske inte känner till det, men det finns ett verktyg för diskredigeraren för Windows NT i stil med den ärevördiga Diskredigering för DOS. Dessutom förstår verktyget FAT och NTFS och det är kostnadsfritt. Microsoft levererade uppenbart DiskEdit av misstag, ett verktyg som måste vara ett internt felsökningsverktyg för sina filsystemteam, på Windows NT 4.0 Service Pack 4 CD. DiskEdit har ett användargränssnitt som skulle ta en liten manuell att dokumentera, men jag ska komma igång med en enkel genomgång. Jag fokuserar på att använda DiskEdit för att ta bort NTFS-filformatet, eftersom DiskEdit är det enda offentligt tillgängliga verktyg 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 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.

I 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 kommandotolkens fönster med TEMP som aktuell katalog: echo hello > out.txt . Välj enheten med den nya OUT.TXT 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 DiskEdit-funktioner kräver att du har öppnat en enhet.

Vi ska leta upp OUT.TXT genom att starta i NTFS-enhetens rotkatalog. Välj menyposten Läs| NTFS-filpost för att öppna en dialogruta där du kan visa valfri MFT-post 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 lägga märke till ett gemensamt tema: de består alla av attribut som $INDEX_ROOT$FILE_NAME , och $DATA . Det är 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 "interna" data, och när data är stora lagrar NTFS data utanför posten i kluster på disk som "icke-interna" 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 attribut, ett attribut som är specifikt för kataloger som registrerar en $INDEX_ALLOCATION katalogs innehåll. Det gör du genom att välja Alternativet Läs| Menyposten NTFS-attribut, vilket öppnar en annan dialogruta. DiskEdit är känsligt för fall, så ange följande precis 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 nedströmsmenyn för att välja det attribut som du vill använda eftersom DiskEdit är mycket användbart när det gäller hur attributtypen anges.

        Attribute Name: $I30

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

Tryck på OK så ser du en hexadecimal dump av attributets innehåll. Vi vill se något mer begripligt så välj Vyn| Menypost för NTFS-indexbuffert. Du kommer att se en lista över katalogens innehåll. Bläddra igenom listan tills du ser posten med namnet " TEMP ". Om du inte ser det kan posten finnas i rotkatalogens attribut, en attributtyp som också är associerad med kataloger och som alltid har sitt värde lagrat i $INDEX_ROOT MFT-posten. Indexrotposter och allokeringsposter bildar tillsammans en B+-trädstruktur som lagrar alla poster i en katalog. Om du behöver 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 få dubbla rader med asterisker: dessa anger slutet på en indexbuffert och början av nästa.

När du har hittat TEMP-katalogens post anteckningen av 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-innehållet för att hitta den. Visa attributet (eller ) för TEMP-katalogen, växla till att visa data som en $INDEX_ALLOCATION$INDEX_ROOT NTFS-indexbuffert och leta upp OUT.TXT fil. 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 (om du skriver fel får du inte se på $INDEX_ROOT DiskEdit tomma feldialogrutor).

När du har hittat OUT.TXT och fastställt att FRS använder Read| NTFS-filpost för att titta på dess MFT-post. Rulla nedåt tills du hittar $DATA attribut. Nu tittar du på platsen för OUT.TXT data. Eftersom vi har gjort en liten fil lagras data i MFT-posten. Om du försöker visa OUT.TXT attribut med DiskEdit ser du ingenting, eftersom DiskEdit inte korrekt visar lokala data (en av $DATA DiskEdit:s många buggar). Kopiera därför en largish ( > 2KB)-textfil 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 alla data om de lagras kontinuerligt på disk) med hjälp av Läsa| NTFS-kluster och ange det första "lcn"-värdet som du ser OUT.TXT i attributet "Extent List"; eller så kan du $DATA använda Läsa| NTFS-attribut och ange " " som attributtyp och ingenting (som i skriver inte något i det $DATA fältet) som attributnamn.

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

Jag gick igenom det långa sättet att hitta OUT.TXT MFT-posten genom att visa hur du genomsöker kataloginnehåll. Det finns dock en genväg: välj Crack| NTFS-sökväg och ange TEMP\OUT.TXT. Du kommer att se OUT.TXT frs och du kan använda Läsa| NTFS-filpost för att gå direkt till den.

Det leder mig till slutet av min DiskEdit-introduktion. Jag uppmuntrar dig att leka med det här fiffiga verktyget genom att bläddra bland dina FAT- eller NTFS-enheter. Det är mycket osannolikt att du någonsin kommer att behöva använda DiskEdit för att ändra data för att få disken ur ett jam, men om du är nyfiken på NTFS on-disk-format (FAT-formatet är väldokumenterat) är det här det perfekta verktyget för undersökning.

DET HÄR ÄR VAD SOM HÄNDER

WIN2K API EXPLOSION

Även om det bara finns 4 nya exporterade API:er i kernelläge som gjorde sina fel i RC2, har det totala antalet API:er som Microsoft har introducerat sedan NT 4.0, både i kerneln och i Win32-kärn-DLL:er, begränsat. Nästa månad ska jag berätta exakt hur många nya API:er det finns och var de har visats, och tyvärr samtidigt ge personer som tror att Win2K är ett uppblopt monstr några bra saker för deras alt.advocacy.linux Usenet-rants.


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

Publicerad onsdag 20 oktober 1999 19:10 av pm

[Newsletters Archive ^][ Volume 1, Number 4][Volume 2, Number 1 ]

[Newsletters Archive ^][ Volume 1, Number 4][Volume 2, Number 1 ]

Systems Internals Newsletter, volym 1, nummer 5

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