Administração do Windows

Dentro do kernel do Windows Vista: parte 2

Mark Russinovich

Visão geral:

• Gerenciamento de memória
• Inicialização e desligamento
• Gerenciamento de energia

No mês passado, na primeira edição desta série de três partes, fiz uma análise dos aprimoramentos do kernel do Windows Vista nas áreas de processos e E/S.

Desta vez, abordarei os avanços na forma como o Windows Vista gerencia a memória, além dos principais melhoramentos na inicialização, desligamento e gerenciamento de energia do sistema (Parte 1).

Cada versão do Windows® apresenta avanços na escalabilidade e no desempenho, e o Windows Vista™ não foge à regra. O Gerenciador de Memória do Windows Vista inclui vários aprimoramentos, como o uso mais extensivo de técnicas de sincronização sem bloqueio, bloqueio mais refinado, empacotamento mais rigoroso da estrutura de dados, maior E/Ss de paginação, suporte às modernas arquiteturas de memória GPU e o uso mais eficiente do TLB (buffer de conversão à parte) de hardware. Além disso, o gerenciamento de memória do Windows Vista oferece agora alocação de espaço de endereço dinâmico para os requisitos de diferentes cargas de trabalho.

Quatro recursos de aprimoramento de desempenho que usam novas tecnologias estão estreando no sistema operacional com o Windows Vista: SuperFetch, ReadyBoost, ReadyBoot e ReadyDrive. Eles serão abordados detalhadamente mais adiante, neste artigo.

Espaço de endereço de kernel dinâmico

O Windows e os aplicativos executados nele tiveram muita dor de cabeça com os limites de espaço de endereço dos processadores de 32 bits. Por padrão, o kernel do Windows fica restrito a 2GB ou à metade do espaço de endereço virtual total de 32 bits, sendo a outra metade reservada para uso do processo cujo thread está em execução na CPU. Dentro de sua metade, o kernel precisa mapear a si mesmo, os drivers de dispositivos, o cache o sistema de arquivos, as pilhas do kernel, as estruturas de dados de códigos por sessão, além dos buffers pagináveis e não pagináveis (memória física bloqueada) alocados por drivers de dispositivos. Antes do Windows Vista, o Gerenciador de Memória determinava, no momento da inicialização, quanto do espaço de endereço deveria ser atribuído a cada fim, mas às vezes esta inflexibilidade levava a situações nas quais uma das regiões ficava cheia, enquanto outras tinham bastante espaço disponível. A exaustão de uma área pode levar a falhas de aplicativos e impedir que drivers de dispositivos concluam operações de E/S.

No Windows Vista de 32 bits, o Gerenciador de Memória gerencia o espaço de endereço do kernel dinamicamente, alocando e desalocando o espaço para diversos usos, conforme a demanda da carga de trabalho. Assim, a quantidade de memória virtual usada para armazenar buffers pagináveis pode aumentar quando drivers de dispositivos solicitam mais e diminuir, quando liberada pelos drivers. Assim, o Windows Vista poderá tratar uma variedade mais ampla de cargas de trabalho e, da mesma forma, a versão de 32 bits do próximo Windows Server®, cujo codinome é "Longhorn", será dimensionada para tratar mais usuários simultâneos do Terminal Server.

Obviamente, nos sistemas Windows Vista de 64 bits, atualmente as restrições de espaço de endereço não representam uma limitação prática e, portanto, não exigem qualquer tratamento especial, pois estão configuradas em seu máximo.

Prioridades de memória

Da mesma forma que o Windows Vista adiciona prioridades de E/S (conforme discutido na última edição), ele também implementa prioridades de memória. Para entender como o Windows usa as prioridades de memória, é necessário saber como o Gerenciador de Memória implementa seu cache de memória, chamado de Lista de Espera. Em todas as versões do Windows anteriores ao Windows Vista, quando uma página física (que geralmente tem 4KB de tamanho) de propriedade de um processo era recuperada pelo sistema, normalmente o Gerenciador de Memória a colocava no final da Lista de Espera. Se o processo quisesse acessá-la novamente, o Gerenciador de Memória pegava a página da Lista de Espera e ela era reatribuída ao processo. Quando um processo queria usar uma nova página de memória física e não havia memória livre disponível, o Gerenciador de Memória fornecia a página à frente de Lista de Espera. Basicamente, este esquema tratava igualmente todas as páginas em espera, usando apenas a hora em que foram colocadas na lista para classificá-las.

No Windows Vista, cada página de memória possui uma prioridade entre 0 e 7; dessa forma, o Gerenciador de Memória divide a Lista de Espera em oito listas que armazenam as páginas de cada prioridade. Quando o Gerenciador de Memória precisa pegar uma página da Lista de Espera, ele utiliza primeiro as páginas das listas de baixa prioridade. Geralmente, a prioridade de uma página reflete a prioridade do thread que gerou sua primeira alocação. (Se a página for compartilhada, ela refletirá as prioridades de memória mais altas dos threads do compartilhamento.) Um thread herda seu valor de prioridade de página do processo ao qual pertence. De forma especulativa, o Gerenciador de Memória usa prioridades baixas para as páginas que lê do disco ao antecipar os acessos de memória de um processo.

Por padrão, os processos possuem um valor de prioridade de página 5, mas as funções permitem que os aplicativos e o sistema alterem os valores de prioridade de página de threads e de processos. Só se percebe o real poder das prioridades de memória quando as prioridades relativas das páginas são entendidas no nível mais abrangente, que é a função do SuperFetch.

SuperFetch

Uma mudança significativa do Gerenciador de Memória se encontra na maneira como ele gerencia a memória física. O gerenciamento da Lista de Espera usado pelas versões anteriores do Windows possui duas limitações. Primeiro, a priorização de páginas depende apenas do comportamento pretérito recente dos processos e não antecipa seus requisitos futuros de memória. Segundo, os dados usados para a priorização se limitam à lista de páginas de propriedade de um processo em qualquer determinado momento. Essas limitações podem resultar em cenários como a "síndrome pós-almoço", quando você deixa seu computador por algum tempo e um aplicativo do sistema que utiliza a memória intensamente é executado (como uma verificação antivírus ou desfragmentação de disco). Esse aplicativo força a substituição do código e dos dados que seus aplicativos ativos armazenaram em cache na memória pelas atividades com intensa utilização de memória. Ao retornar, o desempenho é lento, pois os aplicativos precisam solicitar seus dados e códigos do disco.

O Windows XP introduziu o suporte à pré-busca, que melhorou o desempenho do início de aplicativos e de inicialização, executando grandes E/Ss de disco para pré-carregar a memória com o código e os dados do sistema de arquivos esperados, com base nas inicializações e inícios de aplicativos anteriores. O Windows Vista dá um grande passo com o SuperFetch, um esquema de gerenciamento de memória que aprimora a abordagem acessada menos recentemente com informações históricas e gerenciamento proativo de memória.

O SuperFetch é implementado em %SystemRoot%\System32\Sysmain.dll como um serviço do Windows executado dentro de um processo de Host de Serviço (%SystemRoot%\System32\Svchost.exe). O esquema depende do suporte do Gerenciador de Memória, de forma a poder recuperar os históricos de uso de páginas, além de direcionar o Gerenciador de Memória para pré-carregar dados e código de arquivos no disco ou de um arquivo de paginação na Lista de Espera e atribuir prioridades às páginas. Basicamente, o serviço SuperFetch estende o controle de páginas a dados e código que já estiveram na memória, mas que o Gerenciador de Memória reutilizou para criar espaço para novos dados e código. Ele armazena essas informações em arquivos de cenário com uma extensão .db no diretório %SystemRoot%\Prefetch, junto com os arquivos de pré-busca padrão usados para otimizar o início de aplicativos. Utilizando esse profundo conhecimento do uso da memória, o SuperFetch pode pré-carregar dados e código quando a memória física é disponibilizada.

Sempre que a memória fica livre, por exemplo, quando um aplicativo é encerrado ou libera memória, o SuperFetch solicita que o Gerenciador de Memória busque dados e código que foram removidos recentemente. Isso é feito na taxa de algumas páginas por segundo com E/Ss de prioridade muito baixa, de forma que o pré-carregamento não impacta o usuário ou outros aplicativos ativos. Portanto, se você abandonar o computador para almoçar e uma tarefa de segundo plano que utiliza muita memória fizer o código e os dados de seus aplicativos ativos serem removidos da memória durante sua ausência, freqüentemente o SuperFetch pode trazer tudo ou a maior parte deles de volta para a memória antes de você voltar. O SuperFetch também inclui suporte específico a cenários para hibernação, modo de espera, Troca Rápida de Usuário e início de aplicativos. Quando o sistema hiberna, por exemplo, o SuperFetch armazena dados e código no arquivo de hibernação que ele espera (com base nas hibernações anteriores) que seja acessado durante a continuação subseqüente. Por outro lado, quando você continua o Windows XP, os dados armazenados em cache anteriormente devem ser lidos novamente do disco ao serem referenciados.

Consulte a barra lateral "Observando o SuperFetch" para ver como o SuperFetch impacta a memória disponível.

Observando o SuperFetch

Depois de usar um sistema Windows Vista por algum tempo, você verá um valor pequeno no contador Memória Física Disponível na página Desempenho do Gerenciador de Tarefas. Isso se deve ao fato de o SuperFetch e o cache padrão do Windows usarem toda a memória física disponível para armazenar dados do disco em cache. Por exemplo, ao inicializar pela primeira vez, se você executar o Gerenciador de Tarefas imediatamente, deverá observar que o valor da Memória Disponível diminui conforme o valor da Memória em Cache aumenta. Ou, se você executar um programa que utiliza muita memória e sair dele (qualquer “otimizador de RAM” gratuito que aloca grandes quantidades de memória e depois a libera servirá) ou simplesmente copiar um arquivo muito grande, o valor de Disponível aumentará e o gráfico de Uso de Memória Física cairá conforme o sistema recupera a memória liberada. Contudo, ao longo do tempo o SuperFetch preenche novamente o cache com os dados que foram removidos da memória, então o valor de Em Cache aumentará e o valor de Disponível diminuirá.

Watching memory(Clique na imagem para aumentar a exibição)

ReadyBoost

A velocidade das CPUs e da memória estão ultrapassando rapidamente a dos discos rígidos; dessa forma, comumente os discos representam um afunilamento de desempenho do sistema. A E/S aleatória em disco é especialmente dispendiosa porque os tempos de busca do cabeçote do disco são da ordem de 10 milisegundos; uma eternidade para os processadores atuais de 3 GHz. A RAM é ideal para o armazenamento de dados de disco em cache, mas é relativamente cara. Entretanto, a memória flash é, em geral, mais barata e pode atender leituras aleatórias até 10 vezes mais rápido que um disco rígido normal. Portanto, o Windows Vista inclui um recurso chamado ReadyBoost para tirar proveito dos dispositivos de armazenamento de memória flash através da criação neles de uma camada de cache intermediária situada logicamente entre a memória e os discos.

O ReadyBoost consiste em um serviço implementado em %SystemRoot%\System32\Emdmgmt.dll, executado em um processo de Host de serviço e em um driver de filtro de volume, %SystemRoot%\System32\Drivers\Ecache.sys. (Emd é a abreviação de dispositivo de memória externa (External Memory Device), o nome de trabalho do ReadyBoost durante seu desenvolvimento.) Ao inserir um dispositivo flash, como uma chave USB, em um sistema, o serviço ReadyBoost examina o dispositivo para determinar suas características de desempenho e armazena os resultados de seu teste em HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Emdmgmt, como mostrado na Figura 1.

Figure 1** ReadyBoost device test results in the registry **(Clique na imagem para aumentar a exibição)

Se você ainda não usa um dispositivo para o armazenamento em cache e o novo dispositivo tiver entre 256 MB e 32 GB, uma taxa de transferência de 2,5 MB/s ou mais para leituras aleatórias de 4 KB e uma taxa de transferência de 1,75 MB/s ou mais para gravações aleatórias de 512 KB, o ReadyBoost perguntará se você deseja dedicar até 4 GB do armazenamento para o cache de disco. (Apesar de o ReadyBoost poder usar o NTFS, ele limita o tamanho máximo do cache a 4 GB para acomodar as limitações do FAT32.) Se você concordar, o serviço criará um arquivo de cache chamado ReadyBoost.sfcache na raiz do dispositivo e solicitará que o SuperFetch pré-preencha o cache em segundo plano.

Depois que o serviço ReadyBoost inicializa o cache, o driver do dispositivo Ecache.sys intercepta todas as leituras e gravações nos volumes do disco rígido local (por exemplo, C:\) e copia todos os dados que estão sendo gravados no arquivo de cache criado pelo serviço. O Ecache.sys compacta os dados e, normalmente, atinge uma taxa de compactação de 2:1, de forma que um arquivo de cache de 4 GB geralmente contém 8 GB de dados. O driver criptografa todos os blocos gravados usando a criptografia AES com uma chave de sessão por inicialização gerada aleatoriamente para garantir a privacidade dos dados no cache, caso o dispositivo seja removido do sistema.

Quando o ReadyBoost observa leituras aleatórias que podem ser satisfeitas a partir do cache, ele as atende de lá, mas como os discos rígidos possuem um acesso de leitura seqüencial melhor que a memória flash, ele permite que as leituras que fazem parte de padrões de acesso seqüencial vão diretamente para o disco, mesmo que os dados estejam no cache.

ReadyBoot

O Windows Vista usa a mesma pré-busca de tempo de inicialização que o Windows XP usava quando o sistema tinha menos de 512 MB de memória, mas se o sistema tiver 700 MB ou mais de RAM, será utilizado um cache na RAM para otimizar o processo de inicialização. O tamanho do cache depende da RAM total disponível, mas é suficientemente grande para criar um cache razoável e ainda disponibilizar ao sistema a memória necessária para inicializar tranquilamente.

Após cada inicialização, o serviço ReadyBoost (o mesmo serviço que implementa o recurso ReadyBoost que acabamos de descrever) usa o tempo ocioso da CPU para calcular um plano de armazenamento em cache de tempo de inicialização para a próxima inicialização. São analisadas as informações de rastreamento de arquivos das cinco inicializações anteriores e identificados os arquivos que foram acessados, além de sua localização no disco. Os rastreamentos processados são armazenados em %SystemRoot%\Prefetch\Readyboot como arquivos .fx e o plano de armazenamento em cache é salvo em HKLM\System\CurrentControlSet\Services\Ecache\Parameters, em valores REG_BINARY nomeados de acordo com os volumes de disco internos aos quais se referem.

O cache é implementado pelo mesmo driver de dispositivo que implementa o cache do ReadyBoost (Ecache.sys), mas seu preenchimento é direcionado pelo serviço ReadyBoost enquanto o sistema é inicializado. O cache de inicialização é compactado da mesma forma que o cache do ReadyBoost, mas uma outra diferença entre o gerenciamento de cache do ReadyBoost e do ReadyBoot é que, no modo ReadyBoot, além das atualizações do serviço ReadyBoost, o cache não é alterado para refletir os dados lidos ou gravados durante a inicialização. O serviço ReadyBoost exclui o cache 90 segundos após o começo da inicialização ou se outras demandas de memória o assegurarem, e registra as estatísticas do cache em HKLM\System\CurrentControlSet\Services\Ecache\Parameters\ReadyBootStats, como mostrado na Figura 2. Os testes de desempenho da Microsoft mostram que o ReadyBoot oferece avanços de desempenho aproximadamente 20 % acima da pré-busca herdada do Windows XP.

Figure 2** ReadyBoot Performance statistics **(Clique na imagem para aumentar a exibição)

ReadyDrive

O ReadyDrive é um recurso do Windows Vista que tira proveito das novas unidades de disco rígido híbridas, os chamados H-HDDs. O H-HDD consiste em um disco com memória flash não-volátil incorporada (também conhecida como NVRAM). Os H-HDDs típicos incluem entre 50MB e 512MB de cache, mas o limite de cache do Windows Vista é de 2TB.

O Windows Vista usa comandos ATA-8 para definir os dados do disco a serem mantidos na memória flash. Por exemplo, o Windows Vista gravará os dados de inicialização no cache ao desligar o sistema, permitindo um reinício mais rápido. Ele também armazena partes dos dados do arquivo de hibernação em cache quando o sistema hiberna, de forma que a continuação subseqüente seja mais rápida. Como o cache fica habilitado mesmo quando o disco não está girando, o Windows pode usar a memória flash como um cache de gravação em disco, evitando acelerar o disco quando o sistema está sendo executado com bateria. Manter o eixo do disco desativado economiza bastante energia consumida pela unidade de disco em uso normal.

Banco de dados de configuração de inicialização

O Windows Vista possui vários aspectos avançados de inicialização e desligamento. A inicialização foi melhorada com a introdução do Banco de Dados de Configuração de Inicialização (BCD) para armazenar a configuração de início do sistema operacional e do sistema, um novo fluxo e organização dos processos de inicialização do sistema, uma nova arquitetura de logon e suporte para serviços de início automático atrasado. As alterações do desligamento do Windows Vista incluem uma notificação pré-desligamento para serviços do Windows, o pedido de desligamento de serviços do Windows e uma mudança significativa na forma como o sistema operacional gerencia as transições de estado de energia.

Uma das alterações mais visíveis do processo de inicialização é a ausência do Boot.ini na raiz do volume do sistema. A configuração da inicialização, que nas versões anteriores do Windows ficava armazenada no arquivo de texto Boot.ini, agora é armazenada no BCD. Um dos motivos para o Windows Vista usar o BCD é que ele unifica as duas arquiteturas de atualização atuais com suporte do Windows: o MBR (registro mestre de inicialização) e a EFI (Extensible Firmware Interface). Em geral, o MBR é usado por sistemas desktop x86 e x64, enquanto a EFI é usada por sistemas baseados em Itanium (apesar de que, provavelmente, os computadores desktop serão fornecidos com suporte a EFI em breve). O BCD abstrai o firmware e possui outras vantagens sobre o Boot.ini, como o suporte para cadeias de caracteres Unicode e executáveis pré-inicialização alternativos.

Na realidade, o BCD é armazenado em disco em um hive do Registro que é carregado no Registro do Windows para acesso através de APIs do Registro. Em PCs, o Windows o armazena em \Boot\Bcd no volume do sistema. Em sistemas EFI, ele fica na partição do sistema EFI. Quando o hive é carregado, ele aparece sob HKLM\Bcd00000000, mas seu formato interno não é documentado, de forma que a edição exige o uso de uma ferramenta como %SystemRoot%\System32\Bcdedit.exe. As interfaces para manipular o BCD também são disponibilizadas para scripts e editores personalizados por meio do WMI (Windows Management Instrumentation) e você pode usar o Utilitário de Configuração do Sistema Windows (%SystemRoot%\System32\Msconfig.exe) para editar ou adicionar parâmetros básicos, como opções de depuração do kernel.

O BCD divide as configurações de inicialização de toda a plataforma, como a seleção do sistema operacional padrão e o tempo limite do menu de inicialização, das configurações específicas do sistema operacional, como as opções e o caminho do carregador de inicialização do sistema operacional. Por exemplo, a Figura 3 mostra que, ao executar Bcdedit sem opções da linha de comando, são exibidas as configurações da plataforma na seção Gerenciador de Inicialização do Windows, na parte superior da saída, seguidas das configurações específicas do sistema operacional, na seção Carregador de Inicialização do Windows.

Figure 3** Settings displayed in BCDEdit **(Clique na imagem para aumentar a exibição)

Ao inicializar uma instalação do Windows Vista, este novo esquema divide as tarefas que foram tratadas pelo carregador do sistema operacional (Ntldr) em versões anteriores do Windows em dois executáveis diferentes: \BootMgr e %SystemRoot%\System32\Winload.exe. O Bootmgr lê o BCD e exibe o menu de inicialização do sistema operacional, enquanto o Winload.exe trata do carregamento do sistema operacional. Se você estiver executando uma inicialização simples, o Winload.exe carregara os drivers de dispositivos de inicialização e os arquivos principais do sistema operacional, incluindo o Ntoskrnl.exe, e transfere o controle para o sistema operacional; se o sistema estiver continuando a partir de uma hibernação, ele executará %SystemRoot%\System32\Winresume.exe para carregar os dados de hibernação na memória e continuar o sistema operacional.

O Bootmgr também inclui o suporte para executáveis pré-inicialização adicionais. O Windows Vista é fornecido com o Diagnóstico de Memória do Windows (\Boot\Memtest.exe) pré-configurado como uma opção para verificar a integridade da RAM, nas executáveis pré-inicialização de terceiros podem ser adicionados como opções que serão exibidas no menu de inicialização do Bootmgr.

Processos de inicialização

Nas versões anteriores do Windows, a relação entre vários processos do sistema não é intuitiva. Por exemplo, conforme o sistema é inicializado, o gerenciador de logon interativo (%SystemRoot%\System32\Winlogon.exe) inicia o serviço LSASS (Lsass.exe) e o Gerenciador de Controle de Serviços (Services.exe). Além disso, o Windows usa um contêiner de namespaces que chamou uma Sessão para isolar processos executados em sessões de logon diferentes. Mas, antes do Windows Vista, o usuário fazia logon na Sessão 0 compartilhada pelo console, a sessão usada por processos do sistema, o que criava possíveis problemas de segurança. Um desses problemas aparecia, por exemplo, quando um serviço do Windows mal escrito executado na Sessão 0 exibia uma interface do usuário no console interativo, permitindo que malwares invadissem a janela por meio de técnicas como as de ataque shatter e pudessem obter privilégios administrativos.

Para resolver esses problemas, a arquitetura de vários processos do sistema foi mudada no Windows Vista. O Gerenciador de Sessão (Smss.exe) é o primeiro processo no modo de usuário criado durante a inicialização, como nas versões anteriores do Windows, mas no Windows Vista ele inicia uma segunda instância de si mesmo para configurar a Sessão 0, que é dedicada unicamente a processos do sistema. O processo do Gerenciador de Sessão para a Sessão 0 inicia o Aplicativo de Inicialização do Windows (Wininit.exe), um processo de subsistema do Windows (Csrss.exe) para a Sessão 0 e, em seguida, sai. O Aplicativo de Inicialização do Windows continua, iniciando o Gerenciador de Controle de Serviços, o serviço LSASS e um novo processo, o Gerenciador de Sessão Local (Lsm.exe), que gerencia conexões do servidor de terminal com a máquina.

Quando um usuário faz logon no sistema, o Gerenciador de Sessão inicial cria uma nova instância de si mesmo para configurar a nova sessão. O novo processo Smss.exe inicia um processo de subsistema do Windows e o processo Winlogon para a nova sessão. O fato de o Gerenciador de Sessão principal usar cópias de si mesmo para inicializar novas sessões não oferece vantagens em um sistema cliente, mas nos sistemas Windows Server "Longhorn" que funcionam como servidores de terminal, várias cópias podem ser executadas simultaneamente para permitir o logon mais rápido de diversos usuários.

Com esta nova arquitetura, os processos do sistema, incluindo os serviços do Windows, são isolados na Sessão 0. Se um serviço do Windows executado na Sessão 0 exibe uma interface do usuário, o serviço Detecção de Serviços Interativa (%SystemRoot%\System32\UI0Detect.exe) notifica os administradores conectados, iniciando uma instância de si mesmo no contexto de segurança do usuário e exibindo a mensagem mostrada na Figura 4. Se o usuário selecionar o botão "Exibir esta mensagem", o serviço alternará a área de trabalho para a área de trabalho do serviço do Windows, onde pode interagir com a interface do usuário do serviço e, em seguida, voltar para sua própria área de trabalho. Para saber mais sobre o que acontece na inicialização, consulte a barra lateral "Exibindo Relações de Processos de Inicialização".

Figure 4** Service has displayed a window **(Clique na imagem para aumentar a exibição)

Exibindo Relações de Processos de Inicialização

Você pode usar o Process Explorer da Sysinternals (microsoft.com/technet/sysinternals) para ver a árvore de inicialização de processos do Windows Vista.

A captura de tela inclui a coluna Sessão, que pode ser adicionada por meio da caixa de diálogo da coluna do Process Explorer. O processo realçado é o Smss.exe inicial. Abaixo dele estão o Csrss.exe e o Wininit.exe da Sessão 0, que são justificados à esquerda porque seu processo pai, a instância do Smss.exe que configurou a Sessão 0, saiu. A árvore filha do Wininit consiste em Services.exe, Lsass.exe e Lsm.exe.

O Process Explorer identifica um conjunto de processos como sendo executados na Sessão 1, sendo essa a sessão na qual fiz logon por meio da conexão da Área de Trabalho Remota. O Process Explorer exibe os processos executados na mesma conta que ele realçados em azul. Finalmente, a Sessão 2 foi inicializada para preparar o logon de um usuário no console e a criação de uma nova sessão de logon. O Winlogon é executado nessa sessão, usando LogonUI para solicitar que o novo usuário do console “Pressione Ctrl+Alt+DELETE para Fazer Logon”, e nela o Logonui.exe solicitará as credenciais do usuário.

Startup process and session information(Clique na imagem para aumentar a exibição)

Provedores de Credenciais

Até mesmo a arquitetura de logon foi alterada no Windows Vista. Nas versões anteriores do Windows, o processo Winlogon carregava a DLL GINA (Graphical Identification and Authentication) especificada no Registro para exibir uma interface do usuário de logon que solicitava as credenciais do usuário. Infelizmente, o modelo GINA possui várias limitações, inclusive o fato de apenas uma GINA poder ser configurada, a criação de uma GINA completa ser difícil para terceiros e as GINAs personalizadas que possuem interfaces do usuário diferentes do padrão mudarem a experiência do usuário do Windows.

Em vez de uma GINA, o Windows Vista usa a nova arquitetura de Provedor de Credenciais. O Winlogon inicia um processo separado, o Host da Interface do Usuário de Logon (Logonui.exe), que carrega os provedores de credenciais configurados em HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Authentication\Credential Providers. O Logonui pode hospedar vários provedores de credenciais simultaneamente; na verdade, o Windows Vista é fornecido com provedores interativos (Authui.dll) e de cartão inteligente (Smart-cardcredentialprovider.dll). Para assegurar uma experiência do usuário uniforme, o LogonUI gerencia a interface do usuário exibida para usuários finais, mas também permite que os provedores de credenciais especifiquem elementos personalizados como texto, ícones e editem controles.

Serviços de Início Automático Atrasado

Se você já fez logon em um sistema Windows logo após ele ser iniciado, provavelmente já passou por atrasos antes de sua área de trabalho ser totalmente configurada e você poder interagir com o shell e os aplicativos que iniciar. Enquanto você faz logon, o Gerenciador de Controle de Serviços inicia os vários serviços do Windows que são configurados como serviços de início automático e, portanto, são ativados no momento da inicialização. Muitos serviços executam inicializações com um alto consumo de CPU e disco, e que concorrem com suas atividades de logon. Para acomodar isso, o Windows Vista introduz um novo tipo de início de serviço chamado início automático atrasado, que os serviços podem usar se não precisarem estar ativos imediatamente após a inicialização do Windows.

O Gerenciador de Controle de Serviços inicia os serviços configurados para início automático atrasado depois que os serviços de início automático tiverem terminado de iniciar e define a prioridade do thread inicial como THREAD_PRIORITY_LOWEST. Esse nível de prioridade faz todas as E/Ss do disco executadas pelo thread terem uma prioridade de E/S Muito Baixa. Depois que a inicialização de um serviço é concluída, o Gerenciador de Controle de Serviços define sua prioridade como normal. A combinação de início atrasado, baixa prioridade de CPU e memória, e prioridade de disco em segundo plano reduz bastante a interferência com o logon de um usuário. Vários serviços do Windows, incluindo a Transferência Inteligente em Segundo Plano, o Cliente do Windows Update e o Windows Media® Center, usam o novo tipo de início para ajudar a melhorar o desempenho dos logons após uma inicialização.

Desligamento

Um problema que infernizou os criadores de serviços do Windows é que, durante o encerramento do Windows, eles têm, por padrão, um máximo de vinte segundos para executar a limpeza. As versões do Windows anteriores ao Windows Vista não davam suporte a um encerramento limpo, que aguardasse a saída de todos os serviços, porque um serviço com bugs pode manter um encerramento indefinidamente. Alguns serviços, como os que possuem operações de desligamento relacionadas à rede ou que possuem grandes quantidades de dados em disco, podem exigir mais tempo; assim, o Windows Vista permite que um serviço solicite a notificação pré-desligamento.

Quando o Windows Vista é desligado, o Gerenciador de Controle de Serviços notifica primeiro os serviços que solicitaram a notificação pré-desligamento. Ele aguardará indefinidamente que esses serviços saiam, mas se eles tiverem um bug e não responderem às consultas, o Gerenciador de Controle de Serviços desistirá e continuará após três minutos. Uma vez que todos os serviços tenham saído ou que o tempo limite tenha expirado, o Gerenciador de Controle de Serviços continuará com o desligamento do restante dos serviços no estilo herdado. Os serviços de Diretiva de Grupo e Windows Update registram as notificações pré-desligamento em uma nova instalação do Windows Vista.

Os serviços de Diretiva de Grupo e Windows Update também usam um outro recurso de serviços do Windows Vista: o pedido de desligamento. Os serviços sempre puderam especificar dependências de inicialização que o Gerenciador de Controle de Serviços segue para iniciar os serviços em uma ordem que os satisfaça, mas antes do Windows Vista eles não podiam especificar as dependências de desligamento. Agora, os serviços registrados para notificação pré-desligamento também podem se inserir na lista armazenada em HKLM\System\CurrentControlSet\Control\PreshutdownOrder e o Gerenciador de Controle de Serviços os desligará de acordo com seu pedido. Consulte a barra lateral "Identificando um Serviço de Pré-Desligamento e Início Automático Atrasado" para saber mais sobre esses serviços.

Gerenciamento de Energia

A suspensão e a hibernação são outras formas de desligamento, e os bugs no gerenciamento de energia em drivers e aplicativos foram motivo de grandes batalhas desde que o Windows 2000 introduziu o gerenciamento de energia na linha de sistemas operacionais Windows baseados no Windows NT®. Vários usuários esperavam que os sistemas de seus laptops fossem suspensos ou hibernassem ao fechar a tampa antes de embarcar em uma viagem e chegavam ao seu destino com uma maleta aquecida, uma bateria descarregada e dados perdidos. Isso porque o Windows sempre pediu o consentimento dos drivers de dispositivos e aplicativos para alterar o estado de energia e um único driver ou aplicativo sem resposta poderia impedir a transição.

No Windows Vista, o Gerenciador de Energia do kernel informa os drivers e aplicativos sobre as alterações no estado de energia, de modo que eles possam se preparar, mas não mais pede sua permissão. Além disso, o Gerenciador de Energia espera que os aplicativos respondam às notificações de alteração por no máximo 20 segundos, em vez dos dois minutos aguardados nas versões anteriores do Windows. Como resultado, os usuários do Windows Vista podem confiar mais no cumprimento das hibernações e suspensões pelos seus sistemas.

A seguir

Como mencionado anteriormente, esta é a segunda edição em uma série de três partes. A primeira parte abordou os aprimoramentos do kernel do Windows Vista nas áreas de processos e E/S. Desta vez, examinei os avanços do Windows Vista no gerenciamento de memória, inicialização e desligamento. Da próxima vez, concluirei a série descrevendo as alterações do kernel nas áreas de confiabilidade e segurança.

Identificando um Serviço de Pré-Desligamento e Início Automático Atrasado

O comando interno SC é atualizado no Windows Vista para mostrar os serviços configurados como serviços de início automático atrasado:

Using SC to display start type(Clique na imagem para aumentar a exibição)

Infelizmente, o comando SC não relata os serviços que solicitaram notificação pré-desligamento, mas você pode usar o utilitário PsService da Sysinternals para ver se um serviço aceita a notificação pré-desligamento:

Viewing pre-shutdown status(Clique na imagem para aumentar a exibição)

Mark Russinovich é um colega da área técnica da Microsoft na divisão de plataforma e serviços. Ele é co-autor do livro Microsoft Windows Internals (Microsoft Press, 2004) e palestrante assíduo em conferências de desenvolvedores e TI. Russinovich uniu-se à Microsoft com a recente aquisição da empresa de que foi co-fundador, a Winternals Software. Ele também criou a Sysinternals, onde publicou os utilitários Process Explorer, Filemon e Regmon.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..