Freigeben über

  • Artikel

[Newsletter-Archiv ^] [< Band 1, Nummer 2] [Band 1, Nummer 4 >]

Der Systems Internals Newsletter Band 1, Nummer 3

http://www.sysinternals.com
Copyright (C) 1999 Mark Russinovich

19. Juni 1999 – In dieser Ausgabe:

  1. NEUERUNGEN BEI SYSTEM INTERNALS

    • SDelete v1.1
    • Strings v2.0
    • LoggedOn
    • Filemon v4.13
    • DebugView/EE v3.1
    • „Innenansichten der NT-Netzwerkfunktionen“
    • Juni „NT Internals“
    • Updatestatus von NTFrob
    • Nicht ganz so neue Sachen

  2. INTERNALS-NEUIGKEITEN

    • Numega DriverStudio veröffentlicht
    • Juni Platform SDK verfügbar
    • Win2K System File Protector (SFP)
    • Schließen von über das Netzwerk geöffneten Dateien

  3. BALD VERFÜGBAR

    • Eine „AWE“-ähnliche Win2K-API

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; Notfalldiskette) und NTRecover.

Winternals Software kündigt die Veröffentlichung der Enterprise-Editionen von Regmon und Filemon an. Diese Hilfsprogramme bieten sämtliche Funktionen der Freeware Filemon und Regmon und fügen die folgenden leistungsstarken Funktionen hinzu:

  • Anzeigen der Registrierungs- und Dateisystemaktivitäten auf Win9x/NT-Remotesystemen
  • Protokollieren der Ausgabe in eine Datei in Echtzeit
  • Kopieren von Ausgabezeilen in die Zwischenablage
  • Hervorheben von Zeilen, die einem Filter entsprechen
  • Gleichzeitiges Anzeigen der Ausgabe von verschiedenen Computern
  • Ausgeben von Ausgaben direkt auf einem Drucker
  • Einfaches Abrufen Ihrer letzten 5 ausgewählten Filter

Bestell- und Preisinformationen finden Sie unter http://www.winternals.com..

Guten Tag,

Willkommen zur dritten Ausgabe des Systems Internals Newsletters. Der Newsletter hat aktuell 4400 Abonnenten.

Im letzten Newsletter habe ich darauf hingewiesen, dass Microsoft den Blue Screen of Death, wie wir ihn kennen, mit dem Wechsel zu Windows 2000 (Win2K) abgeschafft hat. Der neue Win2K-Bluescreen enthält nicht die Informationen über geladene Treiber und das Stapelabbild, die im Bluescreen früherer Versionen von Windows NT enthalten sind. Ich habe Sie gefragt, ob Sie die von Microsoft entfernten Informationen für nützlich halten und ob Sie sich wünschen, dass sie die Finger davon gelassen hätten. Die Reaktionen waren nahezu einstimmig, wobei sich alle Antwortenden (mit einer Ausnahme) gefragt haben, warum Microsoft auf den kleinsten gemeinsamen Nenner setzt. Hier ist eine typische Stellungnahme, die von Tony Lavinio eingesandt wurde:

Dies ist also mit anderen Worten die Kundenreaktion, auf die sich Microsoft bei seiner Entscheidung stützt:

„Ich verstehe es nicht, also muss es schlecht sein; mach es weg.“

Warum entfernen sie nicht einfach den gesamten Bildschirm und zeigen eine Meldung an, die besagt: „Stecker ziehen, Stecker wieder einstecken, von vorne anfangen“? Warum nehmen sie uns einen der wenigen Anhaltspunkte, die wir haben, um herauszufinden, warum die Dinge schiefgelaufen sind?

Wenn es sich um einen Virenscanner, einen Defragmentierer oder einen fehlerhaften Treiber gehandelt hat, hatten wir vorher so zumindest einen Ansatzpunkt für die Suche.

Wenn dieses Tool nur 1 von 10.000 von uns hilft, und das bei der breiten Basis der NT-Bereitstellungen, dann ist es das wert. Zumal wir 0,01 % einen großen Teil der anderen 99,99 % unterstützen.

Wer war der einsame Abweichler? Es ist nicht allzu überraschend, dass es jemand von Microsoft ist, der Bluescreen-Absturzberichte abfängt. Hier ist seine Meinung zu dieser Änderung, die Tonys Spekulationen über den Grund dafür bestätigt:

Ich arbeite in der NT-Setup-Gruppe in PSS bei MS (die für die Behandlung von Bluescreenproblemen zuständig ist). Ich kann Ihnen versichern, dass die meisten Leute, mit denen ich spreche, nicht wissen, was sie mit den Informationen auf einem 4.0 Bluescreen anfangen sollen. Ich bin mir sicher, wenn Sie ein „Stop 0xA mit NAIFILTR.SYS“ überall im Stapel sähen, wüssten Sie, dass Sie Ihr Antivirenprogramm aktualisieren müssen, doch die meisten Leute stellen diese Verbindung nicht her und erkennen wirklich gar nicht, dass der Stoppcode und die Parameter nützlich für sie sind. Menschen, die wissen, wie man Bluescreendaten interpretiert, werden wahrscheinlich verärgert sein, aber leider sind sie eine Minderheit.

Wie ich bereits im letzten Newsletter festgestellt habe, bin ich der Meinung, dass Microsoft den NT 4.0-Bluescreen weiterführen und die Liste der geladenen Treiber sowie das Stapelabbild beibehalten sollte. Ich denke auch, dass sie den Bluescreen verbessern könnten, indem sie mehr Informationen bereitstellen, anstatt weniger. Warum wird z. B. nicht der Name des zum Zeitpunkt des Absturzes gerade ausgeführten Prozesses angezeigt? Oder lassen sie mehr BugCheck-Aufrufe die Adresse des Fehlers übergeben, nicht nur die Adresse, die den Fehler verursacht hat? Ein Hauptgrund, warum PSS auf so viele Kunden getroffen ist, die keine Ahnung vom Bluescreen haben, ist, dass Microsoft nie eine Dokumentation darüber geschrieben hat, wie er zu lesen ist. Zumindest ein Teil der Schuld für die Unwissenheit der Nutzer ist somit also bei Microsoft selbst zu suchen.

Wenn Sie mehr darüber wissen wollen, wie Bluescreens entstehen und was auf dem (NT 4.0) Bluescreen zu sehen ist, lesen Sie meinen Artikel „Inside the Blue Screen“ vom Dezember 1997 im Windows NT Magazine (die Onlineversion finden Sie unter http://www.sysinternals.com/publ.htm).

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

SDELETE V1.1

Im letzten Newsletter habe ich SDelete vorgestellt, ein sicheres Löschhilfsprogramm, mit dem Sie Dateidaten unwiederbringlich zerstören sowie den freien Speicherplatz einer Festplatte von zuvor gelöschten Daten bereinigen können. Die erste Version von SDelete war nicht in der Lage, die Namen von Dateien, die Sie mit SDelete löschen, sicher zu überschreiben. Der Name einer Datei verrät oft vertrauliche Informationen, und die Verwendung von SDelete zum Löschen einer Datei mit einem aufschlussreichen Namen könnte diese Informationen weiterhin verfügbar lassen. Um diese Lücke zu schließen, habe ich SDelete so aktualisiert, dass nicht nur die Dateidaten, sondern auch die Dateinamen sicher überschrieben werden. SDelete löscht einen Dateinamen sicher, indem die Datei 26 Mal umbenennt und dabei jeder Buchstabe des Dateinamens durch aufeinanderfolgende Buchstaben des Alphabets, von A bis Z, ersetzt wird.

SDelete v1.1 können Sie zusammen mit dem vollständigen Quellcode unter http://www.sysinternals.com/sdelete.htm. herunterladen.

STRINGS V2.0

Ausführbare Dateien und DLLs enthalten oft eingebettete Zeichenfolgen, die undokumentierte Registrierungswerte und Fehlermeldungen offenlegen können, die auf undokumentierte Funktionen hinweisen. Leider sind die meisten Windows NT/2K System-DLLs und -EXEs so geschrieben, dass sie Unicode-Zeichenfolgen verwenden, während traditionelle Zeichenfolgen-Suchwerkzeuge wie Grep nur ASCII-Zeichenfolgen extrahieren. Die erste Version meines Hilfsprogramms „Strings“ habe ich vor einigen Jahren geschrieben, um Binärdateien nach ASCII- oder Unicode-Zeichenfolgen zu durchsuchen. Ich habe es bei meinen Nachforschungen für NT Internals oft benutzt, um Dinge herauszufinden, die von Microsoft nicht dokumentiert werden.

Strings hatte jedoch immer einen großen Schwachpunkt, nämlich die Unfähigkeit, einen Platzhalterausdruck als Dateispezifikation zu verwenden, sodass Sie mehrere Dateien auf einmal scannen konnten. Ich wollte diese Funktion, damit ich z. B. anhand des Namens eines Registrierungswerts leicht feststellen könnte, welche System-DLLs darauf verweisen.

Nun habe ich Strings endlich so aktualisiert, dass es vollständige Platzhalter-Dateinamen akzeptiert und Verzeichnisse rekursiv durchläuft. Wenn Sie einen Platzhalterausdruck angeben, stellt Strings den Ausgabezeilen automatisch den Namen der Datei voran, in der eine Zeichenfolge gefunden wurde, sodass Sie etwa wie folgt vorgehen können:

strings *.dll | grep SafeBoot

Wenn Sie sich die Ausgabe dieses Ausdrucks ansehen (eine Version von Grep ist in den Posix-Hilfsprogrammen des Windows NT Resource Kit verfügbar), erfahren Sie, welche System-DLLs den SafeBoot-Registrierungsschlüssel unter Windows 2000 überprüfen. Strings ist auch sehr nützlich, um festzustellen, welche neuen Registrierungswerte von Win2K-System-DLLs, -Treibern und ausführbaren Dateien verwendet werden. Beispielsweise habe ich Strings verwendet, um die Registrierungswerte, auf die der NT 4.0 SP4 TCP/IP-Stapel (tcpip.sys) verweist, mit denen zu vergleichen, auf die der Windows 2000 TCPIP-Stack verweist. Hier sehen Sie etwa die Hälfte der Werte, die für den TCPIP-Stack von Win2K neu sind (bei denen ich von allen annehme, dass sie sie unter HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters befinden):

ReservedPorts
DefaultGatewayMetric
InterfaceMetric
TempLeaseExpirationTime
TempIpAddress
TempMask
DhcpDefaultGateway
TcpWindowSize
TcpInitialRTT
TcpDelAckTicks
EnableTrafficControl
EnableTOSetting
MaxNormLookupMemory
MaxSendSegments
MaxFreeConnections
MaxFreeTWTcbs
FFPFastForwardingCacheSize

Ich werde bestimmt nicht darauf warten, dass Microsoft alle neuen Konfigurationsparameter des Stapels dokumentiert.

Sie können Strings v2.0 unter http://www.sysinternals.com/misc.htm. herunterladen.

LOGGEDON

Wollten Sie schon einmal wissen, wer bei einem NT-Remotesystem angemeldet ist? Wenn ja, dann sollten Sie LoggedOn herunterladen. LoggedOn ist ein einfaches Hilfsprogramm, das Ihnen mitteilt, welche Benutzer interaktiv bei dem lokalen oder einem Remotecomputer angemeldet sind und welche Benutzer über Ressourcenverbindungen (z. B. eine Datei- oder Druckerfreigabe) angemeldet sind. Hier ein Beispiel für die LoggedOn-Ausgabe:

C:\>loggedon main

LoggedOn v1.0 - Logon Session Displayer
Copyright (C) 1999 Mark Russinovich
Systems Internals - http://www.sysinternals.com

Users logged on locally:
MAIN\Administrator

Users logged on via resource shares:
MAINDOM\MARK

Windows NT und Win2K stellen keine API zur Verfügung, mit der Anwendungen feststellen können, wer bei einem Computer angemeldet ist. LoggedOn aber ermittelt dies anhand der Registrierungsschlüssel, die in die HKEY\USERS-Registrierungsstruktur geladen sind. Die Profile aller Benutzer, die interaktiv angemeldet sind, werden in diesen Schlüssel geladen, und die Profile verfügen über Namen, die die SID (Sicherheits-ID) des zugehörigen Benutzerkontos angeben. Wenn Sie z. B. Regedit öffnen und unter HKEY_USERS nachsehen, sehen Sie in etwa Folgendes:

HKEY_USERS\.DEFAULT\S-1-5-21-734676951-386466661-1233803906-500

Hier ist nur ein Benutzer interaktiv angemeldet. Sie können erkennen, dass es sich entweder um den lokalen oder den Domänenadministrator handelt, weil die RID (relative ID) 500 lautet, bei der es sich um die von NT für Administratorkonten reservierte RID handelt.

Durch die Verwendung von APIs, die es einem System erlauben, die Registrierung eines anderen Systems einzusehen, liest LoggedOn den HKEY_USERS-Schlüssel eines Remotecomputers und konvertiert die gefundenen SIDs in Kontonamen. Um festzustellen, wer über eine Ressourcenfreigabe angemeldet ist, verwendet LoggedOn die NET API, die im SDK dokumentiert ist. Das Net-Befehlszeilentool macht ausgiebig Gebrauch von der NET-API. Ein Nebeneffekt von LoggedOn beim Zugriff auf die Registrierung eines Remotesystems ist, dass das Konto, unter dem Sie LoggedOn ausführen, in der Ausgabe von LoggedOn immer als bei einem Remotesystem über eine Ressourcenfreigabe angemeldet angezeigt wird.

Sie können LoggedOn zusammen mit dem vollständigen Quellcode unter http://www.sysinternals.com/misc.htm. herunterladen.

FILEMON V4.13

Filemon v4.13 wurde gerade veröffentlicht; ein Update, das Änderungen am Windows NT-Filtertreiber widerspiegelt und einen Fehler korrigiert, den ich versehentlich in den 4.12-Treiber eingeführt hatte. Der 4.13-Filtertreiber besitzt folgende Änderungen:

  • Er verwendet den Ressourcensynchronisierungstyp, um einige seiner internen Datenstrukturen zu schützen.
  • Er behandelt den neuen Win2K-IRP, IRP_MJ_PNP_POWER.

Der Ressourcensynchronisierungstyp ist sowohl in den Windows NT 4.0 als auch den Win2K Device Driver Development Kit (DDKs) praktisch undokumentiert. Im Entwurfsleitfaden werden Ressourcen nicht einmal erwähnt, während ihre Funktionen in der Referenz unter dem Abschnitt „Executive Support Routines“ dokumentiert sind. Ressourcen sind ein nützlicher Mechanismus zum Schutz von Datenstrukturen, die gleichzeitig von verschiedenen Threads gelesen werden können, aber bei einer Aktualisierung exklusiven Zugriff eines Threads erfordern. Es handelt sich also um Leser/Schreiber-Sperren, die für den gemeinsamen Zugriff von Lesern und für den exklusiven Zugriff von Schreibern erzielt werden. Dateisystemtreiber machen ausgiebig Gebrauch von Ressourcen, weshalb ich es für angemessen gehalten habe, Filemon so zu aktualisieren, dass sie dort verwendet werden, wo es angebracht ist.

Filemon v4.13 behandelt auch den neuen IRP_MJ_PNP_POWER IRP, sodass es ein energie- und Plug & Play-freundlicher Filtertreiber ist, wenn er unter Win2K läuft. Die einzige Anforderung an einen Dateisystem-Filtertreiber hinsichtlich der Behandlung von IRPs dieses Typs besteht darin, sie an die Dateisystemgeräte zu übergeben, an die der Filter angefügt ist.

Sie können Filemon v4.13 zusammen mit dem vollständigem Quellcode unter http://www.sysinternals.com/filemon.htm. herunterladen.

DEBUGVIEW/EE V3.1

DebugView/EE ist ein vielseitiger Debugausgabe-Monitor, mit dem Sie lokale oder Remotedebugausgaben erfassen können, die von Win32-Programmen oder Gerätetreibern im Kernel-Modus unter Win95, Win98, WinNT und Win2K generiert werden. Seine Nützlichkeit ist jedoch in Umgebungen begrenzt, in denen ein Benutzer einen Absturz mit einem Gerätetreiber erlebt – alle Debugausgaben, die DebugView vor einem Absturz erfasst, gehen verloren. Die neueste Version von DebugView/EE behebt dieses Problem unter Windows NT/2K. Wenn ein Benutzer die von einem Gerätetreiber erzeugte Kernel-Modus-Ausgabe aufzeichnet und der Benutzer NT so konfiguriert hat, dass ein Absturzabbild gespeichert wird, kann DebugView/EE die Debugausgabe aus der Abbilddatei extrahieren, wenn das System neu gestartet wird. Benutzen Sie den Menüeintrag „Bearbeiten|Absturzabbild verarbeiten“ von DebugView/EE, um ein Speicherabbild nach Debugausgaben zu durchsuchen. Mit dieser Funktion können Benutzer Ihnen eine Textdatei zurücksenden, die die Debugausgaben enthält, die Ihr Treiber bis zum Zeitpunkt des Absturzes generiert hat.

DebugView/EE v3.1 können Sie unter http://www.sysinternals.com/debugview.htm. herunterladen.

„INNENANSICHTEN DER NT-NETZWERKFUNKTIONEN“

Meine „NT Internals“-Kolumne im Windows NT Magazine vom März 1999 ist jetzt online. Lernen Sie die Netzwerkarchitektur von NT von Grund auf kennen, einschließlich der implementierten APIs, der Schnittstellen zwischen Protokollstapeln und APIs sowie der Art und Weise, wie Hardwarehersteller Netzwerktreiber für die Zusammenarbeit mit Protokolltreibern schreiben. Informieren Sie sich außerdem über einige neue Netzwerkfunktionen von Win2K, einschließlich deserialisiertem NDIS und ATM-Unterstützung.

Lesen Sie „Innenansichten der NT-Netzwerkfunktionen“ und andere frühere „NT Internals“-Kolumnen online unter http://www.sysinternals.com/publ.htm..

JUNI „NT INTERNALS“

Die Juni-Ausgabe meiner Kolumne im Windows NT Magazine trägt den Titel „Inside EFS, Part 1“ (Innenansichten von EFS, Teil 1). Dieser Artikel beschreibt die Architektur des Microsoft-EFS (Encrypting File System, verschlüsselndes Dateisystem) und führt Sie detailliert durch die Schritte, die EFS bei der Verschlüsselung einer Datei durchführt. EFS bietet eine transparente Verschlüsselungsfunktion für NTFS-Laufwerke unter Win2K und wurde von Microsoft speziell entwickelt, um die Fähigkeit unseres NTFSDOS-Tools zu berücksichtigen, NTFS-Dateien ohne Rücksicht auf deren Sicherheit lesen zu können. Diese Kolumne wird in drei Monaten online verfügbar sein.

Vor zwei Newslettern habe ich darüber berichtet, dass die für die Sicherung und Wiederherstellung verschlüsselter Dateien erforderlichen EFS-APIs undokumentiert sind. Leider sind diese APIs in der aktuellen Ausgabe von MSDN immer noch nicht dokumentiert. Mir wurde jedoch mitgeteilt, dass Microsoft die Dokumentation, die als „Microsoft Confidential“ (Vertraulich) gekennzeichnet ist, an seine Partner und an Anbieter von Sicherungssoftware versendet. Außerdem hat David Golds, File Systems Program Manager bei Microsoft, auf der jüngsten Microsoft TechEd-Konferenz in Dallas einen Vortrag über Dateisystemverbesserungen für Win2K gehalten. In der Präsentation, deren Folien Sie online unter http://www.teched99.com/slides/1-337.ppt einsehen können, erwähnt er, dass die Sicherungs-APIs undokumentiert sind, dass Sie ihn aber nerven können, wenn Sie die Dokumentation benötigen. Leider ist seine E-Mail-Adresse nicht auf den Folien aufgeführt.

Besuchen Sie http://www.winntmag.com, um Informationen zum Abonnement des Windows NT Magazin zu erhalten.

UPDATESTATUS von NTFROB

NTFrob ist ein Hilfsprogramm, das ich vor ein paar Jahren veröffentlicht habe und das es Ihnen ermöglicht, die Quantumlängen von Vordergrund- und Hintergrundprozessen unter NT 4.0 genau zu konfigurieren. NTFrob modifiziert interne Datenstrukturen des NT-Kernels, sodass es in hohem Maße Service Pack-spezifisch ist. Seit der Veröffentlichung von NT 4.0 Service Pack 5 werde ich mit Anfragen überhäuft, wann ich NTFrob v1.5, das SP 5-Update, veröffentlichen werde. Die Antwort ist, dass das Update in Kürze kommt – ich warte darauf, dass Microsoft MSDN-Abonnenten das SP5 einschließlich Debuginformationen zur Verfügung stellt. Ich benötige Debuginformationen, um NTFrob für neue Service Packs aktualisieren zu können.

Sie können NTFrob für NT 4 SP0-4 unter http://www.sysinternals.com/ntfrob.htm. herunterladen.

NICHT GANZ SO NEUE SACHEN

Vor ein paar Monaten habe ich bei Systems Internals einen Win9x/NT/2K-Monitor für serielle und parallele Schnittstellen veröffentlicht. Mit Portmon können Sie genau sehen, wie Anwendungen mit seriellen und parallelen Schnittstellen interagieren, einschließlich der Daten, die sie senden und empfangen. Sie können damit Einwahlsitzungen, serielle Laplink-Verbindungen oder Druckeraktivitäten überwachen. Portmon war ein großer Erfolg und wurde kürzlich von Ziff-Davis Software Library mit 5 Sternen ausgezeichnet, der höchstmöglichen Bewertung. Andere Tools von Systems Internals, die 5 Sterne erhalten haben, sind Regmon, NTFSDOS und BlueSave.

Portmon können Sie unter http://www.sysinternals.com/portmon.htm. herunterladen.

INTERNALS-NEUIGKEITEN

DRIVERSTUDIO VERÖFFENTLICHT

NuMega Labs von CompuWare hat DriverStudio veröffentlicht, ein umfassendes Toolkit für Windows 9x/NT/2K-Gerätetreiberentwickler. Es umfasst SoftICE 4.0, BoundsChecker for Drivers, VtoolsD, DriverAgent, DriverWorks, FieldAgent for Drivers und wird in Zukunft um TrueTime for Drivers und TrueCoverage for Drivers erweitert. Wie ich bereits im letzten Newsletter gesagt habe, ist dies ein unverzichtbares Entwickler-Toolkit. NuMega hat außerdem eine Website namens „Driver Central“ eingerichtet, die sich an Entwickler von Gerätetreibern richtet: http://www.numega.com/drivercentral/default.asp..

JUNI PLATFORM SDK VERÖFFENTLICHT

Sie können das Juni-Release des Platform SDK von Microsoft jetzt unter http://www.msdn.microsoft.com/developer/sdk/platform.asp. herunterladen.

WIN2K SYSTEM FILE PROTECTOR (SFP)

Eins der größten Ärgernisse für NT-Systemadministratoren und -Benutzer ist die „DLL-Hölle“ von NT. Die DLL-Hölle ist das Ergebnis vieler Anwendungen, die wichtige System-DLLs mit Versionen aktualisieren, die sie bündeln. Anwendungen tun dies in der Regel, um zu gewährleisten, dass sie ordnungsgemäß funktionieren. Wenn sie jedoch eine DLL ersetzen, beschädigen sie oft andere Anwendungen, indem sie inkompatible Versionen installieren oder sogar eine DLL auf eine ältere Version „aktualisieren“.

Microsoft hat die Probleme mit der DLL-Versionierung in Win2K mit der Einführung des System File Protector (SFP) gelöst. Der Name wird sich zwar bald in Windows File Protector (WFP) ändern, aber ab Beta 3 (Build 2031) heißt er immer noch SFP. SFP ist in einer DLL namens „sfc.dll“ implementiert, die der Windows-Anmeldungsprozess (winlogon.exe) beim Starten des Systems lädt. SFP umfasst eine integrierte Liste von etwa 3000 Win2K-Standardsystem-DLLs, ausführbaren Dateien (EXE), Installationsdateien (INF), Treibern (SYS) und Schriftartdateien (FON), die in 30–40 verschiedenen Verzeichnissen installiert sind. Bei der Initialisierung von SFP wird für jedes Verzeichnis, das zu schützende Dateien enthält, ein Verzeichnisvorgang mit Änderungsmeldung ausgeführt. Wenn es eine Manipulation an einer Datei feststellt, wird ein Dialogfeld angezeigt, das den aktuellen Benutzer informiert, es wird eine Meldung in das Ereignisprotokoll geschrieben und die geänderte Datei durch eine Sicherungskopie ersetzt, die in „%systemroot%\system32\dllcache“ gespeichert ist. Wenn die Sicherungsdatei, nach der SFP in „dllcache“ sucht, fehlt oder ebenfalls manipuliert wurde, ruft SFP eine neue Kopie von den Win2K-Installationsmedien ab.

Um festzustellen, welche Dateien SFP schützt, können Sie das an anderer Stelle in diesem Newsletter erwähnte Hilfsprogramm „Strings“ verwenden, um ein Abbild der in „%systemroot%\system32\sfc.dll“ eingebetteten Unicode-Zeichenfolgennamen zu sichern.

Die einzigen Hilfsprogramme, die Systemdateien aktualisieren können, sind „hotfix.exe“, Service Packs (update.exe), Upgradeinstallationen und der Win2K-Update-Dienst. Wie umgehen diese Werkzeuge SFP? Sie deaktivieren ihn vorübergehend, indem sie die exportierte sfc.dll-Funktion „SfcTerminateWatcherThread“ aufrufen und sicherstellen, dass Aktualisierungen im Unterverzeichnis „dllcache“ berücksichtigt werden. Sie sollten beachten, dass Win2K verlangt, dass alle Systemdateien von Microsoft digital signiert sind, sodass es generell nicht möglich ist, eine Systemdatei mit einer beliebigen eigenen Version zu aktualisieren.

Win32-Programme können mithilfe der Win32-APIs „FindFirstChangeNotification“ und „FindNextChangeNotification“ auf Änderungen in einem Verzeichnis überwachen. Diese APIs informieren eine Anwendung jedoch lediglich darüber, dass sich etwas geändert hat. Sie teilen nicht mit, was genau sich geändert hat. Eine Anwendung muss daher ein ganzes Verzeichnis durchsuchen, um festzustellen, welche Dateien oder Unterverzeichnisse sich möglicherweise geändert haben. SFP verwendet die native API von NT, um eine Änderungsbenachrichtigung anzufordern, in der NT genau mitteilt, welche Dateien oder Unterverzeichnisse sich in den überwachten Verzeichnissen ändern. Die Funktion, die SFP verwendet, heißt „NtNotifyChangeDirectoryFile“ und ist, wie 90 % der nativen API von NT, undokumentiert. Halten Sie in naher Zukunft bei Systems Internals Ausschau nach einem Applet, das Ihnen zeigt, wie Sie „NtNotifyChangeDirectoryFile“ verwenden.

In meiner „NT Internals“-Kolumne der September-Ausgabe, „Inside Win2K Reliability Enhancements, Part 2“ (Innenansichten der Zuverlässigkeitsverbesserungen von Win2K, Teil 2), beschreibe ich SFP ausführlicher.

SCHLIESSEN VON ÜBER DAS NETZWERK GEÖFFNETEN DATEIEN

Eine der häufigsten Fragen, die mir von Besuchern bei Systems Internals gestellt wird, lautet: „Wie schließe ich Dateien, die Benutzer über das Netzwerk geöffnet haben?“ Wenn ein Benutzer eine Datei oder ein Verzeichnis remote geöffnet hat, können Sie die Datei oder das Verzeichnis nicht lokal löschen, umbenennen oder aktualisieren. Eine ähnliche Frage ist: „Wie kann ich feststellen, welche Dateien Benutzer über das Netzwerk geöffnet haben?“ Beide Fragen werden mit dem Net-Befehlszeilenprogramm beantwortet, das im Lieferumfang von Windows NT/2K enthalten ist. Um festzustellen, welche Dateien geöffnet sind, geben Sie einfach „net file“ ein. Sie erhalten eine Namensliste der geöffneten Dateien, der entsprechenden Dateinamenbezeichner und der Namen der Benutzer, die Dateien geöffnet haben. Um eine der als geöffnet angezeigten Dateien zu schließen, geben Sie net file <id> /close ein. Um die lokal geöffneten Dateien anzuzeigen, können Sie meine Tools „NTHandle“ oder „HandleEx“ verwenden.

Die APIs, die den Funktionen des Net-Befehls zum Anzeigen und Schließen von Dateien zugrunde liegen, sind im Platform SDK und in der MSDN Library dokumentiert. Verwenden Sie die NetFileEnum-API, um offene Dateien aufzulisten, und die NetFileClose-API, um eine offene Datei zu schließen. Mit den APIs können Sie tatsächlich die offenen Dateien auf Remoteservern auflisten, was mit dem Befehl Net nicht möglich ist.

NTHandle ist unter http://www.sysinternals.com/nthandle.htm. verfügbar. HandleEx ist unter http://www.sysinternals.com/handleex.htm. verfügbar.

BALD VERFÜGBAR

EINE „AWE“-ÄHNLICHE WIN2K-API

Win2K führt eine neue API namens AWE (Address Window Extensions) ein, mit der speicherintensive Anwendungen direkt auf große Mengen physischen RAM (Arbeitsspeichers) zugreifen und diese verwalten können – sogar mehr als 3 GB, die Obergrenze für RAM, den eine Windows NT-Anwendung in ihrem virtuellen Adressraum adressieren kann. Wenn ein x86-System über PSE (Page Size Extensions) und mehr als 4 GB RAM verfügt, kann eine Anwendung AWE verwenden, um den gesamten Arbeitsspeicher des Computers zu nutzen. Diese API ist daher ideal für speicherintensive Anwendungen wie Webserver und Datenbankserver geeignet. Nächstes Mal werde ich Ihnen erklären, wie Sie die APIs verwenden können, sowohl aus Win32-Anwendungen als auch aus Gerätetreibern heraus.

Da ich gerade beim Thema „speicherhungrige Anwendungen“ bin, hier ein Tipp für alle, die eine Anwendung schreiben, die Dateien zwischenspeichert (wie einen Webserver). Der Cache-Manager von Windows NT teilt seinen Cachespeicher in 256-KB-Slots ein, die als „Ansichten“ (views) bezeichnet werden. Wenn eine Datei mit einer Größe von weniger als 256 KB zwischengespeichert wird, muss der Cache-Manager der Datei dennoch einen ganzen 256-KB-Slot zuweisen, was bedeutet, dass ein Teil des virtuellen Speichers des Cache verschwendet wird. Daher ist es im Allgemeinen leistungseffizienter, Dateien mit einer Größe von weniger als 256 KB im virtuellen Speicher Ihrer eigenen Anwendung zwischenzuspeichern und sich auf das Dateisystem zu verlassen, um Dateien mit einer Größe von mehr als 256 KB zwischenzuspeichern. IIS 5.0 verwendet diesen Trick.

Vielen Dank, dass Sie den Systems Internals Newsletter gelesen haben.

Veröffentlicht Samstag, 19. Juni 1999, um 19:14 Uhr von ottoh

[Newsletter-Archiv ^] [< Band 1, Nummer 2] [Band 1, Nummer 4 >]