[Newsletter-Archiv ^] [< Band 1, Nummer 4] [Band 2, Nummer 1 >]
Der Systems Internals Newsletter Band 1, Nummer 5
http://www.sysinternals.com
Copyright 1999 Mark Russinovich
12. Oktober 1999 – In dieser Ausgabe:
NEUERUNGEN BEI SYSTEM INTERNALS
- NTFS für Windows 98/NTFSDOS Professional
- DebugView v3.21
- Filemon und Regmon v4.21
- Diskmon v1.1
- Systems Internals auf www.microsoft.com
- Oktober „NT Internals“
- Nicht ganz so neue Sachen
INTERNALS-NEUIGKEITEN
- Win2K RC2 DDK veröffentlicht
- Neue Win2K RC Kernel-APIs
- Software Development '99 East
- Verwenden von DiskEdit
BALD VERFÜGBAR
- Win2K API-Explosion
SPONSOR: WINTERNALS SOFTWARE
Der Systems Internals Newsletter wird von Winternals Software gesponsert (im Web unter http://www.winternals.com.). Winternals Software ist der führende Entwickler und Anbieter von erweiterten Systemtools für Windows NT/2K. Zu den Winternals Software-Produkten gehören FAT32 für Windows NT 4.0, ERD Commander (Startdatenträgerfunktion für Windows NT) und NTRecover.
Die Remotewiederherstellung von Winternals ermöglicht Ihnen den Zugriff auf die Laufwerke eines nicht startbaren Computers über TCP/IP von überall in Ihrem Unternehmen aus. Sparen Sie Zeit und Geld beim Support, indem Sie remote Treiber-, Dateisystem- und Konfigurationsprobleme beheben, die NT- oder Win9x-Systeme offline halten. Sie können sogar chkdsk-oder Partitionierungsvorgänge remote mittels Remotewiederherstellung durchführen, was es zu einem vielseitigen Notfallwiederherstellungstool macht. Eine kostenlose, schreibgeschützte Testversion können Sie unter http://www.sysinternals.com/rrecover.htm herunterladen und unter http://www.winternals.com. die lese-/schreibfähige Version kaufen.
Guten Tag,
Willkommen beim Systems Internals Newsletter. Der Newsletter hat aktuell 10.000 Abonnenten.
Die Veröffentlichung von Windows 2000 (Win2K) scheint nach einem bestimmten Muster abzulaufen: Erst steht sie kurz bevor, und dann wird sie verschoben. Jüngste Gerüchte besagen, dass es im Februar erhältlich sein soll. Und die einzigen Informationen über das Win2K-Auslieferungsdatum sind Gerüchte, da Microsoft nicht einmal den OEMs oder Partnern mitteilt, wann es ausgeliefert wird. Nun, Sie sagen: „Es wird ausgeliefert, wenn es fertig ist.“ (ich erspare Ihnen hier das veraltete Sprichwort zum Verkaufen von Wein).
Das Irritierende an Microsoft ist, dass die Presse über ihre Produkte immer den Anschein erweckt, als stünden sie kurz vor der Auslieferung, selbst wenn die Produkte nur Vaporware sind. Das jüngste Beispiel ist Millennium, der Nachfolger von Windows 98. Microsoft hat vor nicht allzu langer Zeit in der Presse so getan, als sei es ein fertiges Produkt, das alle Haushaltsgeräte in intelligente Geräte verwandeln kann. Die Ironie ist, dass kurze Zeit später in Artikeln enthüllt wurde, dass Microsoft das Produkt noch nicht einmal vollständig definiert hat und es wahrscheinlich noch ein Jahr oder länger dauern wird, bis es in den Regalen stehen wird.
Dieses Muster ist nicht neu, und ich bin nicht der erste, der darüber schreibt. Das hält mich aber nicht davon ab, darüber zu spekulieren, inwieweit dieses Hin und Her ein sorgfältig ausgearbeiteter Plan ist und inwieweit es das Ergebnis eines völligen Mangels an Software-Engineering-Prinzipien ist. Wenn man – wie z. B. Verschwörungstheoretiker – der ersten Sichtweise Glauben schenkt, erstickt Microsoft auf brillante Weise den Wettbewerb im Keim, indem es die Kunden mit einem unglaublichen Produkt lockt, das, wenn sie nur ein wenig länger warten, ihr Warten belohnen wird und jede Notwendigkeit, sich einem Nicht-Microsoft-Produkt zuzuwenden, überflüssig macht. Letzteres besagt, dass Microsoft den Softwareentwicklungsprozess nie erlernen wird und ständig den technischen Aufwand unterschätzt und die Qualität des Betacodes überschätzt.
Ich bin unschlüssig, welcher Theorie ich zustimmen soll. Tatsächlich glaube ich, dass das Muster ein wenig auf beides zurückzuführen ist. Ich denke, dass es Microsoft geholfen hat, so zu tun, als ob Active Directory seit zwei Jahren fast fertig wäre. Sicherlich gibt es Kunden, die sich schon vor langer Zeit für Novell Directory Services entschieden hätten, wenn sie vorher gewusst hätten, wie lange sie auf Win2K warten müssen. Andererseits hat sich Microsoft in der Presse wiederholt ein blaues Auge geholt, weil es die Lieferung von Produkten versprochen und dann verzögert hat. Ich glaube, dass das Management von Microsoft einfach nicht versteht, wie schwierig es ist, die letzten 5 % der Fehler zu reproduzieren, zu isolieren und zu korrigieren.
Wo wir gerade von Microsofts Entwicklungspraktiken sprechen: ihr Benennungsschema vor der Veröffentlichung ist eins der verwirrendsten, das ich je gesehen habe. Ihre Betas sind eigentlich Alphas und ihre Release Candidates sind eigentlich Betas. Und selbst die Verwendung dieser Definitionen ist weit hergeholt: Microsoft hat kein Problem damit, von einem Release Candidate zum nächsten Funktionen aus seiner Software zu entfernen oder sogar neue Funktionen hinzuzufügen. Das haben sie bei NT 4.0 gemacht, und sie machen es bei Win2K. Diese Praxis beschleunigt den Veröffentlichungszyklus ganz sicher nicht.
Wird Win2K also im Februar ausgeliefert? Ich glaube, dass wir das Licht am Ende des Tunnels sehen. Schließlich gibt es nur eine Handvoll neuer APIs in RC2...
Im Anschluss an den letzten Newsletter, in dem ich über die Akronym-Verwirrung bei Microsoft sprach, hat Leser George Janczuk ein weiteres Beispiel gefunden. In dem Abschnitt mit der Überschrift: „Ausweitung auf die Mainframe-Transaktionsverarbeitungswelt“ bezieht sich der Artikel unter http://msdn.microsoft.com/library/backgrnd/html/msdn_windnapps.htm auf „CISC – Complex Instruction Set Computing“. Für jeden, der sich mit Mainframe-Anwendungen auskennt, ist es offensichtlich, dass das beabsichtigte Akronym „CICS – Customer Information Control System“ lautet. Eine umgekehrte Buchstabenfolge reicht, und Sie befinden sich in einem völlig anderen Technologiebereich.
Wie immer bitten wir Sie, den Newsletter an Freunde und Bekannte weiterzuleiten, von denen Sie denken, dass sie ihn interessant finden könnten.
Vielen Dank!
-Mark
NEUERUNGEN BEI SYSTEM INTERNALS
NTFS FÜR WINDOWS 98/NTFSDOS PROFESSIONAL
Wir haben es endlich geschafft. Seit Bryce und ich NTFSDOS 1.0 im Frühjahr 1996 veröffentlicht haben, waren wir auf der Suche nach dem heiligen Gral der Windows-Dateisystemkompatibilität: Lese-/Schreibzugriff für NTFS von Windows 9x und DOS aus. Wir haben schon vor langer Zeit festgestellt, dass das Reverse Engineering des NTFS-Formats und das Schreiben eines Treibers für dieses komplexe Journaling-Dateisystem ein schwieriges und riskantes Unterfangen wäre. Selbst wenn man jede Nuance des Formats genau bestimmt, macht eine Aktualisierung des Formats wie NTFS v5.0 von Win2K einen vollständig neuen Reverse Engineering- und Entwicklungsaufwand erforderlich. Außerdem ist die Validierung der Korrektheit eines Dateisystemtreibers für ein so komplexes Format wie NTFS ein entmutigendes Unterfangen.
Also haben wir geschummelt.
NTFS für Windows 98 bietet vollen Lese-/Schreibzugriff auf NTFS-Laufwerke von Windows 95 oder Windows 98 aus, und NTFSDOS Professional bietet vollen NTFS-Lese-/Schreibzugriff von DOS aus. Weder NTFS für Windows 98 noch NTFSDOS Professional kennt das NTFS-Dateisystemformat. Vielmehr verlassen sie sich auf den NTFS-Treiber einer Windows NT- oder Windows 2000-Installation, um dieses Wissen zu implementieren. Beide Hilfsprogramme verwenden dieselbe Codebasis, die als Umgebungs-Wrapper für den NTFS-Dateisystemtreiber dient. NTFS für Windows 98 bietet eine Schnittstelle zur Windows 9x-Dateisystem-API höher als NTFS und zu den Windows 9x-Datenträgerdiensten niedriger als NTFS. Die Schnittstelle, die NTFS für Windows 98 zu NTFS darstellt, sieht aus wie die native Windows NT/2K-Umgebung von NTFS, komplett mit IRPs, dem E/A-Manager, dem Cache-Manager, NT-ähnlichen Festplattengeräten und anderen NT/2K-Subsystemen, mit denen NTFS interagiert.
NTFSDOS Professional funktioniert auf dieselbe Weise wie NTFS für Windows 98, mit dem Unterschied, dass es NTFS mit den DOS-Diensten darüber und den BIOS-Interrupt-13-Datenträgerdiensten darunter verbindet. Um die NT/2K-ähnliche Umgebung zu schaffen, verlassen wir uns auf viele Funktionen in NTOSKRNL, der NT/2K-Kernel-Datei. Beide Hilfsprogramme laden NTOSKRNL in Verbindung mit NTFS, sodass NTFS direkt viele der nativen Dienste des Kernels nutzen kann.
Es hat uns so viel Spaß gemacht, die NTFS-Umgebung zu erstellen, dass wir noch einen Schritt weitergegangen sind: Wir haben dasselbe mit dem chkdsk-Startzeit-Hilfsprogramm von NT „Autochk“ gemacht. NTFSDOS Professional und NTFS für Windows 98 werden mit einem NTFS chkdsk-Hilfsprogramm namens NTFSCHK geliefert. NTFSCHK arbeitet nach dem selben Prinzip wie der NTFS-Dateisystem-Wrapper, indem es eine NT-ähnliche Umgebung für das Autochk-Programm schafft, sodass Autochk unter Windows 95/98 und DOS läuft. Das Ergebnis dieser Trickserei ist eine vollständige NTFS-Lese-/Schreibunterstützung für Windows 95/98 und für DOS.
Eine kostenlose, schreibgeschützte Version von NTFS für Windows 98 können Sie unter http://www.sysinternals.com/ntfs98.htm herunterladen sowie eine kostenlose, schreibgeschützte Version von NTFSDOS Professional unter http://www.sysinternalscom/ntfspro.htm.. Sie können die vollständigen lese-/schreibfähigen Versionen beider Tools bei Winternals Software unter http://www.winternals.com. kaufen.
DEBUGVIEW V3.21
DebugView ist ein Debugausgabe-Monitor, der sowohl die Kernel- als auch die Win32-Debugausgabe unter Windows 95, Windows 98, NT 4.0 und Windows 2000 erfasst. Er verfügt über erweiterte Filter-, Markierungs- und Protokollierungsfunktionen und kann sogar Debugausgaben von einem System über ein Netzwerk aufzeichnen. Sein neuestes Release, 3.21, führt die Möglichkeit zur Überwachung der 16-Bit-Ausgabe von OutputDebugString unter Windows 95 und Windows 98 ein.
Sie können DebugView v3.21 unter http://www.sysinternals.com/dbgview.htm. herunterladen.
FILEMON UND REGMON V4.21
Filemon und Regmon sind Hilfsprogramme zum Ausspionieren des Dateisystems und der Registrierung für Windows 95, 98, NT 4.0 und Win2K. Sie sind ständig in der Entwicklung mit neuen Funktionen und führen mit Release 4.21 (die Versionsnummern von Filemon und Regmon sind synchronisiert) eine erweiterte Filterung mit Listen zuletzt verwendeter Filter, die Möglichkeit, einen Hervorhebungsfilter (sogar mit benutzerdefinierten Farben) zu definieren, eine anpassbare Schriftart, Unterstützung für die Zwischenablage und mehr CUI-kompatible Abkürzungstasten ein. Der Quellcode des Treibers wurde ebenfalls überarbeitet und enthält eine robustere Parametervalidierung in den Funktionen der GUI-Oberfläche.
Filemon v4.21 können Sie unter http://www.sysinternals.com/filemon.htm herunterladen und Regmon v4.21 unter http://www.sysinternals.com/regmon.htm..
DISKMON V1.1
Diskmon ist ein Tool, das die logische und physische Festplattenaktivität überwacht und anzeigt. Version 1.1 aktualisiert Diskmon für die Arbeit mit Windows 2000 und führt neue Verbesserungen in der Benutzerfreundlichkeit ein. Darüber hinaus interpretiert Diskmon jetzt eine große Anzahl von Festplatten- und Massenspeicher-E/A-Steuercodes und übersetzt deren Hexadezimalcodes in Textdarstellungen im Ausgabefenster von Diskmon.
Diskmon v1.1 funktioniert nicht nur als Festplatten-Monitor, sondern Sie können es auch als softwarebasierte Festplatten-LED verwenden. Wenn Sie es in den Festplatten-LED-Modus versetzen, minimiert sich Diskmon in den Infobereich als ein Licht (LED), das bei Lesezugriff auf die Festplatte grün leuchtet und bei Schreibzugriff auf die Festplatte rot.
Diskmon v1.1 können Sie unter http://www.sysinternals.com/diskmon.htm. herunterladen.
SYSTEMS INTERNALS AUF WWW.MICROSOFT.COM
In Anbetracht der Geschichte von Systems Internals (früher NT Internals) ist es in der Tat sehr schmeichelhaft, dass Microsoft auf „sysinternals.com“ als Ressource für seine Kunden verweist. Es gibt eine wachsende Anzahl von Microsoft Knowledge Base-Artikeln, die auf Systems Internals-Hilfsprogramme verweisen. Hier finden Sie die neuesten:
Q183060 INFO: Leitfaden zur Problembehandlung für 80004005 und andere Fehlermeldungen http://support.microsoft.com/support/kb/articles/Q183/0/60.ASP
Dieser Artikel beschreibt, wie Sie Filemon verwenden können, um die Ursache von Datenzugriffsfehlern in OLE DB, ActiveX Data Objects und Remote Data Service zu ermitteln.Q196453 – Problembehandlung bei NTVDM- und WOW-Startfehlern http://support.microsoft.com/support/kb/articles/Q196/4/53.ASP
Dieser Artikel verweist auch auf Filemon als Tool zur Ermittlung der fehlenden Dateien, die Startfehler für NTVDM (die Win16/DOS-Kompatibilitätsumgebung in NT) verursachen.Q216368 – PRB: Zugriffsverletzung während der Anwendungseinrichtung bei in Verwendung befindlicher Datei http://support.microsoft.com/support/kb/articles/Q216/3/68.ASP
HandleEx und DLLView sind empfohlene Tools, um die Ursache von Fehlern bei der Ausführung von Setupprogrammen zu ermitteln, die vom Visual Basic-Installations-Assistenten sowie vom Bereitstellungs-Assistenten generiert werden.Q232830 – GEWUSST WIE: Ermitteln des Besitzes von Dateihandles http://support.microsoft.com/support/kb/articles/Q232/8/30.ASP
Auch dieser Artikel nimmt Bezug auf HandleEx, in dem es darum geht, herauszufinden, welcher Prozess eine Datei oder ein Verzeichnis geöffnet hat.
OKTOBER „NT INTERNALS“
Meine Kolumne „NT Internals“ in der Oktober-Ausgabe des Windows NT Magazine trägt den Titel „Inside Win2K Reliability Enhancements, Part 3“ (Innenansichten der Zuverlässigkeitsverbesserungen von Win2K, Teil 3). In diesem dritten Teil einer dreiteiligen Serie werden zwei leistungsstarke Win2K-Funktionen beschrieben, die Entwicklern und Administratoren helfen, fehlerhafte Treiber aufzuspüren: schreibgeschützter Kernelspeicher und die Treiberüberprüfung.
Russische Leser können meine Artikel jetzt in ihrer Muttersprache lesen. Besuchen Sie die russische Ausgabe des Windows NT Magazine unter http://www.osp.ru/win2000/, und lesen Sie die erste übersetzte „NT Internals“-Kolumne, „Inside the Boot Process“ (Innenansichten des Startprozesses, http://www.osp.ru/win2000/1999/10/59.htm).). Vielen Dank an Ivan Rouzanov, der mich darauf aufmerksam gemacht hat.
Seit Anfang August sind die Onlineversionen der Artikel des Windows NT Magazine nur noch für Abonnenten zugänglich, und die Artikel werden mit jeder neuen Ausgabe online gestellt. Wenn Sie noch kein Abonnement haben, verwenden Sie bitte den Abonnementlink unter http://www.sysinternals.com/publ.htm, um den Rabatt für das Abonnement von Systems Internals zu erhalten.
NICHT GANZ SO NEUE SACHEN
WinObj ist ein leistungsfähiges Tool zum Erkunden des Windows NT/2K-Objektnamespace. Der Objektnamespace ist einer von drei Namespaces in NT/2K: dem Objektnamespace, dem Registrierungsnamespace und dem Dateisystem-Namespace. Der Zugriff auf den Registrierungs- und den Dateiystem-Namespace erfolgt über Objekte im Objektnamespace. Wenn zum Beispiel ein Win32-Programm den Registrierungsschlüssel HKEY_LOCAL_MACHINE\Software\Microsoft öffnet, transformiert die Bibliothek ADVAPI32.DLL den Namen in \Registry\Machine\Software\Microsoft, bevor sie den Kernel-Dienst NtCreateKey aufruft. Wenn Sie sich den Stamm des Objektnamespace in WinObj ansehen, sehen Sie ein Objekt vom Typ „key“ namens „Registry“. Der Name „Registry“ stimmt mit der ersten Komponente des Schlüsselnamens überein, sodass der NT/2K-Objekt-Manager den Rest des Namens, \Machine\Software\Microsoft, an das Subsystem weitergibt, das das Schlüsselobjekt definiert. Das Kernel-Subsystem des Configuration Manager verwaltet die Registrierungs- und Schlüsselobjekte, sodass es den Rest des Namens analysiert, um den gewünschten Schlüssel zu finden.
Sie können den Objektnamespace erkunden und Objektsicherheitseigenschaften mithilfe von WinObj anzeigen oder festlegen. Winobj können Sie unter http://www.sysinternals.com/winobj.htm. herunterladen. Ich bespreche den Objekt-Manager-Namespace und WinObj in meiner „NT Internals“-Kolumne vom Oktober 1997, „Inside the Object Manager“ (Innenansichten des Objekt-Managers). Einen Link zur Online-Version der Spalte finden Sie unter http://www.sysinternals.com/publ.htm.
INTERNALS-NEUIGKEITEN
WIN2K RC2 DDK VERÖFFENTLICHT
Sie können das Win2K RC2-Release des Microsofts Device Driver Development Kit (DDK) jetzt unter http://www.microsoft.com/ddk/ddkRC2.htm. herunterladen. Sie können das Kit kostenlos herunterladen oder die Dokumentation online einsehen.
NEUE WIN2K RC2-KERNEL-APIS
Die Dinge scheinen sich im neuesten Win2K-Kernel zu stabilisieren. Es gibt nur vier neue, exportierte Kernel-APIs in RC3, im Gegensatz zu etwa einem Dutzend, die im Zeitraum von Beta 3 bis RC1 aufgetaucht sind (und einem weiteren halben Dutzend, das verschwunden ist). Einige der neuen Funktionen sind recht interessant, weshalb ich beschlossen habe, sie für Sie zu dokumentieren. Die erste ist MmGetSystemRoutineAddress, und obwohl sie undokumentiert ist, ist ihr Prototyp in der Headerdatei „ntddk.h“ des RC2 DDK enthalten:
NTKERNELAPI
PVOID
MmGetSystemRoutineAddress (
IN PUNICODE_STRING SystemRoutineName
);
Die Anwendung ist so einfach, wie sie aussieht. Sie übergeben den Namen einer Funktion, die sich entweder in NTOSKRNL.EXE oder HAL.DLL befindet, und Sie erhalten deren Einstiegspunktadresse zurück. Diese Funktion ist im ersten Release von Win2K tatsächlich nutzlos, kann aber später sehr nützlich werden, und es handelt sich um eine Funktion, die Microsoft in die erste Version von NT (3.1) hätte aufnehmen sollen. Wie GetProcAddress im User-Space für Win32-Anwendungen ermöglicht diese Funktion einem Treiber, die Verfügbarkeit einer API dynamisch festzustellen. Wenn Microsoft den Win2K Service Packs neue APIs hinzufügt (und ich bin mir sicher, dass sie das tun werden), können Treiber so geschrieben werden, dass sie die Vorteile der APIs nutzen, aber auch so, dass sie entweder unter älteren Versionen von Win2K kontrolliert fehlschlagen oder in einem Modus ausgeführt werden, in dem sie die APIs nicht nutzen. Der Schlüssel, um einen Treiber dazu in die Lage zu versetzen, besteht in seiner Fähigkeit, nach dem Laden zu überprüfen, ob die APIs vorhanden sind. Ohne diese Funktionalität muss ein Treiber statisch mit den von ihm verwendeten Funktionen verknüpft werden, und wenn die Funktionen beim Laden des Treibers nicht vorhanden sind, meldet der Kernel-Loader dem Benutzer einen hässlichen Fehler und kann den Treiber nicht laden.
Die zweite neue API ist MmGetPhysicalMemoryPages. Auch hier befindet sich der Prototyp in der RC2-Datei „ntddk.h“, ist aber nicht dokumentiert. Der Prototyp ist:
NTKERNELAPI
PPHYSICAL_MEMORY_RANGE
MmGetPhysicalMemoryRanges (
VOID
);
Wobei PHYSICAL_MEMORY_RANGE ist:
typedef struct _PHYSICAL_MEMORY_RANGE {
PHYSICAL_ADDRESS BaseAddress;
LARGE_INTEGER NumberOfBytes;
} PHYSICAL_MEMORY_RANGE, *PPHYSICAL_MEMORY_RANGE;
Diese Funktion gibt ein Array mit PHYSICAL_MEMORY_RANGE-Einträgen zurück, wobei das Ende des Arrays durch einen Eintrag markiert ist, der sowohl für BaseAddress als auch für NumberOfBytes den Wert 0 hat. Wie MmGetSystemRoutineAddress, ist es eine ziemlich einfache API. Sie gibt Ihnen eine Beschreibung des gesamten physischen Arbeitsspeichers, den Win2K kennt, zurück. Win2K unterstützt das Hinzufügen und Entfernen von Arbeitsspeicher im laufenden Betrieb mit den APIs MmAddPhysicalMemory und MmRemovePhysicalMemory. Das ist der Grund für die Existenz einer API, mit der Sie Arbeitsspeicherbereiche abfragen können. MmAddPhysicalMemory wurde in RC1 und MmRemovePhysicalMemory in RC2 hinzugefügt. Beide Funktionen sind auch als Prototypen in „ntddk.h“ enthalten.
Worum handelt es sich bei den anderen neuen RC2-APIs? PoShutdownBugCheck und RtlInvertRangeList. Mit PoShutdownBugCheck können Sie das System zum Absturz bringen und eine energiebezogene Aktion wie „Anhalten“ durchführen. Sie wird an einigen Stellen vom RC2-Kernel verwendet. Bereiche (ranges) sind generische Start/End-Spezifikationen, die benutzerdefiniert sind und von einer Reihe von Kernel-APIs für die Verwaltung, Sortierung und Iteration über sie unterstützt werden. Die Plug & Play-Ressourcenvermittler (arbiter) von Win2K verwenden sie, um die Hardwareressourcenanforderungen nachzuverfolgen und zu organisieren. Obwohl die Bereichslisten-APIs nicht dokumentiert sind, sind alle ihre Prototypen und Strukturdefinitionen in „ntddk.h“ enthalten, sodass Sie die API vermutlich verwenden können, um Ihre eigenen Start/Ende-bezogenen Daten zu verwalten.
Bleiben Sie dran, um in den nächsten Newslettern noch mehr Spaß mit undokumentierten APIs zu haben.
SOFTWARE DEVELOPMENT 99 EAST
Die Ostküstenausgabe (East Coast) der Software Development im Jahr 1999 findet vom 8. bis 12. November in Washington D.C. statt. Ich werde am letzten Tag drei Vorträge halten: „What's New in Windows 2000 For Developers“, „Inside the Windows NT/2000 Blue Screen“, und „Inside Windows NT/2000 Networking“ („Neuerungen in Windows 2000 für Entwickler“, Innenansichten des Windows NT/2000-Bluescreens“ und „Innenansichten der Windows 2000-Netzwerkfunktionen“). Außerdem veranstalten Dave Solomon, Autor von „Inside Windows NT, 2. Ausgabe“ sowie ein Nachbar (er wohnt nur 20 Minuten von mir entfernt, ausgerechnet in Danbury, CT) und ich einen Runden Tisch zu Windows NT/2K Internals. Wir kommen zusammen, um Ihre wichtigsten Fragen zu Windows NT/2K Internals zu beantworten. Kommen Sie vorbei, erwähnen Sie den Newsletter, und Sie erhalten ein kostenloses „Systems Internals“-T-Shirt von mir!
Besuchen Sie die Website von Software Development unter http://www.sdexpo.com..
VERWENDEN VON DISKEDIT
Sie wissen es vielleicht nicht, aber es gibt ein Festplatten-Editor-Hilfsprogramm für Windows NT im Stil des ehrwürdigen Norton Disk Edit für DOS. Darüber hinaus versteht das Hilfsprogramm FAT und NTFS und ist kostenlos. Microsoft hat anscheinend versehentlich DiskEdit, ein Tool, das ein internes Debuggingtool für ihre Dateisystemteams sein muss, auf der Windows NT 4.0 Service Pack 4-CD ausgeliefert. DiskEdit besitzt eine eigentümliche Benutzeroberfläche, deren Dokumentation ein kleines Handbuch erfordern würde, aber ich werde Ihnen den Einstieg mit einem einfachen Durchgang erleichtern. Ich werde mich auf die Verwendung von DiskEdit konzentrieren, um das NTFS-Dateisystemformat zu enträtseln, da DiskEdit das einzige mir bekannte, öffentlich verfügbare Tool ist, das NTFS versteht.
Zuerst müssen Sie DiskEdit von der Service Pack 4 (SP4)-CD-ROM herunterladen. Kopieren Sie es einfach aus dem Verzeichnis „\i386“ auf Ihre Festplatte. Wenn Sie DiskEdit unter Win2K verwenden möchten, müssen Sie ein privates Verzeichnis dafür erstellen und die folgenden DLLs aus einem SP4-Verzeichnis „winnt\system32“ (oder einer SP4-CD) in dasselbe Verzeichnis wie DiskEdit kopieren: IFSUTIL.DLL, ULIB.DLL, UNTFS.DLL und UFAT.DLL. Jetzt können Sie DiskEdit starten.
Für diesen Durchgang erstellen Sie ein Verzeichnis mit dem Namen TEMP im Stammverzeichnis eines NTFS-Laufwerks und erstellen eine Datei namens OUT.TXT in diesem Verzeichnis, indem Sie den folgenden Befehl in ein Eingabeaufforderungsfenster mit TEMP als aktuellem Verzeichnis eingeben: echo hello > out.txt. Wählen Sie in DiskEdit das Laufwerk mit Ihrer neuen OUT.TXT-Datei aus, indem Sie den Menüeintrag „Datei|Öffnen“ auswählen und den Laufwerkbuchstaben in das Feld „Volumenname“ des sich öffnenden Dialogfelds eingeben. Achten Sie darauf, dass Sie den Doppelpunkt einschließen, z. B. „d:“. Praktisch alle Funktionen von DiskEdit setzen voraus, dass Sie ein Laufwerk geöffnet haben.
Wir beginnen im Stammverzeichnis des NTFS-Laufwerks, um die Datei OUT.TXT zu finden. Wählen Sie den Menüeintrag „Lesen|NTFS-Dateidatensatz“ aus, um ein Dialogfeld zu öffnen, in dem Sie jeden MFT-Datensatzeintrag einfach durch Eingabe seiner Nummer anzeigen können. Die ersten 16 MFT-Einträge jedes NTFS-Laufwerks sind reserviert und entsprechen vordefinierten NTFS-Metadatendateien. Hier sehen Sie die Nummernzuweisungen (beachten Sie, dass DiskEdit alle Eingaben als Hexadezimalwerte interpretiert):
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)
Sehen Sie sich einige dieser MFT-Einträge an. Sie werden ein gemeinsames Thema erkennen: Sie bestehen alle aus Attributen wie $INDEX_ROOT, $FILE_NAME und $DATA. Für eine Datei spezifische Daten werden in Attributen gespeichert. Wenn die Attributdaten klein sind, speichert NTFS die Daten innerhalb des MFT-Datensatzes der Datei als „residente“ Daten, und wenn die Daten groß sind, speichert NTFS die außerhalb des Datensatzes liegenden Daten in Clustern auf der Festplatte als „nicht residente“ Daten.
Geben Sie nun „5“ als Dateinummer ein, woraufhin Sie die Datei des Stammverzeichnisses sehen. Wir werden uns die Dateien und Verzeichnisse im Stammverzeichnis ansehen, indem wir das $INDEX_ALLOCATION-Attribut des Verzeichnisses betrachten, ein verzeichnisspezifisches Attribut, das den Inhalt eines Verzeichnisses aufzeichnet. Wählen Sie dazu den Menüeintrag „Lesen|NTFS-Attribut“ aus, der ein weiteres Dialogfeld öffnet. DiskEdit beachtet die Groß- und Kleinschreibung, also geben Sie das Folgende genau so ein, wie ich es aufgelistet habe:
Base Frs Number: 5
„Base Frs“ (Base File Record Segment, Basisdatei-Datensatzsegment) ist eine andere Bezeichnung für die MFT-Nummer. Sie geben 5 ein, um anzugeben, dass Sie ein Attribut aus dem Stammverzeichnis lesen wollen.
Attribute Type: $INDEX_ALLOCATION
Damit geben Sie DiskEdit zu verstehen, dass Sie die Inhaltsdaten des Verzeichnisses lesen wollen. Ich empfehle, das Pulldownmenü zu verwenden, um das gewünschte Attribut auszuwählen, da DiskEdit sehr wählerisch ist, was die Art der Eingabe des Attributtyps angeht.
Attribute Name: $I30
Wenn Sie sich das $INDEX_ALLOCATION-Attribut des Stammverzeichnisses ansehen, sehen Sie, dass „$I30“ als sein Name in der „Type code, name“-Zeile aufgeführt ist, also geben Sie dies als Attributnamen ein.
Klicken Sie auf „OK“, woraufhin Sie ein Hexadezimalabbild des Attributinhalts erhalten. Wir möchten aber etwas Verständlicheres sehen, also wählen Sie den Menüeintrag „Anzeigen|NTFS-Indexpuffer“ aus. Sie erhalten eine Liste mit dem Inhalt des Verzeichnisses. Scrollen Sie durch die Liste, bis Sie den Eintrag mit dem Namen „TEMP“ sehen. Wenn Sie ihn nicht sehen, befindet sich der Eintrag möglicherweise im $INDEX_ROOT-Attribut des Stammverzeichnisses, einem Attributtyp, der ebenfalls Verzeichnissen zugeordnet ist, und dessen Wert immer im MFT-Datensatz gespeichert wird. Indexstammeinträge und Zuordnungseinträge bilden zusammen eine B+-Baumstruktur, in der alle Einträge eines Verzeichnisses gespeichert sind. Wenn Sie das Attribut $INDEX_ROOT anzeigen müssen, befolgen Sie einfach dieselben Schritte wie zum Anzeigen des Attributs $INDEX_ALLOCATION. Wenn Sie durch einen Indexpuffer scrollen, können Sie auf Doppelzeilen mit Sternchen stoßen: Diese kennzeichnen das Ende eines Indexpuffers und den Anfang des nächsten.
Sobald Sie den Eintrag des TEMP-Verzeichnisses gefunden haben, notieren Sie sich dessen Dateireferenz (FRS, File Reference). Wählen Sie „Lesen|NTFS-Dateidatensatz“ aus, und geben Sie die FRS von TEMP ein. Jetzt sehen Sie den MFT-Datensatz für das TEMP-Verzeichnis. Wir wollen die Datei OUT.TXT finden, also müssen wir den Inhalt von TEMP durchsuchen, um sie zu finden. Zeigen Sie das Attribut $INDEX_ALLOCATION (oder $INDEX_ROOT) des Verzeichnisses TEMP an, wechseln Sie zur Anzeige der Daten als NTFS-Indexpuffer, und suchen Sie die Datei OUT.TXT. Vergessen Sie nicht, die FRS-Nummer von TEMP als Basis-FRS-Nummer im Attributauswahl-Dialogfeld einzugeben. Wenn Sie TEMP gerade erstellt haben, wird es nur einen $INDEX_ROOT haben (wenn Sie sich irgendwo vertippen, kommen Sie in den Genuss, einen der leeren Fehlerdialoge von DiskEdit zu sehen).
Wenn Sie OUT.TXT gefunden und ihre FRS bestimmt haben, verwenden Sie „Lesen|NTFS-Dateidatensatz“, um ihren MFT-Eintrag zu sehen. Scrollen Sie nach unten, bis Sie das Attribut $DATA gefunden haben. Sie sehen nun den Speicherort der Daten von OUT.TXT. Da wir eine kleine Datei erstellt haben, sind die Daten im MFT-Datensatz gespeichert. Wenn Sie versuchen, das $DATA-Attribut von OUT.TXT mit DiskEdit anzuzeigen, wird nichts angezeigt, weil DiskEdit residente Daten nicht ordnungsgemäß anzeigt (einer der vielen Fehler von DiskEdit). Kopieren Sie also eine relative große (> 2 KB) Textdatei in \TEMP\ OUT.TXT. Jetzt können Sie die OUT.TXT-Daten auf eine von zwei Arten anzeigen: Sie können den Anfang der Daten untersuchen (oder alle Daten, wenn sie zusammenhängend auf der Festplatte gespeichert sind), indem Sie „Lesen|NTFS-Cluster“ verwenden und den ersten „lcn“-Wert angeben, den Sie im $DATA-Attribut „Extent List“ von OUT.TXT sehen. Oder Sie können „Lesen|NTFS-Attribut“ verwenden und „$DATA“ als Attributtyp und nichts (d. h. geben Sie nichts in das Feld ein) als Attributnamen eingeben.
Extent-Listen beschreiben den Ort der nicht residenten Daten eines Attributs. Jeder zusammenhängende Datenblock mit einer Länge von bis zu 16 Clustern wird durch einen Extent-Listeneintrag beschrieben. Ein Extent-Listeneintrag gibt eine virtuelle Clusternummer (vcn), eine logische Clusternummer (lcn) und eine Lauflänge an. Eine Vcn ist der Cluster innerhalb der Datei, an dem die durch den Eintrag beschriebenen Daten beginnen. Eine Lcn bezeichnet den logischen Cluster, in dem die Daten auf der Festplatte gespeichert sind, und die runlength ist die Anzahl der Bytes der Attributdaten an diesem Ort (denken Sie daran, dass DiskEdit Ihnen Hexadezimalwerte anzeigt).
Ich habe Ihnen den mühseligen Weg gezeigt, wie Sie den MFT-Datensatz der Datei OUT.TXT finden können, indem ich Ihnen gezeigt habe, wie Sie den Inhalt des Verzeichnisses durchsuchen. Es gibt jedoch eine Abkürzung: Wählen Sie „Crack|NTFS-Pfad“ aus, und geben Sie „TEMP\OUT.TXT“ ein. Sie erhalten die FRS von OUT.TXT und können mit „Lesen|NTFS-Dateidatensatz“ direkt dorthin wechseln.
Damit komme ich zum Ende meiner DiskEdit-Einführung. Ich möchte Sie ermutigen, dieses nützliche Tool spielerisch auszuprobieren, indem Sie Ihre FAT- oder NTFS-Laufwerke durchsuchen. Es ist höchst unwahrscheinlich, dass Sie DiskEdit jemals benutzen werden, um Daten zu ändern, um Ihrer Festplatte aus der Patsche zu helfen, aber wenn Sie neugierig auf das NTFS-Festplattenformat sind (das FAT-Format ist gut dokumentiert), ist dies das perfekte Werkzeug, um Untersuchungen anzustellen.
BALD VERFÜGBAR
WIN2K API-EXPLOSION
Obwohl es nur 4 neue exportierte Kernel-Modus-APIs gibt, die in RC2 ihr Debüt gegeben haben, ist die Anzahl sämtlicher APIs, die Microsoft seit NT 4.0 eingeführt hat, sowohl im Kernel als auch in den Win32-DLLs, explodiert. Nächsten Monat werde ich Ihnen genau sagen, wie viele neue APIs es gibt und wo sie aufgetaucht sind, und leider gleichzeitig den Leuten, die glauben, dass Win2K ein aufgeblähtes Monster ist, gute Munition für ihre Usenet-Rants unter „alt.advocacy.linux“ liefern.
Vielen Dank, dass Sie den Systems Internals Newsletter gelesen haben.
Veröffentlicht Mittwoch, 20. Oktober 1999, um 19:10 Uhr von ottoh
[Newsletter-Archiv ^] [< Band 1, Nummer 4] [Band 2, Nummer 1 >]