[Newsletter-Archiv ^] [Band 1, Nummer 2 >]
Der Systems Internals Newsletter, Band 1, Nummer 1
14. April 1999 – In dieser Ausgabe:
NEUIGKEITEN BEI SYSTEMS INTERNALS
- VolumeID für Windows 9x
- EFSDump
- ListDLLs für Compaq Alpha
- Einblicke in den Startprozesses, Teil 2
- Mein Artikel für die April-Ausgabe des Windows NT Magazine
- Keine Ehre, wem Ehre gebührt
- Nicht ganz so neue Sachen
NEUIGKEITEN ZU INTERNALS
- Win2K-Treiberüberprüfung
- Y2K-Tests mit „Boot.ini“
BALD VERFÜGBAR
- Spinlocks in Warteschlangen in Win2K
- Tokenmon
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.
Guten Tag,
Willkommen zur ersten Ausgabe des Systems Internals Newsletter. Seit seiner Ankündigung vor etwas mehr als einer Woche konnte der Newsletter bereits 1.000 Abonnent*innen gewinnen, was mich sehr freut.
Ziel des Newsletters ist es, Sie zeitnah über neue Hilfsprogramme und Artikel zu informieren, die bei Systems Internals erscheinen, sowie Ihnen Informationen zu internen Aspekten von Windows zu liefern, die kein geeignetes Forum auf der Website von Systems Internals haben. Wenn Sie Anmerkungen oder Vorschläge zum Newsletter haben, können Sie diese gerne an mich (mark@...) weitergeben. Bitte leiten Sie auch den Newsletter an alle Interessierten aus Ihrem Bekanntenkreis weiter. Informationen zum Abonnieren sowie zum Abmelden oder Ändern Ihres Abonnements finden Sie am Ende des Newsletters.
Vielen Dank!
-Mark
NEUIGKEITEN BEI SYSTEMS INTERNALS
VOLUMEID FÜR WINDOWS 9X
Unter Windows NT und Windows 9x können Sie zwar mithilfe des Befehls „label“ die Bezeichnung für ein logisches Laufwerk oder für ein Diskettenlaufwerk ändern, aber es gibt keine Möglichkeit, die Volume-IDs zu ändern, die beim Formatieren von Laufwerken willkürlich zugewiesen werden. Das VolumeID-Programm, das seit über einem Jahr für Windows NT auf der System Internals-Website verfügbar ist, wurde vor Kurzem für Windows 9x portiert. Mit diesem Applet können Sie die Volume-IDs für Festplatten und Disketten beliebig ändern.
VolumeID verwendet APIs, mit denen Anwendungen direkten Lese- und Schreibzugriff auf logische Laufwerke – und unter Windows 9x auf physische Laufwerke (sprich: Disketten) – erhalten und Dateisysteme umgangen werden. Unter Windows NT/2K verwendet VolumeID reguläre ReadFile- und WriteFile-Vorgänge, um auf unformatierte Laufwerksrohdaten zuzugreifen. Das Besondere ist, wie der Name des Volumes angegeben wird, auf das zugegriffen werden soll. Im Microsoft Knowledge Base-Artikel Q100027 erfahren Sie, wie von einer Anwendung unter Windows NT/2K aus auf physische oder logische Laufwerke zugegriffen werden kann. Als Basis für den Zugriff auf logische Laufwerke unter Windows 9x können Sie den Beispielcode verwenden, der im Microsoft Knowledge Base-Artikel Q174569 bereitgestellt wird. Wenn Sie in Ihrer Anwendung unter Windows 9x direkten Zugriff auf Diskettenlaufwerke benötigen, verwenden Sie den E/A-Steuerungsbefehl VWIN32_DIOC_DOS_INT13 von Win32. Dieser ist in MSDN dokumentiert.
VolumeID kann hier heruntergeladen werden: http://www.sysinternals.com/misc.htm.
EFSDUMP
In Windows 2000 kommt zum ersten Mal die integrierte Dateiverschlüsselungstechnologie von Microsoft zum Einsatz: das verschlüsselnde Dateisystem (Encrypting File System, EFS). EFS bringt eine Reihe neuer APIs zum Bearbeiten verschlüsselter Dateien mit. Eine davon ist QueryUsersOnEncryptedFile. Mit ihr können Sie sehen, welche Benutzer*innen für den Zugriff auf verschlüsselte Dateien registriert sind und welche Benutzer*innen als Wiederherstellungs-Agents für diese Dateien registriert sind. Ich habe ein kleines Programm namens EFSDump geschrieben, mit dem Sie diese Informationen für verschlüsselte Dateien auf Ihrem System ganz einfach anzeigen können.
Wo wir gerade bei EFS-APIs sind: Es gibt eine Reihe neuer APIs, die Stand April noch nicht in MSDN dokumentiert sind, was in dieser späten Phase des Windows 2000-Releasezyklus recht beunruhigend ist. Das gilt insbesondere für OpenEncryptedFileRaw, ReadFileEncryptedRaw, WriteFileEncryptedRaw und CloseEncryptedFileRaw (alle exportiert durch „ADVAPI32.DLL“ von Win2K). Diese APIs müssen von jeder Anwendung verwendet werden, die verschlüsselte Dateien sichern möchte. Also entweder gibt Microsoft entsprechende Informationen nur an ausgewählte Partner weiter, oder Anbieter von Sicherungssoftware müssen sich ordentlich ins Zeug legen, um ihre Produkte auf den Markt zu bringen, wenn Microsoft die APIs doch irgendwann öffentlich dokumentiert. Fest steht, dass die Entwickler*innen des Programms NTBACKUP von Windows 2000 bereits Zugriff auf die API-Dokumentation hatten: NTBACKUP von Win2K Beta 3 nutzt die APIs aktiv.
Bei Interesse an internen Aspekten von EFS empfehle ich die Lektüre meiner anstehenden zweiteiligen Serie zu EFS im Juni/Juli im Rahmen meiner Kolumne „NT Internals“ im Windows NT Magazine. In dem Artikel beschreibe ich genau, wo FEKs (File Encryption Keys, Dateiverschlüsselungsschlüssel) und benutzerseitige EFS-Schlüssel gespeichert werden, wie der Verschlüsselungsprozess von NTFS, dem EFS-Treiber und LSASRV (dem Subsystemserver der lokalen Sicherheitsautorität) durchgeführt wird und natürlich, wie die Entschlüsselung funktioniert.
EFSDump mit vollständigem Quellcode kann hier heruntergeladen werden: http://www.sysinternals.com/misc.htm.
LISTDLLS FÜR COMPAQ ALPHA
Die Anzahl verfügbarer Hilfsprogramme für die Alpha-Version bei Systems Internals nimmt immer weiter zu. Die neueste Ergänzung ist ListDLLs, ein Befehlszeilenprogramm, mit dem Sie DLL-Informationen für ausgeführte Prozesse anzeigen können. Mit meinem HandleEx-Tool können Sie diese Informationen sowie Informationen zu den Handles (Dateien, Prozesse, Threads, Synchronisierungsobjekte) anzeigen, die durch Prozesse geöffnet wurden. HandleEx ist allerdings ein GUI-Tool, was nicht immer praktisch ist. (Es kann z. B. nicht innerhalb einer Batchdatei ausgeführt werden.)
Sind Sie neugierig auf das Verhältnis der Downloads der x86-Version der typischen Systems Internals-Hilfsprogramme gegenüber der entsprechenden Alpha-Version? Es liegt bei etwa 20:1. Das entspricht ziemlich genau der Benutzerbasis mit installiertem Alpha NT, die laut Branchenschätzungen bei fünf Prozent des gesamten NT-Markts liegt.
ListDLLs und andere Alpha-Portierungen (einschließlich HandleEx) können hier heruntergeladen werden: http://www.sysinternals.com/alpha.htm.
EINBLICKE IN DEN STARTPROZESSES, TEIL 2
Die Januar-Ausgabe meiner Kolumne „NT Internals“ aus dem Windows NT Magazine ist jetzt online über die Windows NT Magazine-Website verfügbar. Einen Link zu diesem Teil sowie zu Teil 1 und zu älteren Kolumnen vom Typ „NT Internals“ finden Sie bei Systems Internals auf der Seite mit den Veröffentlichungen: http://www.sysinternals.com/publ.htm.
MEIN ARTIKEL FÜR DIE APRIL-AUSGABE DES WINDOWS NT MAGAZINE
Sehen Sie sich auch meinen Leitartikel „Linux and the Enterprise“ in der April-Ausgabe des Windows NT Magazine an. Ich enthülle einige signifikante Probleme in Bezug auf den Linux 2.2-Kernel sowie im Zusammenhang mit Netzwerkserveranwendungen (Unternehmensanwendungen), die letztendlich dafür sorgen, dass diese Version des Linux-Kernels nicht mit der Leistung von NT und anderen UNIX-Varianten konkurrieren kann.
KEINE EHRE, WEM EHRE GEBÜHRT
Vielleicht haben Sie in diesem Zusammenhang von der neuesten Veröffentlichung von D.H. Brown (einem Analystenunternehmen) zur Eignung von Linux als Betriebssystem für Unternehmen gehört. Der Verfasser oder die Verfasserin des Berichts hat sich stark aus einer E-Mail von mir bedient, die jemand im Januar in der Usenet-Newsgroup für den Linux-Kernel veröffentlicht hatte. Der Bericht ist nicht öffentlich verfügbar und muss für eine hohe Summe gekauft werden. Aber falls Sie Zugriff auf den Bericht haben und die Seiten 44 und 45 zu Linux und Multiprozessoren mit meiner E-Mail bei Deja News vergleichen, sehen Sie eine direkte Parallele, bis hin zu kleinen Details.
NICHT GANZ SO NEUE SACHEN
Ich nutze diesen Abschnitt des Newsletters, um auf aktuelle Änderungen an der Systems Internals-Website hinzuweisen, die Ihnen möglicherweise nicht bekannt sind, und/oder um Informationen zu einem Hilfsprogramm bereitzustellen, die über die Informationen auf der Website hinausgehen. Beispielsweise haben wir vor ein paar Wochen Filemon v4.1 veröffentlicht. Diese Version von Filemon kann sowohl Named Pipe- als auch E-Mail-Slot-Aktivitäten unter Windows NT/2K überwachen. Die erforderliche Erweiterung des Codes, um dies zu unterstützen, war relativ überschaubar, da Named Pipes und E-Mail-Slots als Dateisystemtreiber implementiert sind. Der schwierige (mühsame) Teil bestand darin, die privaten IOCTLs (I/O Control Commands, E/A-Steuerungsbefehle) zu ermitteln, die diese speziellen Dateisysteme unterstützen, damit Filemon sie anzeigen kann. Filemon funktioniert unter Windows NT/2K sowie unter Windows 9x und kann hier heruntergeladen werden: http://www.sysinternals.com/filemon.htm.
Wenn Sie mehr zur internen Funktionsweise von Filemon erfahren möchten, lesen Sie die Februar-Ausgabe meiner Kolumne „NT Internals“ mit dem Titel „Inside NT Utilities“ im Windows NT Magazine. Der Artikel beschreibt die Verwendung von Filemon, Regmon, NTFSDOS, NewSID und HandleEx und enthält einige Informationen zur Funktionsweise.
NEUIGKEITEN ZU INTERNALS
WINDOWS 2000-TREIBERÜBERPRÜFUNG
In Windows 2000 Beta 3 wird eine überaus leistungsfähige Gerätetreiber-Entwicklungshilfe namens Driver Verifier (Treiberüberprüfung) eingeführt. Dieses Tool arbeitet mit Code im Kernel, um die Kontrolle über Ihren Treiber zu übernehmen und die Einhaltung von Kernelmodusregeln auf ganz neue Weise zu überprüfen. Fehlerhafte Gerätetreiber haben mit Abstand den größten Anteil daran, dass viele Menschen NT für ein instabiles Betriebssystem halten, und dieses Tool zielt darauf ab, das zu korrigieren, indem es Treiberentwickler*innen dabei hilft, Fehler zu finden, bevor sie bei Benutzer*innen auftreten.
Verschiedene Arten subtiler Probleme können bei beiläufigen Treibertests (die häufigste Art von Tests, die unter engen Time-to-Market-Einschränkungen durchgeführt werden) und sogar bei intensiven Stresstests unbemerkt bleiben. Ein häufiges Problem sind Treiber, die auf ausgelagerten Arbeitsspeicher mit erhöhtem IRQL (hohe Interruptpriorität) zugreifen. Wenn der Arbeitsspeicher, auf den der Treiber zugreift, zum Zeitpunkt des Zugriffs physisch vorhanden ist (also nicht in die Auslagerungsdatei ausgelagert wurde), bleibt der unzulässige Zugriff unbemerkt. Wenn Sie einen Treiber veröffentlichen, der gegen diese Regel verstößt, wird er wahrscheinlich irgendwann einen Bluescreen-Absturz verursachen.
Ein anderer verbreiteter Fehler bei der Treiberprogrammierung entsteht, wenn Entwickler*innen beim Schreiben des Codes davon ausgehen, dass ausgelagerter und/oder nicht ausgelagerter Arbeitsspeicher immer verfügbar ist, und deshalb die Rückgabewerte für Zuordnungen nicht überprüfen. Wenn der Pool aufgebraucht ist und der Treiber eine NULL-Pufferadresse erhält, dereferenziert der Treiber das System in einen Bluescreen. Eine Poolauslastung ist zwar selten, sollte Systemadministrator*innen aber trotzdem keinen Bluescreen bescheren. Ein ähnlicher Arbeitsspeicherfehler ist ein Pufferüberlauf oder -unterlauf. Hierbei liest oder schreibt ein Treiber außerhalb seines zugeordneten Puffers.
Die Treiberüberprüfung behandelt IRQL-Probleme, indem Aufrufe aller Funktionen, die IRQLs in einem Treiber ändern (z. B. KeRaiseIrql, KeAcquireSpinLock), beim Laden des Treibers durch entsprechende Überprüfungskernelfunktionen (VerifierKeRaiseIrql, VerifierKeAcquireSpinLock) ersetzt werden. Wenn der IRQL auf DISPATCH_LEVEL oder höher erhöht wird, ruft der Überprüfungscode die interne Speicher-Manager-Funktion MmTrimAllPageableSystemMemory() auf, um die Verschiebung aller ausgelagerten Daten aus dem physischen Speicher zu erzwingen. Wenn also ein Treiber gegen die IRQL-Regel verstößt, nicht auf auslagerungsfähige Daten oder Code auf DISPATCH_LEVEL oder höher zuzugreifen, erkennt der Speicher-Manager den Zugriffsversuch auf eine nicht vorhandene Seite und löst einen Bluescreen aus. Dadurch können Entwickler*innen diese Arten von Fehlern schnell erkennen, bevor der Treiber veröffentlicht wird, da sie beim Debuggen des Absturzes ihren Treiber im Fehlerstapel vorfinden.
Die Treiberüberprüfung führt damit Speicherauslastungstests durch, wobei die Importtabelle des zu überprüfenden Treibers gepatcht wird, sodass der Treiber Arbeitsspeicherfunktionen der Überprüfung aufruft anstatt die Standard-Kernelversionen. Ein Aufruf von ExAllocatePool wird beispielsweise durch einen Aufruf von VerifierAllocatePool ersetzt. Es gibt zwei Techniken, die die Überprüfung verwendet, um Entwickler*innen dabei zu helfen, Arbeitsspeicherfehler schnell zu finden. Die erste besteht in der Verwendung eines speziellen Arbeitsspeicherpools, in dem eine Schutzseite (eine ungültige Seite) direkt nach dem Ende des Puffers platziert wird. Darüber hinaus wird der Teil der Seite, in dem der Puffer zugeordnet ist, der dem Puffer vorausgeht, mit einer Signatur gefüllt. Überläufe, die sich innerhalb einer Seite jenseits des Endes eines Puffers befinden, werden sofort erkannt, da sie zu unzulässigen Seitenfehlern auf der Schutzseite führen. Unterläufe, die eine Änderung von Daten vor einem Puffer beinhalten, werden von der Überprüfung erkannt, wenn der Treiber die Zuordnung des Arbeitsspeichers aufhebt, da sich die Signatur geändert hat.
Treiber, die immer einen nicht leeren Pool erwarten, werden durch die Speicherfehlerinjektion der Überprüfung dazu gebracht, einen Absturz zu verursachen. Sie können die Überprüfung so konfigurieren, dass die Poolzuweisungen eines Treibers nach dem Zufallsprinzip nicht erfolgreich sind.
Es gibt eine Handvoll weiterer Fehlertypen, nach denen die Treiberüberprüfung sucht, einschließlich IRP-Konsistenz (E/A-Anforderungspaket) und Schreibschutz von System- und Treiber-Codepages.
Gerätetreiberentwickler*innen, die mit der Treiberüberprüfung testen, tun nicht nur sich selbst einen Gefallen, sondern auch Ihrem Unternehmen und der NT-Community. Beachten Sie, dass Sie auch Ihre NT 4.0-Treiber testen sollten, die mit Win2K kompatibel sind, sobald Sie Zugriff auf die Treiberüberprüfung haben. (Das ist bei den meisten Entwickler*innen mit der MSDN-Auslieferung von Win2K Beta 3 Ende April oder Mai der Fall.)
Weitere Informationen finden Sie unter Treiberüberprüfung.
Y2K-TESTS MIT „BOOT.INI“
Wenn Sie häufig die Systems Internals-Website besuchen, sind Sie wahrscheinlich bereits über den neuen nicht dokumentierten Win2K-BOOT.INI-Schalter „/YEAR“ im Bilde. Ich habe auf der Website nicht erwähnt, dass der Schalter auch von NT 4.0 Service Pack 4 unterstützt wird. Mit diesem Schalter können Sie NT und der gesamten Software auf einem NT-System suggerieren, es wäre ein anderes Jahr. Mit „/YEAR=2001“ wird dem System beispielsweise suggeriert, es wäre 2001. Daher eignet sich der Schalter perfekt zum Testen auf Y2K-Probleme auf allen Softwareebenen. Der Vorteil gegenüber der manuellen Zurücksetzung der BIOS-Uhr (z. B. über das Clock-Applet) besteht darin, dass die Änderung vorübergehend und nur aktiv ist, wenn Sie eine Installation starten, die den Schalter in der BOOT.INI-Zeile enthält. Dies erleichtert die Erstellung einer speziellen Y2K-Installation, indem Sie einfach eine vorhandene Startzeile aus „BOOT.INI“ duplizieren und den Schalter „/YEAR“ hinzufügen.
BALD VERFÜGBAR
Der nächste Newsletter kommt voraussichtlich in ein paar Wochen. Bei meinem nächsten Internals-Tipp geht es um Spinlocks in Warteschlangen – eine neue Art von Spinlock, die Windows 2000 für seine globalen Spinlocks verwendet. Dies sind die globalen Spinlocks, die in Windows 2000 vorhanden sind:
- KiDispatcherLock: die Scheduler-Datenbanksperre
- KiContext-SwapLock: die Thread-Swap-Sperre
- MmPfnLock: die physische Seitenrahmen-Datenbanksperre
- MmSystemSpaceLock: die Kernelmodus-Adressraumsperre
- CcMasterSpinLock: das globale Spinlock des Cache-Managers
- CcVacbSpinLock: die Zuordnungsarraysperre des Cache-Managers
Anstatt wie in NT 4.0 reguläre Kernel-Spinlocks (KeAcquireSpinLock, KeReleaseSpinLock) für diese globalen Sperren zu verwenden, verwendet der Windows 2000-Kernel Spinlocks in Warteschlangen (KeAcquireQueuedSpinLock, KeReleaseQueuedSpinLock). Diese Sperren weisen einige interessante Eigenschaften auf, die die Busaktivität auf SMPs minimieren. Beim nächsten Mal erfahren Sie, wie Spinlocks in Warteschlangen implementiert werden.
Mit Tokenmon wird bei Systems Internals demnächst ein weiteres Überwachungstool verfügbar. Tokenmon zeigt detaillierte Informationen zu allen tokenbezogenen Aktivitäten auf Ihrem System an – einschließlich Anmeldungen, Abmeldungen, Nutzung von Berechtigungen und Identitätswechsel.
Vielen Dank, dass Sie den Systems Internals Newsletter gelesen haben.
Veröffentlicht am Mittwoch, den 14. April 1999 um 19:16 Uhr von ottoh