Dieser Artikel wurde maschinell übersetzt.

Ereignisablaufverfolgung für Windows

Zentralen Betriebssystem Events in Windows 7, Teil 1

Dr. Insung Park und Alex Bendetovers

Heutige Computersoftware unterbricht ständig neue Gründe. Consumer Software-Anwendungen bieten einen komplexen Satz von Funktionen, die umfangreiche neue Erfahrungen zu ermöglichen. Leistungsfähige Serveranwendungen sind neue Datensätze in Durchsatz, Geschwindigkeit und Skalierung festlegen. Diese Möglichkeit durch schnelle Bearbeitung im Hardware-Technologien und fortlaufende Übernahme von Software Fortschritte in Optimierung, Virtualisierung und verteilt und parallele Datenverarbeitung wurden Verbesserungen vorgenommen. Allerdings als Ergebnis Softwareanwendungen größer und komplizierter geworden. Gleichzeitig den BenutzerErwartungen zu Softwarequalität sind höher als je zuvor. Grundlegende Merkmale wie Leistung, Zuverlässigkeit und Verwaltbarkeit haben erwies den langfristigen Erfolg von Softwareprodukten wichtig als, und Sie werden häufig als primären Features betreibt.

Zunehmenden Komplexität von Software und höheren Benutzererwartungen auf Qualität stellen daher eine schwierige Herausforderung in der Softwareentwicklung. Wenn ein unerwartetes Problem auftritt, ist die Vorhersage der interne Zustand aller relevanten Komponenten nahezu unmöglich. Den Verlauf der Ausführung Abläufe retracing ist zwar mühsam und schwierig, aber häufig erforderlich, die Ursache des Softwareprobleme herausfinden. Wenn Benutzer nach Bereitstellung Probleme melden, erwarten Sie die Ursache des Problems schnell erkannt und behoben werden. Die überwältigende Anzahl von Kombinationen aus Hardware und Software, unterschiedliche Arbeitsauslastung Merkmale und Verwendungsmuster der Endbenutzer Erstellen solcher Aufgaben auch komplexere. Die Möglichkeit, einen Mechanismus verwenden, der Ihnen ermöglicht, System Ausführung auf transparente Weise mit minimalem Aufwand zu verstehen ist dabei von unschätzbarem Wert.

Ereignis-Instrumentation

Die Instrumentation ist eine solche effektive Lösung in messen und Verbessern der Softwarequalität. Software-Leistungsindikatoren haben Anwendung Ausführung Status und der Ressourcennutzung auf einer aggregierten Ebene überwachen auf einfache Weise bereitgestellt. Ereignis Instrumentation ist im Laufe der Jahre wurde auch beliebte. In verschiedenen Phasen der Ausführung durch eine Softwarekomponente ausgelöste Ereignisse können verschiedene Probleme diagnostizieren dauert die Dauer deutlich reduziert. Zusätzlich zum Scannen für bestimmte Ereignisse oder Muster der Ereignisse, können eine Data Mining und Korrelation Techniken, um die Ereignisse, aussagekräftige Statistiken und Berichte über die Ausführung des Programms und problematische Verhalten erzeugen weiter zu analysieren anwenden. Die Möglichkeit, Ereignisse in Produktionssystemen in Echtzeit erfassen kann die Notwendigkeit, ein unhandlich Debugger-Setup auf Kunden Computern haben vermieden werden.

In Windows 2000-Betriebssystem eingeführt, ist Event Tracing für Windows (ETW) eine allgemeine Ereignisablaufverfolgung Plattform auf Windows-Betriebssystemen. ETW ist eine effiziente Pufferung und Protokollierungsmechanismen im Kernel implementiert verwenden, bietet einen Mechanismus durch beide Anwendungen im Benutzermodus und im Kernelmodus-Gerätetreiber ausgelöste Ereignisse beibehalten. Darüber hinaus ETW bietet Benutzern die Möglichkeit zum Aktivieren und deaktivieren Protokollierung dynamisch, sodass leicht zu ausführliche Ablaufverfolgung in Produktionsumgebungen ohne Ausführen Neustarts oder Anwendung neu gestartet.

Das Betriebssystem selbst hat intensiv mit ETW-Ereignissen instrumentiert wurde. Die Möglichkeit, analysieren und Simulieren von zentralen Betriebssystem Aktivitäten basierend auf ETW-Ereignisse in der Entwicklung sowie auf Systemen mit Produktions-Modus wurde wertvoll für Entwickler in viele Qualität Probleme lösen. Mit jeder nachfolgenden Windows-Version ist die Anzahl der durch das Betriebssystem ausgelöste ETW-Ereignisse erhöht;Windows 7 ist das am häufigsten instrumentierte Betriebssystem Datum. Darüber hinaus enthält Windows 7 Tools, die diese Betriebssystem ETW-Ereignisse analysieren, Leistung und Zuverlässigkeit sowie die Qualität in Softwareanwendungen Probleme aufdecken nutzen können.

Viele Anwendungsproblemen Oberfläche als Anomalien bei der Ressourcenverwendung Betriebssystem wie z. B. unerwartete Muster oder Spitzen in der Verbrauch der CPU, Arbeitsspeicher, Netzwerkbandbreite, e/a-Vorgänge usw.. Da OS-Ereignisse für die meisten Systemaktivitäten auf die ursprünglichen Prozess- und Thread zurückverfolgt werden können, können einen beträchtlichen Fortschritt erstellen, in der Sie mögliche Ursachen für viele Anwendungsprobleme auch ohne ETW-Instrumentation in Anwendungen einschränken. Natürlich würde ETW-Instrumentation in der Anwendung weitere Diagnose erheblich effizienter ermöglichen.

Im ersten Artikel unserer zweiteiligen Reihe stellen wir eine Übersicht über die ETW-Technologie und Betriebssystem Instrumentation Core. Es besprechen wir Sie anschließend, um Toolunterstützung erhalten und Verwenden von OS-Ereignisse. Geben Sie es anschließend weitere Details, auf die Ereignisse aus verschiedenen Unterkomponenten der Kern-Betriebssystem. Außerdem erläutern wir wie die verschiedenen Systemereignisse ein umfassendes Bild des Systemverhalten, erzeugen die wir mithilfe eines Satzes von Windows PowerShell-Skripts veranschaulichen kombiniert werden können.

Ereignisablaufverfolgung für Windows

Wie bereits erwähnt, ist ETW eine Protokollierung-Plattform, die effizient die Ereignisse von Softwareanwendungen oder Kernelmodus-Komponenten gesendet wurden aufgezeichnet. ETW-Anbieter-APIs, jede Anwendung, kann DLL- oder Treiber werden einem Ereignisanbieter (eine Komponente, die Ereignisse auslöst) für ETW. Ein Anbieter registriert zuerst ETW und sendet Ereignisse von verschiedenen Punkten im Code durch Einfügen von ETW-API-Aufrufe protokollieren. Alle beschreibbaren Aktivitäten Wichtigkeit kann ein Ereignis, und es wird durch ein Teil der zum Zeitpunkt der Protokollierung von ETW geschriebenen Daten dargestellt. Diese Protokollierung API-Aufrufe werden ignoriert, wenn der Anbieter nicht aktiviert ist. Eine ETW-Controller-Anwendung startet eine ETW-Sitzung und bestimmte Anbieter ermöglicht. Nimmt ein Ereignisanbieter aktiviert eine Protokollierung API-Aufruf, wird das Ereignis dann an die Sitzung gekennzeichnet durch den Controller weitergeleitet. In einer Protokolldatei programmgesteuert in Echtzeit verbraucht oder im Arbeitsspeicher beibehalten, bis der Controller eine Leerung der Daten, die eine Datei anfordert, können an einer Sitzung gesendeten Ereignisse gespeichert werden. Einen vorangegangenen Artikel "Verbessern Debuggen und Leistung optimieren mit ETW" (msdn.microsoft.com/magazine/dvdarchive/cc163437.aspx) enthält weitere Informationen über die ETW-Technologie und zum Hinzufügen von ETW-Instrumentation in eine Anwendung. Im Laufe der Jahre hat ETW stammen, unterstützen viele verschiedene Protokollierung Modi und Features, die auf MSDN dokumentiert sind.

Ein ETW-Ereignis besteht aus einer festen Header gefolgt von kontextspezifischen Daten. Der Header kennzeichnet, das Ereignis und die Komponente Auslösen des Ereignisses, während die kontextspezifischen Daten ("Ereignisnutzlast"Hereafter) verweist auf zusätzlichen Daten, die die Komponente Auslösen des Ereignisses aufzeichnen möchte. Wenn von einem Anbieter ausgelöste Ereignis in eine ETW-Sitzung geschrieben wird, fügt ETW zusätzliche Metadaten der Kopfzeile Thread und Prozess-IDs, die aktuelle CPU auf dem der Protokollierung Thread ausgeführt wird, einschließlich CPU-Zeit Auslastung den Thread und Timestamp. Abbildung 1 zeigt eine XML-Darstellung eines Ereignisses (ein Prozess-Ereignis vom Typ Start) als decodiert, von dem Tool Tracerpt (, die später erläutert werden) in der XML-Dump-Datei. Das < System >Abschnitt ist üblich, alle Ereignisse und allgemeinen Headers die ETW-Datensätze für jedes Ereignis darstellt. Dieses enthält Timestamp, Prozess und Thread-ID, Anbieter-GUID, immer die Prozessorauslastung, CPU-ID und usw.. &Lt; EventData >Abschnitt zeigt die protokollierte Nutzlast dieses Ereignisses. Wie in Abbildung 1 dargestellt, ein Ereignis aus der Windows-Kernel Prozess Schlüssel (einen eindeutigen Schlüssel jeder Prozess für die Identifikation zugewiesen), enthält Prozess starten verarbeiten, übergeordnete Prozess-ID, Sitzungs-ID, beenden, Status (gültig nur für einen Prozess beenden-Ereignis), Benutzer-SID, ausführbare Dateiname der der Prozess und den Befehl, der der Prozess gestartet.

ETW-Domänencontroller sind Anwendungen, die das Steuerelement ETW-API verwenden eingestellt ETW-Sitzungen starten und aktivieren eine oder mehrere Anbieter diese Sitzungen. Sie müssen jede Sitzung einen eindeutigen Namen geben und auf Windows 7 kann es bis zu 64 Sitzungen gleichzeitig ausgeführt.

Abbildung 1 Process Start-Ereignis in XML Dump

<Event xmlns="https://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Guid="{9e814aad-3204-11d2-9a82-006008a86939}" />
<EventID>0</EventID>
<Version>3</Version>
<Level>0</Level>
<Task>0</Task>
<Opcode>1</Opcode>
<Keywords>0x0</Keywords>
<TimeCreated SystemTime="2009-07-14T16:27:43.441456400Z" />
<Correlation ActivityID="
{00000000-0000-0000-0000-000000000000}" />
<Execution ProcessID="2584" ThreadID="4324"
ProcessorID="1" KernelTime="90" UserTime="15" />
<Channel />
<Computer />
</System>
<EventData>
<Data Name="UniqueProcessKey">0xFFFFFA8005BBC950</Data>
<Data Name="ProcessId">0x1430</Data>
<Data Name="ParentId">0xA18</Data>
<Data Name="SessionId"> 1</Data>
<Data Name="ExitStatus">259</Data>
<Data Name="DirectoryTableBase">0x4E1D6000</Data>
<Data Name="UserSID">guest</Data>
<Data Name="ImageFileName">notepad.exe</Data>
<Data Name="CommandLine">notepad</Data>
</EventData>
<RenderingInfo Culture="en-US">
<Opcode>Start</Opcode>
<Provider>MSNT_SystemTrace</Provider>
<EventName xmlns=
"https://schemas.microsoft.com/win/2004/08/events/trace">
Process</EventName>
</RenderingInfo>
<ExtendedTracingInfo xmlns=
"https://schemas.microsoft.com/win/2004/08/events/trace">
<EventGuid>{3d6fa8d0-fe05-11d0-9dda-00c04fd7ba7c}</EventGuid>
</ExtendedTracingInfo>
</Event>

Die Ereignisse von den Kernel und Core-Systemkomponenten sind jedoch in anderen Anwendungen im Benutzermodus oder Kernelmodus-Gerätetreiber Weise protokolliert. Core-System protokolliert Ereignisse zu einer besonderen Sitzung mit einem reservierten Namen "NT-Kernelprotokollierung" Nur die "NT-Kernelprotokollierung"Sitzung ("Kernel"Hereafter) empfängt Core Systemereignisse und akzeptiert keine Ereignisse von anderen regulären Ereignisanbieter. Darüber hinaus werden zentralen Betriebssystem Ereignisse aktiviert entsprechenden Flags angeben, wenn eine Sitzung gestartet wird. Jedes Flag stellt Ereignis Instrumentation in eine andere Hauptkomponente, die selektiv aktiviert werden können. Dies verringert den Verwaltungsaufwand Instrumentation im Kernel und die Authentizität der Systemereignisse Lernziele. Darüber hinaus kann ein neues Feature in Windows 7 Benutzer Aufruflisten zum Zeitpunkt der Anmeldung erfassen. Wenn Symbole verfügbar sind, kann eine eine Kette von Funktionsaufrufen verfolgen, die der Kernel-Ereignisse protokolliert werden. Der Vorteil von Aufrufliste Analyse werden in den nachfolgenden Abschnitten erläutert, wenn einzelne Ereignisse ausführlicher erörtert.

Sammeln von Ereignissen mithilfe der Tools unter Windows

Auf Windows, die Benutzer zum Erfassen von Ereignissen ermöglichen sind ein paar ETW Steuerelement Tools verfügbar. Beispielsweise macht den Systemmonitor ETW-Steuerelement in Form einer Datengruppe Auflistung verfügbar. Der Ereignisprotokolldienst ist auch in der Lage starten und beenden ETW-Sitzungen und Anzeigen von Ereignissen. Für Befehlszeilen und Skripts Schnittstellen logman.exe bietet Optionen für ETW-Steuerelement-Operationen. Ereignis Verbrauch können Befehlszeilenprogramm tracerpt.exe verbrauchen ETW-Protokolldateien und erzeugen von Speicherabbildern in verschiedenen Formaten, einschließlich CSV und XML. Ein Beispiel für eine XML-Darstellung eines Ereignisses Prozess starten, wird im Abbildung 1 angezeigt. In diesem Artikel verwenden wir logman.exe und tracerpt.exe in den Beispielen, die wir präsentieren. Die "Logman Query Providers"Befehl im Abbildung 2 Listet die verschiedenen Flags, die beim Aktivieren der Kernel-Sitzung durch einen Domänencontroller verwendet werden können.

Der folgende Befehl startet die Kernel-Sitzung und Prozess, Thread, Datenträger, Netzwerk, Bild und Registrierung Ereignisse. Die erfassten Ereignisse werden in einer Datei namens systemevents.etl im aktuellen Verzeichnis gespeichert. Steuern der Kernel-Sitzung und zentralen Betriebssystem Ereignisse gesammelt sind Administratorrechte erforderlich:

> logman start "NT Kernel Logger" –p "Windows Kernel Trace"
 (process,thread,img,disk,net,registry) –o systemevents.etl –ets

Um die Auflistung zu beenden, müssen die Benutzer "Logman Stop - Ets" ausstellenBefehl:

> logman stop "NT Kernel Logger" –ets

Das Tool Tracerpt kann die Ereignisse in der Protokolldatei in ein lesbares Format verarbeitet werden. Standardmäßig werden Tracerpt akzeptiert eine oder mehrere Protokolldateien und generiert eine Ausgabedatei Ereignis und eine Zusammenfassung-Datei. Das Standardformat der Ausgabedatei ist XML:

> tracerpt systemevents.etl

Die Logman und Tracerpt können Text, Windows-Hilfe und Support und online-Dokumentation Weitere Informationen zu Optionen und Funktionen dieser Tools haben.

Es sind Analysetools Leistung erweiterte, die zentralen Betriebssystem Ereignisse für verschiedene Analyse und Optimierung Szenarien beanspruchen. Windows Performance Toolkit (WPT) ist ein solches Tool wichtige und steht im Windows SDK (msdn.microsoft.com/performance/cc825801.aspx). WPT ist hilfreich, ein breites Publikum einschließlich Systemherstellern, Hardwareherstellern, Treiberentwickler und allgemeine Anwendungsentwickler. Seine Ablaufverfolgungsanalyse Tools, Xperf und XperfView, anspruchsvolle Techniken (einschließlich hier eingeführte) anwenden zusammenfassen und analysieren die zentralen Betriebssystem-Ereignisse, bieten sinnvolle Perspektiven in das Betriebssystem und Verhalten der Anwendung. Die flexible Benutzeroberfläche bietet viele komplexe und anpassbare Präsentationsoptionen, mit denen Benutzer können auf verschiedene Aspekte der Systemaktivitäten konzentrieren. Abbildung 3 zeigt einen Screenshot des Dienstprogramms XperfView in Aktion.

Zentralen Betriebssystem-Ereignisse

Der Windows-Kern-Betriebssystem verfügt über viele Komponenten, die mit ETW instrumentiert. Wie in Abbildung 2 dargestellt, sind die Ereignisse für Aktivitäten umfasst verschiedene Subsysteme, z. B. Prozesse, Threads, Datenträger- und EA-Vorgängen, Arbeitsspeicher, Netzwerk, Registrierung usw. verfügbar. In diesem Abschnitt stellen wir Details für jede Gruppe von Ereignissen. Besprochen, auch eine Reihe von grundlegenden Betriebssystem Konzepte. Weitere Informationen zu diesen Konzepten finden Sie in den Betriebssystem-zentrierten Referenzmaterialien wie z. B. "Windows Internals, fünfter Edition"durch Russinovitch Solomon und Ionescu auf (Microsoft Press, 2009). Zentralen Betriebssystem Ereignisse werden in zukünftigen Versionen von Windows als Plattform geändert und die Instrumentation weiterentwickelt, um neue Anforderungen zu erfüllen.

Es gibt mehrere Möglichkeiten zu Ereignisdaten verwenden. Eine kann Scannen für eine bestimmte Ereignis z. B. ein Fehlerereignis oder ein Muster der Ereignisse, die Ausführungsablauf darstellen. Andere häufig verwendete Methoden enthalten statistischen Analyse (zählen und summarizing-Ereignisse) Delta Analysis (Analyse Deltas zwischen Standortpaaren Ereignisse, z. B. Start- und End), Aktivität Analyse (eine Aktivität/Anforderung über Ereignis Korrelation tracking) und basierend auf Aufruflisten Analyse der Aggregation und Muster. Im Laufe der Jahre haben wir gefunden es effektive erstellen einen Statuscomputer und Betriebssystem Aktivitäten zu simulieren, wenn wir die Kern-Systemereignisse betrachten. Wenn wir die Systemereignisse in diesem Abschnitt erläutern, werden wir auch beschreiben, wie wir Sie verwenden bei der Erstellung des Statuscomputer.

Prozess, Thread, Image, Verarbeitung Counter-Ereignissen

Ein Thread ist eine grundlegende Speichereinheit Ausführung auf das Windows-Betriebssystem und ein Prozess fungiert als Container für Threads. Jedes Prozesses (sowie Thread) wird eine ID zugewiesen, der eindeutig ist, während er ausgeführt wird. IDs für Prozesse und Threads freigeben den gleichen Anzahl Speicherplatz. Während ein Thread mit der ID A aktiv ist, wird ein nie anderer Prozesse oder Threads erteilt. Die einzige Ausnahme ist die pro CPU im Leerlauf Threads und der Leerlaufprozess, deren IDs alle identisch sind und historisch gesehen wurden 0. Prozess- und Thread-Ereignisse sind die grundlegenden Bausteine beim Herstellen der Automat, der erweiterte Systemaktivitäten Verständnis hilfreich ist. Es gibt zwei Arten von Ereignissen für Prozess- und Thread-Ereignisse: Starten und beenden. Prozess Start- und Enddatum werden protokolliert, wenn ein Prozess startet und bzw. beendet. Dasselbe gilt für Ereignisse Thread starten und beenden. Die Nutzlast für Prozess Ereignisse hat weitere Informationen über den Prozess, z. B. Prozess Name und übergeordneten Prozess ID an, wie in Abbildung 1 dargestellt. Analog dazu enthält die Ereignisnutzlast Thread threadspezifische Informationen, wie Stapel Basis beschränken und Startadresse. Es sollte beachtet werden, dass die IDs der starten Prozesse oder Threads, die Ereignisnutzlast Prozess- und Thread gehören zwar der Ereignisvorspann bereits die Elemente darin. Prozess starten-Ereignisse werden im Kontext von einem übergeordneten Prozess protokolliert, die den aktuellen Prozess erstellt. In diesem Fall der Prozess im < System > IDAbschnitt (Ereignis-Header) ist der übergeordnete Prozess. Der Prozess-ID im Ereignisprotokoll Nutzlast erstellt wird. Dasselbe gilt für Thread-ID Thread Ereignisse.

Für Prozesse und Threads, die vor der Ereignisauflistung gestartet protokolliert ETW Zustand rundown Ereignisse. Zum Zweck der Analyse werden Sie verwendet die ausgeführten Prozesse und Threads gleichzeitig kennzeichnen die Ereignisauflistung beginnt. ETW protokolliert außerdem rundown Ereignisse für die verbleibenden Prozesse und Threads weiterhin ausgeführt, wenn die Auflistung beendet. Prozess und Thread rundown Ereignisse aufzulisten und protokollieren Ereignisse in das gleiche Format wie für alle Prozesse und Threads, einschließlich System und im Leerlauf Prozessen Ereignisse Prozess und Thread starten. Prozess und Thread Rundowns Ereignisse verwenden unterschiedliche Typen, DCStart und DCEnd, um selbst realen Prozess und Threaderstellung und-Beendung unterscheiden. Ein separates außer Kraft gesetzte Ereignis wird für einen Prozess, der beendet wurde, jedoch mit ausstehenden Verweise darauf geschrieben.

Jede Prozess- und Thread während der Ereignissammlung aktiven kann Prozess und Thread-Ereignisse überwacht werden. Beim Erstellen eines Statuscomputers bewahren Verarbeitung Routine eine Liste der aktiven Prozesse und Threads, vielleicht als einige Typ der Objekte in der Anwendung. Wenn ein Thread oder Prozess beendet wird, kann das entsprechende Objekt in eine andere Liste ("complete") platziert werden. Die Prozess-Objekte enthalten auch weitere Informationen (z. B. Prozessname) zu der Prozesse oder Threads, die Sie zu aus die Ereignisnutzlast Prozess- und Thread übernommen verweisen. Es ist einfacher und viel mehr informativ, wenn eine an einen Prozess nach Namen während der Analyse, anstatt-ID verweisen kann, wie IDs wiederverwendet werden können, sobald ein Prozess oder Thread wird beendet (und alle Verweise darauf freigegeben werden). Wenn Ereignisse von anderen Kernkomponenten OS-Aktivitäten während der Zustand Computer Konstruktion und Simulation anzugeben, die Threads und Prozesse, die Sie initiiert befinden sich in der Statuscomputer und deren Objekte werden diese mithilfe von in erster Linie für die Prozess- und Thread-IDs in den Headern Ereignis Aktivitäten Attribut aktualisiert. Am Ende werden Prozess-und Threadobjekte aggregiert, und in einen Bericht mit verschiedenen Metriken zusammengefasst.

Bild Ereignisse entsprechen (auch bekannt als Modul) Bilddateien geladen und Entladen in Prozessadressraum abrufen. Es gibt vier Arten von Image-Ereignisse: Load, Unload, DCStart und DCEnd. Diese Ereignisse werden nicht direkt LoadLibrary Aufrufen jedoch korrelieren. Wenn eine DLL bereits in den Prozess geladen wird, wird in nachfolgende Aufrufen von LoadLibrary für dieselbe DLL einfach erhöht die Anzahl der Modul-Verweise jedoch werden das Modul nicht erneut zugeordnet. Wie die DCStart und DCEnd Ereignistypen Prozess- und Thread werden Image DCStart und DCEnd verwendet, um geladenen Module der bereits ausgeführten Prozesse aufzählen. Bild Ereignisse ermöglichen die Überwachung der geladenen Module und die Zuordnung von Adressen innerhalb eines Prozesses. Sie sind außerdem wichtig in DPC, ISR und System Call Ereignisse zuordnen, wie in einem späteren Abschnitt und Teil 2 dieser Reihe erörtert werden. Die Ereignisnutzlast Bild enthält Informationen, z. B. die Modul-Adresse-Basis und Größe und den Namen der binären Datei geladen (oder entladen). Bild-Ereignisse sind auch für die Decodierung Aufruflisten erforderlich. In einer typischen Zustand Computer Konstruktion lösen Ereignisse aus Bild das Aktualisieren von eine Liste der geladenen Module in ein Prozessobjekt oben genannten.

Verarbeiten Sie Zähler Ereignisse, wenn aktiviert, am Prozessbeendigung protokolliert werden und in seine Nutzlast ein paar Eigenschaften bezüglich der Ausführung Prozessstatistik während der Lebensdauer des Prozesses zeichnen. Sie bestehen aus maximale Speichergröße, maximale Größe des Workingsets, maximalen ausgelagerten und nicht ausgelagerten Pool Verwendung und maximale Auslastung der Auslagerungsdatei. Diese Ereignisse hinweisen, wie ein Prozess auf die Speicherverwendung hat. Wie Prozess-Ereignisse werden separate rundown Prozess Leistungsindikator-Ereignisse für alle aktiven Prozesse am Ende der Ereignisauflistung protokolliert.

Abbildung 2 NT-Kernelprotokollierung Flags aktivieren

>
logman query providers "Windows Kernel Trace"
Provider GUID
------------------------------------------------------------------------
Windows Kernel Trace {9E814AAD-3204-11D2-9A82-006008A86939}
Value Keyword Description
------------------------------------------------------------------------
0x0000000000000001 process Process creations/deletions
0x0000000000000002 thread Thread creations/deletions
0x0000000000000004 img Image load
0x0000000000000008 proccntr Process counters
0x0000000000000010 cswitch Context switches
0x0000000000000020 dpc Deferred procedure calls
0x0000000000000040 isr Interrupts
0x0000000000000080 syscall System calls
0x0000000000000100 disk Disk IO
0x0000000000000200 file File details
0x0000000000000400 diskinit Disk IO entry
0x0000000000000800 dispatcher Dispatcher operations
0x0000000000001000 pf Page faults
0x0000000000002000 hf Hard page faults
0x0000000000004000 virtalloc Virtual memory allocations
0x0000000000010000 net Network TCP/IP
0x0000000000020000 registry Registry details
0x0000000000100000 alpc ALPC
0x0000000000200000 splitio Split IO
0x0000000000800000 driver Driver delays
0x0000000001000000 profile Sample based profiling
0x0000000002000000 fileiocompletion File IO completion
0x0000000004000000 fileio File IO
The command completed successfully.

Kontext wechseln, DPC und ISR-Ereignisse

Kontext wechseln Ereignisse werden protokolliert, jedem Threadwechsel auf einer CPU auftreten und zum Erstellen eines sehr präzise Verlaufs, welche Threads ausgeführt wurden und für wie lange verwendet werden können. Sie treten sehr häufig und erzeugt eine große Datenmenge. Jeder Switch werden zwei Threads beteiligt. Der alte Thread wird entsprechenden Anteil an Ausführungszeit aufzugeben und die Ausführung an den neuen Thread übergeben. Folglich Kontext wechseln Ereignisse enthält alte und neue Thread-IDs, alte und neue Threadprioritäten Grund warten und Wartezeit. Kontextwechsel können aus verschiedenen Gründen, einschließlich der Kernel-Synchronisierungsobjekte (Ereignisse, Zeitgeber, Semaphoren und usw.), Preemption von einem Thread höherer Priorität, Quantum Ablaufdatum und Änderungen in Threadaffinität blockieren auftreten. Eine bestimmte Menge an Kontextwechsel sind immer erwartet. Allerdings übermäßig viele Kontextwechsel kann ein Hinweis auf ineffiziente Verwendung von Synchronisierungsprimitiven und kann zu schlechter Skalierung in Leistung führen. Aufruflisten auf Kontext wechseln Ereignisse aktivieren ermöglicht die detaillierte Analyse auf Gründen Threads abrufen gewechselt.

Deferred Procedure Call (DPC) Ereignisse werden protokolliert, wenn DPCs ausgeführt werden. DPC ist ein Kernel-Modus-Funktion zur erhöhten Interruptebene Ausführungsmodus ausgeführt und normale Threadausführung Vorrang vor hat. Die Ereignisnutzlast DPC enthält DPC Eintrag Zeit und Routine Adresse. ISR (Interrupt Service Routine) einen ähnlichen Mechanismus ist, und es auf einer höheren Ausführung als DPC ausgeführt wird. ISR Ereignisse haben ISR Eintrag Zeit, Routine Adresse, ISR Vektor- und ISR-Rückgabewert. DPC und ISR-Mechanismen sind wichtige Elemente in einer Windows-Treiber, wie Sie i. d. r. zum Behandeln von Hardwareunterbrechungsanforderungen verwendet werden. Treiber und Kernelmodus-Komponenten haben eine recht DPC und ISR verwenden, aber es wird dringend empfohlen, dass Sie als wenig Zeit wie möglich in diesen erweiterten Modi aufwenden. DPC und ISR-Ereignisse dienen zum Überwachen und das Verhalten der verschiedenen Treiber und Kernelmodus-Komponenten überprüfen. Indem Sie die Routine Adressen mit dem Bereich im Bild Ereignisse vergleichen, kann eine für diese Ereignisse DPC und ISR zuständige Komponente nicht Kernel suchen.

Status Computer Konstruktion ermöglicht kombinieren Ereignisse Kontext wechseln, DPC und ISR eine sehr genaue Kontoführung von CPU-Auslastung. Durch Festlegen reserviert Speicher für jeden Prozessor, der seinen aktuellen aktiven Thread basierend auf den Kontext wechseln, DPC und ISR-Ereignisse aufzeichnet, eine kann überwachen--angegebene Timestamp--jede CPU wurde zu diesem Zeitpunkt Aktionen und deren Code Sie ausgeführt wurde. In der Zustand Computer Simulation-Methode Wenn einem Kontextwechsel stattfindet, eine CPU-Objekt wird mit der neuen Thread-ID aktualisiert und so ist das Objekt für den alten Thread mit CPU-Auslastung bis zu der Option. Ebenso sind DPC und ISR-Ereignisse den entsprechenden Kernelmodus-Komponenten attributiert, bei Bedarf.

In bestimmten Fällen z. B. mit IO, Memory oder System Call Ereignissen ETW nicht aufzeichnen den Prozess oder thread-IDs in der Ereignisvorspann in erster Linie um den Verwaltungsaufwand der sehr häufige Ereignisse zu reduzieren. Für solche Ereignisse angezeigt die Werte der Thread und Prozess-IDs in der Kopfzeile als 0xFFFFFFFF (4294967295 =). Wenn Ereignisse Kontext wechseln, DPC und ISR nachverfolgt werden, wie oben beschrieben, können diese Ereignisse an die Threads oder Kernelmodus-Komponente verfolgt werden durch untersuchen das CPU-Objekt für die aktuell ausgeführten Thread oder DPC-ISR.

Arbeitsspeicher-Ereignisse

Arbeitsspeicher-Ereignisse bezeichnen Speichervorgänge-Manager (MM). Windows bietet Seite Ereignisse, harte Seitenfehler Ereignisse und virtueller Speicher. Arbeitsspeicher-Ereignisse sind sehr häufig, insbesondere auf einem ausgelasteten System.

Ein Seitenfehler tritt, wenn ein gesuchter-Out Page Table Entry ungültig ist. Wenn die angeforderte Seite von der Festplatte geschaltet werden muss, es ist einen harte Seitenfehler (ein sehr aufwändiger Vorgang) aufgerufen, und alle anderen Typen gelten Softwareseitenfehler (kostengünstiger Operation). Eine Seite Ereignisnutzlast enthält die Adresse virtuellen Speicher für die ein Seitenfehler passiert ist und der Anweisungszeiger, die ihn verursacht hat. Harte Seitenfehler erfordert den Datenträgerzugriff auf auftreten, der ersten Zugriff auf Inhalte in eine Datei oder Zugriffe auf Speicherblöcke, die ausgelagert wurden werden konnte. Aktivieren die Seite Ereignisse bewirkt, dass ein Hardwareseitenfehler als ein Seitenfehler, die mit einem Typ harte Seitenfehler angemeldet sein. Jedoch hat ein hard Fault i. d. r. eine erheblich größere Auswirkung auf die Leistung, damit ein separates Ereignis nur für ein hard Fault verfügbar ist, die unabhängig voneinander aktiviert werden können. Ein Hard Fault Ereignisnutzlast hat weitere Daten, wie Datei Schlüssel, Offset und Thread-ID im Vergleich zu einem Seite-Ereignis.

Virtueller Speicher Ereignisse bestehen aus Typen virtueller Speicher Speicherplatzreservierung und virtueller Speicher frei und zu MM Anrufe zuordnen und freigeben virtueller Speicher Bereiche entsprechen. Ihre Nutzlast enthält die Prozess-ID, Basisadresse, angeforderte Größe und Flags, die in der API-Aufruf verwendet. Virtueller Speicher-Ereignisse wurden neu hinzugefügt, für Windows 7 und eignen sich zum Aufspüren verlorene Aufrufe der VirtualAlloc-Funktion und übermäßige virtuellen Speichernutzung von Anwendungen.

Speicher Ereignis Kopfzeilen enthalten nicht die IDs der Threads und Prozessen, die die bestimmten Aktivitäten verursacht. Die Ereignisnutzlast Seite verfügt jedoch über die THREADKENNUNG des Threads verursacht den Fehler. Dies ermöglicht die Korrelation von Seite Ereignisse an Threads und Prozessen durch den Statuscomputer. Die Ereignisnutzlast virtueller Speicher enthält die ID des Prozesses für den virtuellen Speichervorgänge ausgeführt wurden. Um an den Thread, die den API-Aufruf zu verfolgen, benötigen Sie Kontextwechsel Kontoführung, die im vorherigen Abschnitt beschrieben.

Ausblick

Windows 7 bietet Hunderte von Ereignisanbietern aus verschiedenen Komponenten. Im ersten Teil dieser zweiteiligen Artikelserie haben wir einige der zentralen Betriebssystem ETW vorgestellt Ereignisse verfügbar, auf Windows 7 und Analysetechniken, die wir bereits seit vielen Jahren verwendet haben. Einzelne Ereignisse bestimmte Aktivitäten in den Kern-BETRIEBSSYSTEMS anzugeben, jedoch wenn kombiniert über kontextbezogenen Analyse Methoden können verwendet werden um aussagekräftige Berichte zu erzeugen, die Einblicke in Mustern und Anomalien bei der Ressourcenverwendung zu bieten. In Teil 2, wir planen, andere zentrale abdecken Betriebssystem ETW-Ereignisse sowie vorhanden einfache Skripts zur Veranschaulichung einige grundlegende Kontoführung Techniken für einige der Betriebssystem-Ereignisse in diese beiden Teile eingeführt. Wir hoffen, dass viele der hier vorgestellten Inhalte nutzen und, dass es die Heraufstufung von sound engineering praktischen größer Softwarequalität und besserer Nutzungserlebnisse führt.

Dr.. Insung Park ist ein Development Manager für die Windows-Verwaltungsinstrumentation und Diagnose Platform-Team. Er hat ein Dutzend Dokumente Leistungsanalyse, Anfrage nachverfolgen, Instrumentation Technologie und Programmieren von Methodik und Unterstützung veröffentlicht. Seine e-Mail-Adresse insungp@microsoft.com.
Alex Bendetov ist leitender Entwicklung für die Windows-Verwaltungsinstrumentation und Diagnose Platform-Team. Er arbeitet an Event Tracing für Windows und die Leistungsindikator-Technologien. Er kann unter erreicht werden alexbe@microsoft.com.