Este artigo foi traduzido por máquina.

Rastreamento de Eventos para Windows

Eventos de sistema operacional básico no Windows 7, parte 1

Dr. Insung Park e Alex Bendetovers

Software de computador hoje constantemente quebras de novo plano. Aplicativos de software de consumidor oferecem um conjunto sofisticado de recursos que permitem experiências sofisticadas de novas. Aplicativos de servidor eficiente estiverem definindo novos registros no taxa de transferência, velocidade e a escala. Esses aprimoramentos foram feitos possíveis por andamento rápido em tecnologias de hardware e contínua adoção de software avanços na otimização, virtualização e computação paralela e distribuídas. No entanto, como resultado, aplicativos de software tornaram maiores e mais complicado. Ao mesmo tempo, os usuários'expectativas sobre qualidade do software são maiores do que nunca. Características fundamentais, como o desempenho, confiabilidade e capacidade de gerenciamento tem comprovado essenciais para o sucesso a longo prazo de produtos de software e eles geralmente são comemorados como principais recursos.

Crescente complexidade de software e as expectativas de usuário superiores em qualidade, portanto, apresentam um difícil desafio no desenvolvimento de software. Quando ocorre um problema inesperado, é praticamente impossível prever estados internos de todos os componentes relevantes. Retracing o histórico de fluxos de execução é complicado e complicado, mas geralmente necessário em descobrir a causa raiz dos problemas de software. Quando os usuários relatar problemas após a implantação, eles esperam que a causa raiz do problema ser identificada e abordada rapidamente. O número incrível de combinações de hardware e software, características de carga de trabalho diferentes e padrões de uso de usuários finais fazer tarefas, até mesmo tougher. A capacidade de usar um mecanismo que permite que você compreender a execução do sistema de maneira transparente, com sobrecarga mínima, é imprescindível.

Evento WMI

Instrumentação é uma tal solução eficaz em medir e melhorar a qualidade do software. Contadores de desempenho do software forneceu uma maneira conveniente de monitorar o aplicativo execução status e recurso uso em um nível de agregação. Evento instrumentação também foi popular ao longo dos anos. Eventos gerados por um componente de software em diferentes estágios de execução podem reduzir significativamente o tempo para diagnosticar diversos problemas. Além de verificação para certos eventos ou padrões de eventos, um pode aplicar técnicas de mineração e correlação de dados para analisar melhor os eventos para produzir estatísticas significativas e relatórios em execução do programa e o comportamento problemático. A capacidade de coletar eventos em sistemas de produção em tempo real ajuda a evitar a necessidade de uma instalação do depurador complicadas em máquinas cliente.

Evento de rastreamento para Windows (ETW) introduzido no sistema operacional Windows 2000, é uma plataforma de rastreamento de eventos geral em sistemas operacionais Windows. Usando um buffer eficiente e um mecanismo de log implementado no kernel do, ETW fornece um mecanismo para manter eventos gerados por aplicativos de modo de usuário e drivers de dispositivo no modo kernel. Além disso, ETW oferece aos usuários a capacidade de habilitar e desabilitar o log dinamicamente, tornando fácil de executar o rastreamento detalhado em ambientes de produção sem a necessidade de reinicialização ou aplicativo for reiniciado.

O próprio sistema operacional tiver sido instrumentado intensamente com eventos ETW. A capacidade de analisar e simular atividades de OS principais com base em eventos ETW em desenvolvimento, bem como em sistemas de modo de produção, foi valioso para desenvolvedores em solucionar muitos problemas de qualidade. Com cada versão subseqüente do Windows, aumentou o número de eventos ETW gerados pelo sistema operacional;Windows 7 é o sistema operacional mais instrumentado Data. Além disso, o Windows 7 contém ferramentas que podem utilizar esses eventos ETW de sistema operacional para analisar o desempenho do sistema e a confiabilidade, bem como descobrir problemas de qualidade em aplicativos de software.

Muitos problemas de aplicativo superfície como anomalias no uso de recursos OS, como padrões inesperados ou picos no consumo de CPU, memória, largura de banda da rede, E/s e assim por diante. Porque OS eventos para a maioria das atividades do sistema podem ser rastreados para o processo de origem e o thread, um pode fazer andamento considerável em restringir pressionada possíveis causas de muitos problemas de aplicativo, mesmo sem instrumentação ETW em aplicativos. Obviamente, ETW instrumentação no aplicativo permitiria que o diagnóstico adicional a ser significativamente mais eficiente.

O primeiro artigo de nossa série de duas partes, apresentamos uma visão geral de alto nível do ETW tecnologia e instrumentação OS principais. Em seguida, abordaremos suporte de ferramenta para obter e consumir eventos de sistema operacional. Em seguida, fornecemos mais detalhes sobre os eventos de vários subcomponentes na principal do sistema operacional. Também explicamos como os eventos do sistema diferentes podem ser combinados para produzir uma imagem abrangente do comportamento do sistema, que demonstraremos usando um conjunto de scripts do Windows PowerShell.

Rastreamento de Eventos para Windows

Como mencionado anteriormente, o ETW é uma plataforma de log que registra os eventos enviados por aplicativos de software ou componentes do modo kernel com eficiência. Usando o provedor de ETW APIs, qualquer aplicativo, driver ou DLL pode se tornar um provedor de eventos (um componente que gera eventos) para ETW. Um provedor primeiro registra com ETW e envia eventos de vários pontos no código inserindo ETW fazer chamadas de API. Qualquer atividade gravável de importância pode ser um evento, e ela é representada por uma parte dos dados gravados pelo ETW no momento do log. Essas chamadas de API de log são ignoradas quando o provedor não está habilitado. Um aplicativo do controlador ETW inicia uma sessão de ETW e permite que determinados provedores. Quando um provedor de eventos habilitado faz um log de chamada da API, o evento, em seguida, é direcionado para a sessão designada pelo controlador. Eventos enviados a uma sessão podem ser armazenados em um arquivo de log, consumido programaticamente em tempo real ou mantidos na memória até que o controlador solicita uma liberação dos dados em um arquivo. Um artigo anterior, "Melhorar depuração e desempenho ajuste com o ETW"(msdn.microsoft.com/magazine/dvdarchive/cc163437.aspx), tem mais detalhes sobre a tecnologia ETW e como adicionar instrumentação ETW em um aplicativo. Nos anos, ETW chegou oferecem suporte a muitos modos diferentes de log e recursos, que estão documentados no MSDN.

Um evento ETW consiste em um cabeçalho fixo seguido pelos dados específicos de contexto. O cabeçalho identifica o evento e o componente de disparar o evento, enquanto os dados de contexto específicos "(carga do evento de"hereafter) se refere a quaisquer dados adicionais que o componente de disparar o evento deseja registrar. Quando um evento gerado por um provedor é gravado em uma sessão de ETW, ETW adiciona metadados adicionais para o cabeçalho, incluindo thread e processo identificações, a CPU atual no qual o thread de log está sendo executado, tempo da CPU do thread e carimbo de data/hora. A Figura 1 mostra uma representação XML de um evento (um evento de processo do tipo Iniciar) como decodificado pela ferramenta tracerpt (a ser discutido posteriormente) no arquivo de despejo de XML. O sistema de < >seção é comum a todos os eventos e representa o cabeçalho comuns que os registros para cada evento ETW. Ele contém um carimbo de data/hora, ID de thread e processo, GUID do provedor, tempo da CPU, identificação de CPU e assim por diante. &Lt; EventData >seção exibe a carga conectada deste evento. Como mostrado na Figura 1, iniciar um processo evento do kernel do Windows contém chave de processo (uma chave de exclusiva atribuída a cada processo de identificação), processo, identificação do processo pai, identificação de sessão, sair status (válido somente para um evento de término de processo), SID de usuário, nome do arquivo executável do processo e o comando que iniciou o processo.

ETW controladores são os aplicativos que usam o controle do ETW API definem para iniciar sessões ETW e ativar um ou mais provedores a essas sessões. Eles precisam dar a cada sessão de um nome exclusivo e no Windows 7 pode haver até 64 sessões em execução simultaneamente.

Figura 1 Processo iniciar eventos no despejo XML

<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>

No entanto, os eventos de componentes de sistema principal e de kernel, são registrados de maneira diferente do modo de usuário aplicativos ou drivers de dispositivo no modo kernel. Núcleo do sistema registra eventos de uma sessão especiais com um nome reservado, "NT Kernel Logger." Somente o "NT Kernel Logger"sessão ("kernel sessão"hereafter) recebe eventos de sistema principal, e não aceita eventos de qualquer outro provedor de eventos regulares. Além disso, principais OS eventos são ativados, especificando sinalizadores apropriados quando uma sessão é iniciada. Cada sinalizador representa instrumentação de eventos em um componente principal diferentes que pode ser habilitada seletivamente. Isso ajuda a reduzir a sobrecarga de instrumentação no kernel e reforça a autenticidade de eventos do sistema. Além disso, um novo recurso no Windows 7 permite que os usuários capturar as pilhas de chamada no momento do log. Se os símbolos estiverem disponíveis, um pode rastrear uma cadeia de chamadas de função que disparam eventos de kernel devem ser registrados. A vantagem da análise de pilha de chamadas será abordada nas seções subseqüentes, quando discutiremos eventos individuais em mais detalhes.

Coleta de eventos usando ferramentas no Windows

Existem algumas ferramentas de controle do ETW disponíveis no Windows que permitem aos usuários coletar eventos. Por exemplo, o desempenho do sistema expõe ETW controle no formulário de um conjunto de coleção de dados. O serviço de log de eventos também é capaz de iniciar e parar ETW sessões, além de Visualizar eventos. Para linha de comando e interfaces de script, logman.exe oferece opções para executar operações de controle do ETW. Para consumo do evento, tracerpt.exe ferramenta de linha de comando pode consumir arquivos de log do ETW e produzir despejos em vários formatos, incluindo CSV e XML. Um exemplo de uma representação XML de um evento iniciar processo é mostrado na Figura 1. Neste artigo, nós usamos logman.exe e tracerpt.exe nos exemplos, apresentamos. Os "provedores de consulta do logman"comando no Figura 2 lista os diferentes sinalizadores que podem ser usados por um controlador ao habilitar a sessão de kernel.

O seguinte comando inicia a sessão de kernel e permite que processo, thread, disco, rede, imagem e eventos do Registro. Os eventos coletados serão armazenados em um arquivo chamado systemevents.etl no diretório atual. Controlar a sessão de kernel e coletar eventos de sistema operacional principal exigem privilégios de administrador:

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

Para interromper a coleção, os usuários precisam emitir a "interrupção de logman - ets"comando:

> logman stop "NT Kernel Logger" –ets

A ferramenta tracerpt pode processar os eventos no arquivo de log em um formato legível. Por padrão, tracerpt aceita um ou mais arquivos de log e gera um arquivo de saída do evento e um arquivo de resumo. O formato padrão do arquivo de saída é XML:

> tracerpt systemevents.etl

Logman de tracerpt ajudam a texto, Ajuda e suporte e documentação on-line tem mais detalhes sobre as opções e recursos dessas ferramentas.

Existe são avançadas ferramentas de análise de desempenho que consumam eventos de sistema operacional principal para vários cenários de ajustes e análise. Windows Performance Toolkit (WPT) é uma dessas ferramentas importante e está disponível Windows SDK (msdn.microsoft.com/performance/cc825801.aspx). WPT é útil para um público amplo, incluindo os integradores de sistemas, fabricantes de hardware, os desenvolvedores de driver e os desenvolvedores de aplicativos genéricos. A análise de rastreamento ferramentas, Xperf e XperfView, aplicam técnicas sofisticadas (incluindo aqueles apresentado aqui) para agregar e analisar os eventos principais do SO para oferecer perspectivas significativas no sistema operacional e o comportamento do aplicativo. Sua GUI flexível fornece várias opções de apresentação rica e personalizável que podem ajudar os usuários a se concentrar em diferentes aspectos das atividades do sistema. Figura 3 mostra uma captura de tela da ferramenta XperfView em ação.

Eventos principais do SO

O núcleo do Windows OS tem muitos componentes instrumentados com ETW. Como mostrado na Figura 2, eventos estão disponíveis para atividades englobando vários subsistemas incluindo processos, segmentos, registro de disco e arquivo de E/s, memória, rede, e assim por diante. Nesta seção, fornecemos detalhes para cada grupo de eventos. Também discutimos um número de principais conceitos do sistema operacional. Obter mais informações sobre esses conceitos encontradas em centrado em OS materiais de referência, como "Windows Internals, Quinta edição"Russinovitch, Solomon e Ionescu (Microsoft Press, 2009). Principais OS eventos estão sujeitos a mudar em futuras versões do Windows, como a plataforma e seu instrumentação evoluir para atender aos requisitos de novos.

Há várias maneiras de fazer uso de dados do evento. Um pode procurar um determinado evento, como um evento de erro ou um padrão de eventos que representam o fluxo de execução. Outras metodologias populares incluem análise estatística (eventos contagem e summarizing), análise de delta (análise deltas entre pares de eventos, como inicial e final), análise de atividade (uma atividade/solicitação através de correlação de eventos de controle) e análise de agregação e padrão com base em pilhas de chamadas. Nos anos, descobrimos ele eficaz construir uma máquina de estado e simular OS atividades quando examinarmos principais eventos do sistema. Quando explicamos os eventos do sistema nesta seção, também descreveremos como usamos na criação de máquina de estado.

Processo, thread, imagem, eventos de contadores de processo

Um segmento é uma unidade básica de execução no sistema operacional Windows e um processo atua como um recipiente para segmentos. Cada processo (e thread) é atribuída uma identificação que é exclusiva enquanto ele estiver sendo executado. Identificações de processos e segmentos compartilham o mesmo espaço número. Ou seja, enquanto um segmento com A identificação estiver ativo, A nunca é dada a outros processos ou segmentos. A única exceção é threads por CPU ocioso e o processo ocioso, cujas identificações são todos idênticos e tem sido historicamente 0. Eventos de processo e segmento são os blocos de construção básicos estabelecer a máquina de estado, que é útil na compreensão atividades mais avançadas do sistema. Há dois tipos de eventos para eventos de processo e thread: Início e término. Processo de início e fim são registrados quando um processo inicia e termina, respectivamente. O mesmo se aplica a eventos de segmento de início e final. A carga para eventos de processo tem mais detalhes sobre o processo, como nome e pai processo de identificação do processo, como mostrado no Figura 1. Da mesma forma, a carga do evento de thread contém informações de segmento específicas, como pilha base e o limite e o endereço inicial. É preciso observar que as identificações de segmentos ou processos inicial são parte da carga do evento processo e segmento, embora o cabeçalho do evento já possui esses itens. Processo iniciar eventos são registrados no contexto de um processo pai que cria o processo atual. Nesse caso, o processo de identificação no sistema de < >seção (cabeçalho do evento) é o processo pai. O processo de identificação no caso de carga é aquele que está sendo criado. O mesmo se aplica a ID do thread no thread de eventos.

Para processos e segmentos que iniciado antes da coleta de eventos, ETW registra eventos de encerramento do estado. Para fins de análise, elas são usadas para indicar os processos e segmentos em execução no momento que começa a coleta de eventos. ETW também registra eventos de encerramento para os restantes processos e segmentos ainda em execução quando a coleção termina. Eventos de encerramento de processo e segmento enumerar e registrar eventos no mesmo formato como eventos de processo e thread iniciar para todos os processos e threads, incluindo sistema e processos ociosos. Processo e thread eventos rundowns usam diferentes tipos, DCStart e DCEnd, para distinguir próprios de processo real e criação do thread e encerramento. Um evento extintos separado é gravado para um processo foi finalizado, mas com pendentes referências a ele.

Cada processo e thread ativo durante a coleta de eventos podem ser rastreada usando eventos de processo e segmento. Quando você cria uma máquina de estado, a rotina de processamento deve manter uma lista de processos ativos e threads, talvez como algum tipo de objeto no programa. Quando um thread ou processo é encerrado, o objeto correspondente pode ser colocado em uma lista diferente ("concluída"). Os objetos de processo também podem conter mais detalhes (como nome do processo) em processos ou threads que eles se referem, pegou de carga de evento processo e segmento. É mais simples e muito mais informativos se um pode se referir a um processo pelo nome durante a análise, em vez de pela identificação, como IDs podem ser reciclados depois encerra um processo ou segmento (e todas as referências a ele são liberadas). Quando eventos de outros componentes essenciais indicarem OS atividades durante a construção de máquina de estado e a simulação, os segmentos e processos que iniciou a eles estão localizados na máquina de estado e seus objetos são atualizados para atributo essas atividades, usando principalmente as identificações de thread e processo nos cabeçalhos de eventos. No final, objetos de thread e processo são agregados e resumidos em um relatório com várias métricas.

Eventos de imagem correspondem aos arquivos de imagem (também conhecido como módulo) obter espaço de endereço carregado e descarregado em processo. Há quatro tipos de eventos de imagem: Carregar, descarregar, DCStart e DCEnd. Esses eventos não estar diretamente correlacionados a LoadLibrary chamadas, no entanto. Se uma DLL já está carregada no processo, chamadas LoadLibrary subseqüentes para a mesma DLL simplesmente incrementa a contagem de referências de módulo mas não mapear o módulo novamente. Como os tipos DCStart e DCEnd de eventos de processo e thread, imagem DCStart e DCEnd são usados para enumerar módulos carregados de processos já em execução. Eventos de imagem permitem o controle de módulos carregados e o mapeamento de endereços dentro de um processo. Eles também são importantes no mapeamento eventos DPC, ISR e chamada de sistema, como será discutido em uma seção posterior e em parte 2 desta série. A carga do evento imagem contém informações como a base do módulo endereço, tamanho e o nome do arquivo binário carregados (ou descarregado). Imagem eventos também são necessários para decodificação pilhas de chamadas. Em uma construção de máquina de estado comum, eventos de imagem disparam a atualização de uma lista de módulos carregados em um objeto de processo mencionadas anteriormente.

Processa eventos do contador, quando ativado, são registrados no encerramento do processo e gravar em sua carga algumas propriedades sobre as estatísticas de execução do processo durante a vida útil do processo de. Eles consistem em tamanho de memória de pico, tamanho do conjunto de trabalho de pico, pico paginada e uso de pool não paginado e pico do arquivo de página. Estes eventos indicam como um processo agiu em relação ao uso de memória. Como eventos de processo, separados encerramento eventos de contadores de processo são registrados para todos os processos ativos no final da coleta de eventos.

Figura 2 NT Kernel Logger Ativar sinalizadores

>
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.

Alternar do contexto, DPC e ISR eventos

Contexto alternar eventos são registrados sempre thread opções ocorrem em uma CPU e podem ser usadas para construir um histórico muito preciso para execução de quais segmentos e por quanto tempo. Eles ocorrem com muita freqüência e produzem uma grande quantidade de dados. Em cada opção, dois threads envolvidos. O antigo segmento será desistir seu compartilhamento do tempo de execução e mão a execução para o novo segmento. Portanto, eventos de alternância de contexto contém antigo e novo thread identificações, antigas e novo prioridades do thread, aguarde motivo e tempo de espera. Alternâncias de contexto podem acontecer por vários motivos, incluindo o bloqueio em objetos de sincronização do kernel (eventos, timers, semáforos e assim por diante), preemption por um thread de prioridade mais alta, expiração quantum e alterações na afinidade de segmento. Uma certa quantidade de alternâncias de contexto sempre são esperadas. No entanto, a alternância de contexto excessivo pode ser uma indicação de uso ineficiente da primitivos de sincronização e pode levar para dimensionamento ruim no desempenho. Ativar pilhas de chamadas em eventos de alternância de contexto permite que análise detalhada razões para segmentos Obtendo alternados check-out.

Eventos de chamada de procedimento (DPC) adiada são registrados quando DPCs são executadas. DPC é uma função do modo kernel executada no modo de execução elevados de nível de interrupção e ele preempts execução regular de thread. A carga do evento DPC inclui DPC entrada tempo e endereço de rotina. Rotina de serviço de interrupção (ISR) é um mecanismo semelhante e é executado em um nível de execução maior do que DPC. Eventos ISR têm ISR entrada tempo, endereço de rotina, ISR vetor e valor de retorno ISR. Mecanismos de DPC e ISR são elementos importantes em um driver do Windows, como eles geralmente são utilizados para manipular interrupções de hardware. Drivers e componentes do modo kernel tem um direito de usar DPC e ISR, mas é altamente recomendável que eles passam como pouco tempo possível nesses modos elevados. Eventos DPC e ISR são usados para monitorar e verificar o comportamento de vários drivers e componentes do modo kernel. Comparando os endereços de rotina em relação a informações da imagem eventos intervalo, um pode localizar o componente de núcleo responsável por esses eventos DPC e ISR.

Na construção de máquina de estado, a combinação de eventos de alternância de contexto, DPC e ISR permite que um muito precisas estatísticas de utilização da CPU. Definindo reservado armazenamento para cada processador que registra seu thread ativo atual com base em eventos de alternância de contexto, DPC e ISR, um pode monitorar--fornecido qualquer carimbo de hora--o que cada CPU estava fazendo naquele momento e cujo código estava sendo executado. No método de simulação de máquina de estado, quando ocorre uma alternância de contexto, um objeto de CPU é atualizado com a nova identificação de thread e portanto, é o objeto para o antigo segmento com o uso da CPU até a opção. Da mesma forma, eventos DPC e ISR são atribuídos aos componentes de modo kernel correspondente, se necessário.

Em determinados casos, como com eventos de E/S, memória ou chamada de sistema, ETW não registrar o processo ou thread identificações no cabeçalho do evento, principalmente para reduzir a sobrecarga de eventos muito freqüentes. Para esses eventos, os valores de identificadores de thread e processo no cabeçalho mostram como 0xFFFFFFFF (= 4294967295). Se os eventos de alternância de contexto, DPC e ISR são controlados conforme descrito acima, os eventos poderão ser rastreados para o componente thread ou modo de kernel examinando o objeto de CPU para o thread em execução no momento ou DPC/ISR.

Eventos de memória

Eventos de memória indicam operações de Gerenciador (MM) de memória. O Windows oferece falha de página eventos, eventos de disco rígido falha de página e eventos de memória virtual. Eventos de memória tendem a ser muito freqüente, especialmente em um sistema ocupado.

Uma falha de página ocorre quando uma entrada de tabela de página apontada-out é inválida. Se a página solicitada precisa ser colocado disco, ela é chamada uma falha de página (uma operação muito cara) e todos os outros tipos são considerados falhas de página flexível (uma operação menos cara). Uma carga do evento de falha de página contém o endereço de memória virtual para que ocorreu uma falha de página e o ponteiro de instrução que deixá-lo. Uma falha de página rígido requer acesso de disco para ocorrer, que pode ser o primeiro acesso ao conteúdo em um arquivo ou acessos aos blocos de memória que foram paginados check-out. Habilitar eventos de falha de página faz com que uma falha de disco rígido página devem ser registrados como uma falha de página com um tipo de disco rígido falha de página. No entanto, uma falha de disco rígida normalmente tem um impacto consideravelmente maior sobre o desempenho, portanto, um evento separado está disponível apenas para uma falha de disco rígida que pode ser habilitada independentemente. Uma carga de evento de falha de disco tem mais dados, como chave, deslocamento e thread ID do arquivo, em comparação com um evento de falha de página.

Eventos de memória virtual consistem em tipos de alocação de memória virtual e memória virtual livre e correspondem às MM chamadas para alocar e sem intervalos de memória virtual. Sua carga contém o ID de processo, endereço base, tamanho solicitado e os sinalizadores usados na chamada API. Eventos de memória virtual recém-adicionados para o Windows 7 e são úteis para rastrear chamadas perdidas para a função VirtualAlloc e o uso excessivo de memória virtual por aplicativos.

Cabeçalhos de eventos de memória não contêm as identificações de threads e processos que causou atividades específicas. No entanto, a carga do evento de falha de página, tem a identificação de segmento do thread causando a falha. Isso permite a correlação de falha de página eventos para segmentos e processos por meio da máquina de estado. A carga do evento de memória virtual contém a identificação do processo para o qual foram realizadas operações de memória virtual. Para controlá-la ao thread de chamada de API, você precisa a alternância de contexto estatísticas, descrito na seção anterior.

Da próxima vez

Windows 7 recursos centenas de provedores de evento de vários componentes. Na primeira parte desta série de artigo de duas partes, nós ter apresentado alguns dos principais ETW OS eventos disponíveis no Windows 7 e as técnicas de análise que usamos por muitos anos. Eventos individuais indicarem determinadas atividades na principal do sistema operacional, mas se combinada com métodos de análise contextual, podem ser usadas para produzir relatórios significativos que fornecem informações sobre padrões e anomalias no uso de recursos. Na parte 2, pretendemos abordar outros principais eventos ETW OS bem como scripts simples presentes para demonstrar algumas técnicas básicas de estatísticas em alguns dos eventos de sistema operacional introduzidos nessas duas partes. Esperamos que muitas pessoas serão aproveitar o conteúdo apresentado aqui e que levará para a promoção de prática de engenharia de som maior qualidade do software e melhores experiências de usuário.

Dr. Parque insung *é um gerente de desenvolvimento para o WMI e a equipe de plataforma de diagnóstico. Ele publicou uma dúzia papers sobre análise de desempenho, solicitação de controle, instrumentação tecnologia e programação metodologia e suporte. Seu endereço de email é de insungp@microsoft.com.
Alex Bendetov *é um líder de desenvolvimento para o WMI e a equipe de plataforma de diagnóstico. Ele funciona no rastreamento de eventos do Windows e as tecnologias de contador de desempenho. Ele pode ser contatado pelo alexbe@microsoft.com.