Dies sind maschinell übersetzte Inhalte, die von den Mitgliedern der Community bearbeitet werden können. Sie können die Übersetzung verbessern, indem Sie auf den jeweils zum Satz gehörenden Link "Bearbeiten" klicken.Mithilfe des Dropdown-Steuerelements "Inhalt anzeigen" links oben auf der Seite können Sie zudem bestimmen, ob nur der englische Originaltext, nur die deutsche Übersetzung oder beides nebeneinander angezeigt werden.
Event Tracing for Windows
Core OS Events in Windows 7, Part 1
Today's computer software constantly breaks new grounds.
Consumer software applications offer a sophisticated set of features that enable rich new experiences.
Powerful server applications are setting new records in throughput, speed and scale.
These improvements have been made possible by rapid progress in hardware technologies and continuous adoption of software advancements in optimization, virtualization, and distributed and parallel computing.
However, as a result, software applications have become larger and more complicated.
At the same time, users' expectations about software quality are higher than ever.
Fundamental characteristics such as performance, reliability and manageability have proved essential in the long-term success of software products, and they are often celebrated as primary features.
Increasing software complexity and higher user expectations on quality thus present a difficult challenge in software development.
When an unexpected problem occurs, predicting internal states of all relevant components is nearly impossible.
Retracing the history of execution flows is cumbersome and tricky, but often necessary in finding out the root cause of software problems.
When users report problems after deployment, they expect the root cause of the problem to be quickly identified and addressed.
The overwhelming number of hardware and software combinations, different workload characteristics, and usage patterns of end users make such tasks even tougher.
The ability to use a mechanism that enables you to understand system execution in a transparent manner, with minimal overhead, is invaluable.
Event Instrumentation
Instrumentation is one such effective solution in measuring and improving software quality.
Software performance counters have provided a convenient way to monitor application execution status and resource usage at an aggregate level.
Event instrumentation has also been popular over the years.
Events raised by a software component at different stages of execution can significantly reduce the time it takes to diagnose various problems.
In addition to scanning for certain events or patterns of events, one can apply data mining and correlation techniques to further analyze the events to produce meaningful statistics and reports on program execution and problematic behavior.
The ability to collect events on production systems in real time helps avoid the need to have an unwieldy debugger setup on customer machines.
Introduced in the Windows 2000 operating system, Event Tracing for Windows (ETW) is a general-purpose event-tracing platform on Windows operating systems.
Using an efficient buffering and logging mechanism implemented in the kernel, ETW provides a mechanism to persist events raised by both user-mode applications and kernel-mode device drivers.
Additionally, ETW gives users the ability to enable and disable logging dynamically, making it easy to perform detailed tracing in production environments without requiring reboots or application restarts.
The operating system itself has been heavily instrumented with ETW events.
The ability to analyze and simulate core OS activities based on ETW events in development, as well as on production-mode systems, has been valuable to developers in solving many quality problems.
With each subsequent Windows release, the number of ETW events raised by the operating system has increased; Windows 7 is the most instrumented operating system to date.
In addition, Windows 7 contains tools that can utilize these operating system ETW events to analyze system performance and reliability, as well as uncover quality problems in software applications.
Many application problems surface as anomalies in OS resource usage, such as unexpected patterns or spikes in the consumption of CPU, memory, network bandwidth, IOs and so on.
Because OS events for most system activities can be traced to the originating process and thread, one can make considerable progress in narrowing down possible root causes of many application problems, even without ETW instrumentation in applications.
Of course, ETW instrumentation in the application would allow further diagnosis to be significantly more efficient.
In the first article of our two-part series, we present a high-level overview of the ETW technology and core OS instrumentation.
Then, we discuss tool support to obtain and consume OS events.
Next, we provide more details on the events from various subcomponents in the core OS.
We also explain how the different system events can be combined to produce a comprehensive picture of system behavior, which we demonstrate by using a set of Windows PowerShell scripts.
Event Tracing for Windows
As mentioned earlier, ETW is a logging platform that efficiently records the events sent by software applications or kernel-mode components.
Using ETW provider APIs, any application, DLL or driver can become an event provider (a component that raises events) for ETW.
A provider first registers with ETW and sends events from various points in the code by inserting ETW logging API calls.
Any recordable activity of importance can be an event, and it is represented by a piece of data written by ETW at the time of logging.
These logging API calls are ignored when the provider is not enabled.
An ETW controller application starts an ETW session and enables certain providers to it.
When an enabled event provider makes a logging API call, the event is then directed to the session designated by the controller.
Events sent to a session may be stored in a log file, consumed programmatically in real time, or kept in memory until the controller requests a flush of that data to a file.
A previous article, "Improve Debugging And Performance Tuning with ETW" (msdn.microsoft.com/en-us/magazine/dvdarchive/cc163437.aspx), has more details about the ETW technology and how to add ETW instrumentation into an application.
Over the years, ETW has come to support many different logging modes and features, which are documented on MSDN.
An ETW event consists of a fixed header followed by context-specific data.
The header identifies the event and the component raising the event, while the context-specific data ("event payload" hereafter) refers to any additional data that the component raising the event wants to record.
When an event raised by a provider is written to an ETW session, ETW adds additional metadata to the header, including thread and process IDs, the current CPU on which the logging thread is running, CPU time usage of the thread, and timestamp.
Figure 1 shows an XML representation of an event (a Process event of type Start) as decoded by the tracerpt tool (to be discussed later) in the XML dump file.
The <System> section is common to all events and represents the common header that ETW records for each event.
This contains timestamp, process and thread ID, provider GUID, CPU time usage, CPU ID, and so on.
The <EventData> section displays the logged payload of this event.
As shown in Figure 1, a Process Start event from the Windows kernel contains process key (a unique key assigned to each process for identification), process ID, parent process ID, session ID, exit status (valid only for a Process End event), user SID, executable file name of the process, and the command that started the process.
ETW controllers are the applications that use the ETW control API set to start ETW sessions and enable one or more providers to those sessions.
They need to give each session a unique name, and on Windows 7 there can be up to 64 sessions running concurrently.
Figure 1 Process Start Event in XML Dump
<Event xmlns="http://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=
"http://schemas.microsoft.com/win/2004/08/events/trace">
Process</EventName>
</RenderingInfo>
<ExtendedTracingInfo xmlns=
"http://schemas.microsoft.com/win/2004/08/events/trace">
<EventGuid>{3d6fa8d0-fe05-11d0-9dda-00c04fd7ba7c}</EventGuid>
</ExtendedTracingInfo>
</Event>
The events from the kernel and core system components, however, are logged in a manner different from user-mode applications or kernel-mode device drivers.
The core system logs events to a special session with a reserved name, "NT Kernel Logger." Only the "NT Kernel Logger" session ("kernel session" hereafter) receives core system events, and it does not accept events from any other regular event provider.
Also, core OS events are enabled by specifying appropriate flags when a session is started.
Each flag represents event instrumentation in a different core component that can be enabled selectively.
This helps reduce the instrumentation overhead in the kernel and reinforces the authenticity of system events.
In addition, a new feature in Windows 7 allows users to capture call stacks at the time of logging.
If symbols are available, one can trace a chain of function calls that trigger the kernel events to be logged.
The benefit from call-stack analysis will be discussed in subsequent sections, when we discuss individual events in more detail.
Collecting Events Using Tools on Windows
There are a few ETW control tools available on Windows that allow users to collect events.
For instance, the Performance Monitor exposes ETW control in the form of a data collection set.
The EventLog service is also capable of starting and stopping ETW sessions and viewing events.
For command-line and script interfaces, logman.exe offers options to perform ETW control operations.
For event consumption, the command-line tool tracerpt.exe can consume ETW log files and produce dumps in several formats, including CSV and XML.
An example of an XML representation of a Process Start event is shown in Figure 1.
In this article, we use logman.exe and tracerpt.exe in the samples we present.
The "logman query providers" command in Figure 2 lists the different flags that can be used by a controller when enabling the kernel session.
The following command starts the kernel session and enables process, thread, disk, network, image, and registry events.
The collected events will be stored in a file called systemevents.etl in the current directory.
Controlling the kernel session and collecting core OS events require administrator privileges:
> logman start "NT Kernel Logger" –p "Windows Kernel Trace" (process,thread,img,disk,net,registry) –o systemevents.etl –ets
To stop the collection, users need to issue the "logman stop -ets" command:
> logman stop "NT Kernel Logger" –ets
The tracerpt tool can process the events in the log file into a readable format.
By default, tracerpt accepts one or more log files and generates an event output file and a summary file.
The default format of the output file is XML:
> tracerpt systemevents.etl
The logman and tracerpt help text, Windows Help and Support, and online documentation have more details on the switches and features of these tools.
There are advanced performance analysis tools that consume core OS events for various analysis and tuning scenarios.
Windows Performance Toolkit (WPT) is one such notable tool, and is available from the Windows SDK (msdn.microsoft.com/en-us/performance/cc825801.aspx).
WPT is useful to a broad audience, including system builders, hardware manufacturers, driver developers and general application developers.
Its trace analysis tools, Xperf and XperfView, apply sophisticated techniques (including those introduced here) to aggregate and analyze the core OS events to offer meaningful perspectives into the OS and application behavior.
Its flexible GUI provides many rich and customizable presentation options that can help users focus on different aspects of system activities.
Figure 3 shows a screenshot of the XperfView tool in action.
Core OS Events
The Windows core OS has many components instrumented with ETW.
As shown in Figure 2, events are available for activities spanning various subsystems including processes, threads, disk and file IOs, memory, network, registry and so on.
In this section, we provide details for each group of events.
We also discuss a number of core operating system concepts.
More information on these concepts can be found in OS-centric reference materials such as "Windows Internals, 5th Edition," by Russinovitch, Solomon and Ionescu (Microsoft Press, 2009).
Core OS events are subject to change in future versions of Windows, as the platform and its instrumentation evolve to meet new requirements.
There are several ways to make use of event data.
One can scan for a certain event, such as an error event, or a pattern of events that represent execution flow.
Other popular methodologies include statistical analysis (counting and summarizing events), delta analysis (analyzing deltas between pairs of events, such as Start and End), activity analysis (tracking an activity/request through event correlation), and aggregation and pattern analysis based on call-stacks.
Over the years, we have found it effective to construct a state machine and simulate OS activities when we look at core system events.
When we explain the system events in this section, we will also describe how we use them in building the state machine.
Process, Thread, Image, Process Counter Events
A thread is a basic unit of execution on the Windows OS, and a process acts as a container for threads.
Each process (and thread) is assigned an ID that is unique while it is running.
IDs for processes and threads share the same number space.
That is, while a thread with ID A is active, A is never given to other processes or threads.
The only exception is the per-CPU idle threads and the idle process, whose IDs are all identical and have been historically 0.
Process and Thread events are the basic building blocks in establishing the state machine, which is helpful in understanding more advanced system activities.
There are two types of events for Process and Thread events: Start and End.
Process Start and End are logged when a process starts and terminates, respectively.
The same applies to Thread Start and End events.
The payload for Process events has more details about the process, such as process name and parent process ID, as shown in Figure 1.
Likewise, the Thread event payload contains thread-specific information, such as stack base and limit, and start address.
It should be noted that the IDs of the starting processes or threads are part of the Process and Thread event payload, although the event header already has those items in it.
Process Start events are logged in the context of a parent process that creates the current process.
In that case, the process ID in the <System> section (event header) is the parent process.
The process ID in the event payload is the one being created.
The same applies to thread ID in Thread events.
For processes and threads that started before the event collection, ETW logs state rundown events.
For the purpose of analysis, they are used to denote the running processes and threads at the time the event collection begins.
ETW also logs rundown events for the remaining processes and threads still running when the collection ends.
Process and Thread rundown events enumerate and log events in the same format as Process and Thread Start events for all processes and threads, including system and idle processes.
Process and Thread rundowns events use different types, DCStart and DCEnd, to distinguish themselves from real process and thread creation and termination.
A separate Defunct event is written for a process that has terminated, but with outstanding references to it.
Every process and thread active during event collection can be tracked using Process and Thread events.
When you build a state machine, the processing routine should keep a list of active processes and threads, perhaps as some type of objects in the program.
When a thread or process terminates, the corresponding object may be placed in a different ("complete") list.
The process objects may also contain more details (such as process name) on the processes or threads that they refer to, picked up from the Process and Thread event payload.
It is simpler and a lot more informative if one can refer to a process by name during analysis, rather than by ID, as IDs can be recycled once a process or thread terminates (and all references to it are released).
When events from other core components indicate OS activities during the state machine construction and simulation, the threads and processes that initiated them are located in the state machine, and their objects are updated to attribute those activities, using primarily the process and thread IDs in the event headers.
At the end, process and thread objects are aggregated and summarized into a report with various metrics.
Image events correspond to image (also known as module) files getting loaded and unloaded into process address space.
There are four types of Image events: Load, Unload, DCStart and DCEnd.
These events do not directly correlate to LoadLibrary calls, however.
If a DLL is already loaded in the process, subsequent LoadLibrary calls for the same DLL simply increment the count of module references but will not map the module again.
Like the DCStart and DCEnd types of Process and Thread events, Image DCStart and DCEnd are used to enumerate loaded modules of already running processes.
Image events allow for the tracking of loaded modules and the mapping of addresses within a process.
They are also important in mapping DPC, ISR, and System Call events, as will be discussed in a later section and in Part 2 of this series.
The Image event payload contains information such as the module address base and size, and the name of the binary file loaded (or unloaded).
Image events are also required for decoding call-stacks.
In a typical state machine construction, Image events trigger the updating of a list of loaded modules into an aforementioned process object.
Process Counter events, when enabled, are logged at process termination and record in its payload a few properties regarding the process execution statistics over the lifetime of the process.
They consist of peak memory size, peak working set size, peak paged and nonpaged pool usage, and peak page file usage.
These events indicate how a process behaved with respect to memory usage.
Like Process events, separate rundown Process Counter events are logged for all active processes at the end of event collection.
Figure 2 NT Kernel Logger Enable Flags
>
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.
Context Switch, DPC and ISR Events
Context Switch events are logged every time thread switches occur on a CPU and can be used to construct a very accurate history as to which threads have been running and for how long.
They occur very frequently and produce a large amount of data.
In each switch, two threads are involved.
The old thread will give up its share of execution time and hand the execution to the new thread.
Thus, Context Switch events contains old and new thread IDs, old and new thread priorities, wait reason and wait time.
Context switches can happen for various reasons, including blocking on kernel synchronization objects (events, timers, semaphores and so on.), preemption by a higher priority thread, quantum expiration, and changes in thread affinity.
A certain amount of context switches are always expected.
However, excessive context switching can be an indication of inefficient use of synchronization primitives and can lead to poor scaling in performance.
Enabling call-stacks on Context Switch events allows in-depth analysis on reasons for threads getting switched out.
Deferred Procedure Call (DPC) events are logged when DPCs are executed.
DPC is a kernel-mode function executed at elevated interrupt-level execution mode, and it preempts regular thread execution.
The DPC event payload includes DPC entry time and routine address.
Interrupt Service Routine (ISR) is a similar mechanism, and it runs at a higher execution level than DPC.
ISR events have ISR entry time, routine address, ISR vector and ISR return value.
DPC and ISR mechanisms are important elements in a Windows driver, as they are typically used for handling hardware interrupts.
Drivers and kernel-mode components have a right to use DPC and ISR, but it is strongly recommended that they spend as little time as possible in these elevated modes.
DPC and ISR events are used to monitor and verify the behavior of various drivers and kernel-mode components.
By comparing the routine addresses against the range information in Image events, one can locate the kernel component responsible for those DPC and ISR events.
In state machine construction, combining Context Switch, DPC and ISR events enables a very accurate accounting of CPU utilization.
By setting aside storage for each processor that records its current active thread based on Context Switch, DPC and ISR events, one can monitor -- given any timestamp -- what each CPU was doing at that time and whose code it was executing.
In the state machine simulation method, when a context switch takes place, a CPU object is updated with the new thread ID, and so is the object for the old thread with CPU usage up to the switch.
Likewise, DPC and ISR events are attributed to the corresponding kernel-mode components, if needed.
In certain cases, such as with IO, Memory or System Call events, ETW does not record the process or thread IDs in the event header, primarily to reduce the overhead of very frequent events.
For such events, the values of thread and process IDs in the header show up as 0xFFFFFFFF (= 4294967295).
If Context Switch, DPC and ISR events are tracked as described above, those events can be traced to the thread or kernel-mode component by examining the CPU object for the currently running thread or DPC/ISR.
.gif)
Memory Events
Memory events denote memory manager (MM) operations.
Windows offers Page Fault events, Hard Page Fault events and Virtual Memory events.
Memory events tend to be very frequent, especially on a busy system.
A page fault occurs when a sought-out page table entry is invalid.
If the requested page needs to be brought in from disk, it is called a hard page fault (a very expensive operation), and all other types are considered soft page faults (a less expensive operation).
A Page Fault event payload contains the virtual memory address for which a page fault happened and the instruction pointer that caused it.
A hard page fault requires disk access to occur, which could be the first access to contents in a file or accesses to memory blocks that were paged out.
Enabling Page Fault events causes a hard page fault to be logged as a page fault with a type Hard Page Fault.
However, a hard fault typically has a considerably larger impact on performance, so a separate event is available just for a hard fault that can be enabled independently.
A Hard Fault event payload has more data, such as file key, offset and thread ID, compared with a Page Fault event.
Virtual Memory events consist of Virtual Memory Allocation and Virtual Memory Free types and correspond to MM calls to allocate and free virtual memory ranges.
Their payload contains the process ID, base address, requested size and flags used in the API call.
Virtual Memory events were newly added for Windows 7 and are useful for tracking down leaked calls to the VirtualAlloc function and excessive virtual memory usage by applications.
Memory event headers do not contain the IDs of the threads and processes that caused the particular activities.
The Page Fault event payload, however, has the thread ID of the thread causing the fault.
This allows the correlation of Page Fault events to threads and processes through the state machine.
The Virtual Memory event payload contains the ID of the process for which virtual memory operations were performed.
To track it to the thread making the API call, you need the context switch accounting, described in the previous section.
Next Time
Windows 7 features hundreds of event providers from various components.
In the first part of this two-part article series, we have presented some of the core OS ETW events available on Windows 7 and the analysis techniques that we have used for many years.
Individual events indicate certain activities in the core OS, but if combined through context-sensitive analysis methods, they can be used to produce meaningful reports that provide insights into patterns and anomalies in resource usage.
In Part 2, we plan to cover other core OS ETW events as well as present simple scripts to demonstrate a few basic accounting techniques on some of the OS events introduced in these two parts.
We hope that many people will take advantage of the content presented here and that it will lead to the promotion of sound engineering practice, greater software quality and better user experiences.
Dr.
Insung Park
is a development manager for the Windows Instrumentation and Diagnosis Platform Team.
He has published a dozen papers on performance analysis, request tracking, instrumentation technology, and programming methodology and support.
His e-mail address is insungp@microsoft.com.
Alex Bendetov
is a development lead for the Windows Instrumentation and Diagnosis Platform Team.
He works on both Event Tracing for Windows and the Performance Counter technologies.
He can be reached at alexbe@microsoft.com.
|
Ereignisablaufverfolgung für Windows
Zentralen Betriebssystem Events in Windows 7, Teil 1
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..
≪ 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="http://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=
"http://schemas.microsoft.com/win/2004/08/events/trace">
Process</EventName>
</RenderingInfo>
<ExtendedTracingInfo xmlns=
"http://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.
|
|
| Tip: Click the printer button in your browser toolbar to get the printer friendly version of this article. |
|