[Arquivo de boletins informativos ^] <[ Volume 1, Número 1] [Volume 1, Número 3 >]
The Systems Internals Newsletter Volume 1, Número 2
15 de maio de 1999 - Nesta edição:
O QUE HÁ DE NOVO NA SYSTEMS INTERNALS
- SDelete
- BlueScreen Screen Saver Win2K Atualização
- "Linux e a Empresa"
- "Por dentro dos utilitários NT"
- Minha coluna de maio do Windows NT Magazine
- Coisas não tão novas
NOTÍCIAS INTERNAS
- As más maneiras de cabeceira do Dr. GUI
- WinDev '99 Leste
- Numega Driver Works Lançamento Iminente
- Beta 3 DDK Lançado
- Spinlocks em fila Win2K
O QUE VEM POR AÍ
- Protetor de arquivos do sistema Win2K (SFP)
PATROCINADOR: WINTERNALS SOFTWARE
A Newsletter Systems Internals é patrocinada pela Winternals Software, na Web em http://www.winternals.com. A Winternals Software é a principal desenvolvedora e fornecedora de ferramentas de sistemas avançados para Windows NT/2K. Os produtos Winternals Software incluem FAT32 para Windows NT 4.0, ERD Commander (capacidade de disco de inicialização para Windows NT) e NTRecover.
Olá a todos,
Bem-vindo à segunda edição da newsletter Systems Internals. A newsletter conta atualmente com 2700 subscritores, com as subscrições a manterem-se fortes.
Desde a última newsletter a Microsoft lançou oficialmente o Windows 2000 Beta 3. O número de compilação do kernel Beta 3 é 2031, enquanto o do kernel de lançamento inicial do NT 4.0 era 1381 e o NT 3.51 tinha um número de compilação de 1025. . O que eu acho estranho (e um pouco chato), é que a Microsoft incrementa o número de compilação cada vez que eles fazem uma compilação completa do sistema operacional (todos os dias úteis), no entanto, o número de compilação relatado do kernel reflete o de seu lançamento público inicial. Por exemplo, mesmo que o número de compilação real do kernel NT 4.0 Service Pack 5 seja muito maior do que 1381, o kernel ainda relata 1381 como o número de compilação.
A versão Beta 3 do Windows 2000 pretende ser um alerta para a comunidade de desenvolvedores. A Microsoft anunciou que lançará o Windows 2000 em outubro, e que o Beta 3 representa a versão completa do que será lançado, para que os desenvolvedores possam começar a escrever novos produtos sem medo de que as coisas mudem por baixo deles.
O Windows 2000 vem com uma série de novas APIs, serviços em camadas e aprimoramentos do kernel. Uma mudança que será especialmente visível para os desenvolvedores de drivers de dispositivo é que a Tela Azul da Morte (BSOD) mudou. Em versões anteriores do NT, o BSOD exibia informações de tempo de link e endereço de carga para todos os drivers em um sistema, bem como um despejo da pilha como existe no momento do acidente. No Windows 2000, apenas o código de parada e a(s) linha(s) de endereço associada(s) (linhas de endereço convertem um ou mais dos parâmetros de código de parada em locais dentro de drivers de dispositivo) são mostrados, juntamente com uma mensagem detalhada. A mensagem de suporte sugere que você verifique as configurações do BIOS e do disco rígido e desative o software de desfragmentação e os scanners de vírus para tentar evitar a falha novamente. O Microsoft Premier Support Services (PSS) determinou, com base em sua experiência e nos comentários dos clientes, que o BSOD no estilo NT 4 não é útil para determinar a causa de uma falha.
Eu pessoalmente achei a lista de drivers carregados, e em particular o despejo de pilha, para ser útil ao obter relatórios de bugs de driver de usuários, é muito mais fácil e rápido obter essas informações do que ter usuários para enviar um despejo de falha de vários megabytes. Muitas vezes isolei a causa da falha com base no despejo de pilha e verifiquei as versões do driver que os usuários carregaram com base nas informações de versão exibidas na lista de drivers. Estou curioso para saber o que você pensa: você gostaria de ver o BSOD estilo NT 4 levado adiante para o Windows 2000, ou o novo formato BSOD é suficiente? Envie-me um e-mail se você tiver uma opinião. Relatarei os resultados desta sondagem informal na próxima newsletter. Enquanto eu estou no assunto de BSODs, certifique-se de verificar a atualização do Windows 2000 do sempre popular Systems Internals BlueScreen Screen Saver, que é abordado nesta edição.
Obrigado!
-Marcar
O QUE HÁ DE NOVO NA SYSTEMS INTERNALS
SDELETE
Como parte do Windows NT 4.0 cumprindo os requisitos de classificação de segurança C2, ele implementa "proteção de reutilização de objeto". Isso significa que o NT zera os recursos de arquivo e memória que os aplicativos alocam quando os aplicativos acessam os recursos pela primeira vez. Isso impede que um aplicativo, por exemplo, crie um arquivo grande e examine seu conteúdo para ver o que foi armazenado anteriormente no disco. No entanto, a proteção de reutilização de objeto não se estende à proteção de recursos acessíveis por aplicativos que ignoram APIs padrão relacionadas a recursos ou que ignoram completamente o sistema operacional. Por exemplo, você pode usar um editor de disco, como o DiskProbe do Resource Kit, para examinar o conteúdo de partes não alocadas de um disco. Isso permite que você veja dados que anteriormente pertenciam a arquivos excluídos.
Muitos ambientes exigem um recurso de "exclusão segura". Esse recurso permite que os usuários excluam permanentemente dados confidenciais para que não sejam visíveis por ferramentas que ignoram os recursos de proteção do sistema operacional. O advento do Sistema de Arquivos com Criptografia (EFS) destacou a necessidade de um recurso de exclusão segura no Windows 2000. Quando você criptografa um arquivo não criptografado anteriormente, o EFS não apaga o conteúdo das alocações de disco que continham os dados não criptografados do arquivo quando libera as alocações de disco. Assim, mesmo que a versão ativa de um arquivo que você criptografa seja segura, a versão antiga do arquivo ainda existe nas partes não alocadas de um disco até que ele seja substituído por novos dados de arquivo que o NTFS atribui a essas partes.
Para preencher este buraco, escrevi SDelete (Secure Delete). É uma ferramenta de linha de comando que torna possível não apenas excluir arquivos padrão com segurança, mas também excluir com segurança quaisquer dados excluídos anteriormente que existam nas partes não alocadas de um disco. Além disso, ele funciona com arquivos compactados, criptografados e esparsos do Windows NT/2000, algo que requer o uso da API de desfragmentação. SDelete adere ao padrão de limpeza e higienização do Departamento de Defesa DOD 5220.22-M, para que você possa ter certeza de que, uma vez que você excluir dados, desapareceu para sempre.
Eu forneço ao SDelete o código-fonte completo e uma descrição de como ele funciona, para que você possa ver como ele faz uso da API de desfragmentação e para que você possa verificar minhas alegações de que ele impedirá que seus dados excluídos confidenciais sejam recuperáveis.
Você pode encontrar documentação sobre a API de desfragmentação do Windows NT/2000 em http://www.sysinternals.com/defrag.htm. Faça o download do SDelete com o código-fonte completo em http://www.sysinternals.com/sdelete.htm.
BLUESCREEN SCREEN SAVER WIN2K ATUALIZAÇÃO
As alterações que a Microsoft fez na tela de inicialização do NT e no layout BSOD (Blue Screen of Death) no Windows 2000 fizeram com que o Systems Internals BlueScreen Screen Saver exigisse uma grande atualização. A fim de continuar a fornecer-lhe o máximo em realismo BSOD, eu lancei a versão 2.0 do protetor de tela. Ele não só reflete as mudanças no formato BSOD, mas também imita precisamente a tela de inicialização do Windows 2000, completa com faixas de progresso rotativas e atualizações da barra de progresso. É tão real que o protetor de tela vai enganar até mesmo os usuários e desenvolvedores especialistas do Windows 2000. Claro, sob NT 4.0 BlueScreen Screen Saver ainda apresenta o NT 4.0 BSOD e telas de inicialização.
Como recriei a tela de inicialização do Windows 2000 tão perfeitamente e, ao mesmo tempo, não violei as leis de direitos autorais? Eu não incluo os gráficos de bitmap de inicialização do Windows 2000 com a proteção de tela. Em vez disso, uso o DirectX para alternar o modo gráfico para o mesmo usado pelo Windows 2000 durante a sequência de inicialização e, em seguida, faço referência aos recursos de bitmap do arquivo do kernel do Windows 200, ntoskrnl.exe. Esses recursos (você pode visualizá-los abrindo os recursos do ntoskrnl.exe no Visual Studio) são aqueles que o kernel exibe, o que é uma mudança em relação à maneira do Windows 9x de fazer as coisas, onde os gráficos de inicialização são, na verdade, arquivos separados. Não parece que os OEMs de computador terão a oportunidade de personalizar a experiência de inicialização no Windows 2000...
Você pode baixar o protetor de tela BlueScreen em http://www.sysinternals.com/bluescreen.htm. Se você tem uma história bem-humorada relacionada a enganar alguém com o protetor de tela, por favor, passe-a adiante.
Você pode encontrar mais informações sobre como e por que dos BSODs na minha coluna NT Magazine NT Internals de dezembro de 1997, "Inside the Blue Screen". Um link na página Systems Internals Publications, http://www.sysinternals.com/publ.htm, irá levá-lo para a versão on-line dessa coluna. A página também contém links para outras apresentações on-line de artigos e colunas de minha autoria.
"LINUX E A EMPRESA"
A enorme resposta da comunidade Linux ao meu artigo na edição de abril da Windows NT Magazine sobre as deficiências de escalabilidade do kernel Linux levou a revista a postar a versão on-line do artigo antes do previsto. Você pode encontrar um link para o artigo, "Linux e a Empresa", na seção "Artigos" em http://www.sysinternals.com/publ.htm. O artigo descreve várias limitações da versão atual do kernel Linux (2.2x), incluindo a falta de um mecanismo eficiente de espera de eventos, serialização significativa de chamada de sistema, nenhuma E/S assíncrona e uma implementação ruim da API de soquete sendfile (no NT chamada TransmitFile). A combinação dessas limitações impede que o Linux compita frente a frente com o NT e outros UNIXs, em termos de desempenho, em aplicativos de classe empresarial, como servidores web, servidores de banco de dados e servidores de e-mail.
"DENTRO DA NT UTILITIES"
Se você usou Filemon, Regmon ou HandleEx, e queria saber mais sobre o que eles dizem e como eles são implementados, então você estará interessado na minha coluna de fevereiro do Windows NT Magazine, "Dentro dos utilitários NT". Esta coluna descreve os componentes internos dessas ferramentas e, para Regmon e Filemon, informa um pouco sobre os códigos de erro e tipos de solicitação que eles registram durante a captura da atividade do Registro ou do sistema de arquivos. Um link para a versão on-line deste artigo, que acaba de ser disponibilizada, está localizado em http://www.sysinternals.com/publ.htm.
MINHA COLUNA DE MAIO DA REVISTA WINDOWS NT
Você já se perguntou como o Windows NT/2000 organiza o conteúdo do Registro na memória ou no disco? A edição atual (maio) da Windows NT Magazine inclui minha coluna, "Dentro do Registro", que diz isso e muito mais. Por exemplo, saiba como o subsistema de modo kernel do Configuration Manager (o subsistema responsável por gerenciar o Registro) procura chaves, armazena dados de valor, otimiza a pesquisa e protege a integridade dos arquivos no disco do Registro. Windows NT Magazine, http://www.winntmag.com, está disponível em Borders e Barnes and Nobles.
COISAS NÃO TÃO NOVAS
Não muito tempo depois que o Windows 2000 Beta 2 foi lançado, eu peguei a compilação verificada (depuração) do arquivo de imagem do kernel (ntoskrnl.exe), fiz uma pesquisa de string no kernel e cheguei a uma lista dos nomes dos arquivos de origem usados para construir o kernel. A compilação Checked do kernel NT/2000 contém numerosas instruções Assert (verificações de consistência) que incluem o nome do arquivo no qual o Assert está localizado. Supondo que praticamente todos os arquivos de qualquer significado na fonte do kernel terão pelo menos um Assert nele, a lista é bastante abrangente. Despejar a lista em um script Java me deu uma boa visualização em árvore semelhante ao Explorer da estrutura de diretórios da árvore de código-fonte do Windows 2000. Confira em http://www.sysinternals.com/nt5src.htm.
NOTÍCIAS INTERNAS
DR. AS MÁS MANEIRAS DE GUI AO LADO DA CAMA
Na edição de março/abril do Microsoft Developer Network News Dr. GUI coloca uma pergunta de um leitor que pergunta como um driver pode afinitizar (forçar a usar uma CPU específica) seus threads. O Dr. GUI responde que não há como determinar o número de processadores em um sistema a partir de um driver e que um thread de driver não pode dizer em qual processador ele está sendo executado. Infelizmente, o Dr. GUI explodiu esse diagnóstico (talvez o Dr. GUI deva se ater às GUIs).
O kernel NT (ntoskrnl.exe) exporta uma variável chamada KeNumberProcessors que é definida em NTDDK. H como:
extern PCCHAR KeNumberProcessors;
Ele pode ser referenciado diretamente em um driver como este:
CHAR i;
for( i = 0; i < *KeNumberProcessors; i++ ) {
// do processor specific stuff
}
Para determinar em qual processador um thread de driver está sendo executado, use KeGetCurrentProcessorNumber(), outra exportação do kernel que não é definida apenas no NTDDK. H, mas na verdade está documentado no DDK!
Dr. GUI receitou a medicação errada para esta doença, então eu educadamente deixei o Dr. saber através de um e-mail educado. Surpreendentemente, o Dr. GUI nunca sequer reconheceu o e-mail. Vamos ver se o bom Dr. se sai à altura do erro na próxima edição...
WINDEV '99 LESTE
A edição de 1999 da Costa Leste da principal conferência para desenvolvedores do Windows está se aproximando rapidamente. WinDev '99 East está acontecendo de 14 a 18 de junho no Boston Cambridge Marriot. Vários grandes nomes do desenvolvimento do Windows estão falando, incluindo Jeff Richter, Jeff Prosise e Don Box. Eu estarei lá com Jamie Hanrahan e Brian Catlin na pista do driver do dispositivo. Minhas apresentações incluem um tutorial de um dia sobre internos do NT, bem como um sobre como escrever drivers de sistema de arquivos do Windows NT/2K e um sobre problemas avançados de desenvolvimento de driver de dispositivo. Venha e diga olá!
NUMEGA DRIVER WORKS LANÇAMENTO IMINENTE
Compuware NuMega Labs está prestes a lançar um novo e poderoso kit de desenvolvimento de driver de dispositivo Windows 9x/NT/2K, DriverStudio. O DriverStudio combina todas as ferramentas de driver de dispositivo existentes do NuMega, incluindo DriverAgent, DriverWorks, SoftICE e VtoolsD, e adiciona o novo BoundsChecker para drivers e FieldAgent (somente Windows NT/2K).
A versão do driver de dispositivo do BoundsChecker fornece monitoramento abrangente de cada API do kernel que seu driver usa, e você pode usá-lo para monitorar as interações do driver com qualquer outro driver de dispositivo no sistema. O FieldAgent permite implantar a versão do driver do BoundsChecker em sistemas cliente para que os clientes possam coletar rastreamentos para você que você possa analisar. Em breve como uma atualização gratuita para os clientes do DriverStudio estão o TrueTime para drivers e o TrueCoverage para drivers, ferramentas que permitem que você ajuste facilmente o desempenho e teste a cobertura de seus drivers de dispositivo.
Este pacote é o kit de desenvolvimento de driver final, e eu recomendo vivamente (estou no programa Beta). Saiba mais em http://www.numega.com.
BETA 3 DDK LANÇADO
Em conjunto com o lançamento do Windows 2000 Beta 3, a Microsoft disponibilizou para download gratuito o Windows 2000 Beta 3 DDK (Device Driver Kit). Você pode pegar o DDK em http://www.microsoft.com/ddk/ddk2kb3.htm. Espero que o SDK siga em breve, pois há várias APIs do Win32 na versão Beta 3 que não estão documentadas a partir da edição de abril do MSDN.
SPINLOCKS EM FILA WIN2K
O Windows 2000 usa um novo tipo de spinlock chamado "spinlock em fila" para seus bloqueios globais. Os bloqueios globais no Windows 2000 são os mesmos do Windows NT 4.0 e incluem:
KiDispatcherLock: o bloqueio do banco de dados do agendadorKiContext-SwapLock: o bloqueio de permuta do pisoMmPfnLock: o bloqueio do banco de dados de quadro de página físicoMmSystemSpaceLock: o bloqueio de espaço de endereçamento do modo kernelCcMasterSpinLock: o spinlock global do Gerenciador de CacheCcVacbSpinLock: o bloqueio da matriz de mapeamento do Gerenciador de Cache
Em um monoprocessador, os spinlocks em fila funcionam exatamente como os spinlocks normais. Na compilação multiprocessador do NT, no entanto, spinlocks enfileirados são significativamente diferentes. Como spinlocks padrão, spinlocks em fila são implementados no HAL. O kernel chama a função KeAcquireQueuedSpinlock HAL para adquirir um spinlock em fila e invoca KeReleaseQueuedSpinlock para liberar um spinlock em fila. KeAcquireSpinlock e KeReleaseSpinlock, as funções HAL que o kernel usa para adquirir e liberar spinlocks padrão, exigem o endereço do spinlock especificado como parâmetro. Por outro lado, as funções de spinlock em fila tomam o número de índice de um spinlock global. O kernel inicializa os spinlocks globais em uma matriz, onde cada spinlock tem um número de índice predefinido que o kernel usa para identificá-los para o HAL. Assim, spinlocks enfileirados não podem ser definidos e usados por drivers de dispositivo, uma vez que não há nenhuma maneira de aumentar a matriz global de spinlock em fila.
No Windows 2000, cada região de controle do processador (PCR) em um SMP (há um PCR para cada processador) tem uma matriz com tantas entradas quanto há spinlocks enfileirados. Cada entrada de matriz contém dois campos: um ponteiro para o spinlock enfileirado ao qual corresponde (o campo "spinlock") e o campo "fila". Na descrição a seguir, quando me refiro aos campos spinlock e queue, estou falando dos campos associados à entrada de matriz para o spinlock que está sendo adquirido ou lançado.
KeAcquireQueuedSpinlock funciona assim: a função tenta adquirir o spinlock usando a instrução da CPU de troca intertravada para colocar o endereço do PCR do processador atual no spinlock. Se o spinlock for mantido, a função tem, como parte da operação de troca, o endereço do PCR de outro processador. Em seguida, a função identifica-se como "esperando" alternando o bit baixo do campo spinlock em seu próprio PCR. Em seguida, ele coloca seu próprio endereço de PCR no campo de fila do PCR que recuperou do spinlock. Finalmente, ele espera em um loop ocupado até que o bit baixo seja alternado em seu campo spinlock quando o bit estiver desligado, então o processador atual recebeu o spinlock e assim ele retorna ao chamador da função de aquisição.
Depois que um processador adquire um spinlock em fila e termina o processamento que queria fazer enquanto segura o bloqueio, ele chama KeReleaseQueuedSpinlock. KeReleaseQueuedSpinlock examina o campo de fila para o spinlock especificado no PCR do processador atual. Se o campo de fila for diferente de zero, outro processador "enfileirou" seu PCR lá. KeReleaseQueuedSpinlock limpa o bit baixo do campo spinlock para o PCR em espera e, em seguida, limpa seu próprio campo de fila e retorna. Ao limpar o bit baixo no campo de spinlock do PCR em espera, ele acaba de sinalizar à próxima CPU na fila que pode ter o bloqueio. Se o campo de fila era zero, nenhum outro processador está esperando pelo bloqueio e KeReleaseQueuedSpinlock simplesmente executa uma operação de troca intertravada para limpar o spinlock global.
A operação de spinlocks em fila é aquela em que os processadores "se alinham" esperando por um spinlock que é mantido. Cada processador faz fila informando ao que está à sua frente na fila que está esperando. Isso fornece uma ordenação determinística para a aquisição de um spinlock em fila, os processadores adquirem o spinlock na ordem em que o solicitam. Para spinlocks padrão, não há esse pedido. Os spinlocks em fila têm outra vantagem mais significativa. À medida que um processador gira esperando que seu campo de spinlock tenha o bit baixo limpo, ele está girando na memória privada de seu próprio processador. Quando um processador ocupado espera por um spinlock padrão, ele gira no próprio spinlock global, que é compartilhado por todos os processadores. Assim, os spinlocks em fila têm melhores características de barramento multiprocessador porque não há acesso compartilhado à linha de cache durante a espera ocupada. Além disso, devido à natureza de enfileiramento de spinlocks em fila, normalmente há menos operações de bloqueio de barramento do que para spinlocks padrão quando um bloqueio está sob contenção de vários processadores.
Os spinlocks em fila são um dos vários aprimoramentos que a Microsoft fez na escalabilidade de multiprocessamento do Windows 2000.
O QUE VEM POR AÍ
O Windows 2000 inclui vários recursos que o tornam mais resiliente a erros do operador e aplicativos mal comportados. Um deles é que muitas das DLLs e drivers sob o %systemroot%\system32 diretório e %systemroot%\system32\drivers são protegidos por um cão de guarda chamado System File Protetor (SFP). Você pode verificar sua existência entrando nesse system32 diretório e renomeando ntoskrnl.exe. O cão de guarda irá acordar e notificá-lo de que detetou adulteração de um arquivo de sistema protegido e está reparando-o. Se você verificar o diretório novamente, você verá ntoskrnl.exe que foi substituído magicamente. Da próxima vez vou dizer-lhe como isto funciona.
Obrigado por ler a Newsletter da Systems Internals.
Publicado sábado, 15 de maio de 1999 19:15 por ottoh
[Arquivo de boletins informativos ^] <[ Volume 1, Número 1] [Volume 1, Número 3 >]