[Arquivo de boletins informativos ^] [Volume 1, Número 2 >]
O Boletim Informativo de Sistemas Internos Volume 1, Número 1
14 de abril de 1999 - Nesta edição:
NOVIDADES NOS SISTEMAS INTERNOS
- VolumeID para Windows 9x
- EFSDump
- ListDLLs para Compaq Alpha
- "Dentro do processo de inicialização, parte 2"
- Meu Artigo da Revista Windows NT de abril
- Sem crédito onde é devido
- Coisas não tão novas
NOTÍCIAS DO INTERNALS
- Verificador de Driver Win2K
- Teste de Y2K com Boot.ini
O QUE ESTÁ POR VIR
- Spinlocks enfileirados no Win2K
- Tokenmon
PATROCINADOR: WINTERNALS SOFTWARE
O Boletim Informativo de Sistemas Internos é patrocinado pela Winternals Software, na Web em http://www.winternals.com. O Winternals Software é o principal desenvolvedor e provedor 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á, pessoal.
Bem-vindo à primeira parte do Boletim Informativo interno de sistemas. Tenho o prazer de dizer que o boletim informativo já adquiriu 1000 assinantes desde seu anúncio há pouco mais de uma semana.
Meu objetivo no boletim informativo é fornecer informações oportunas sobre novos utilitários e artigos que estão aparecendo no Systems Internals, além de fornecer informações sobre os internos do Windows que não têm um fórum apropriado no site do Systems Internals. Se você tiver comentários ou sugestões sobre o boletim informativo, fique à vontade para passá-los para mim em mark@...... Além disso, encaminhe o boletim informativo para qualquer um que você saiba que pode estar interessado nele. Instruções sobre como assinar, cancelar a assinatura ou modificar sua assinatura são fornecidas no final do boletim informativo.
Agradecemos!
-Mark
NOVIDADES NOS SISTEMAS INTERNOS
VOLUMEID PARA WINDOWS 9X
Embora o Windows NT e o Windows 9x permitem que você altere o rótulo em uma unidade lógica ou disquete usando o comando "label", eles não fornecem meios para que você possa alterar as IDs de volume que eles atribuem arbitrariamente quando você formata unidades. O programa VolumeID, que está disponível para o Windows NT no site Internos de Sistemas há mais de um ano, acaba de ser portado para o Windows 9x. Este applet permite alterar as IDs de volume em discos rígidos e disquetes para o que você quiser.
O VolumeID usa APIs que permitem que os aplicativos leiam e escrevam diretamente em unidades lógicas e, no Win9x, unidades físicas (disquetes), ignorando sistemas de arquivos. No Windows NT/2K, o VolumeID usa ReadFile e WriteFile regulares para acessar dados brutos da unidade – o truque é como ele especifica o nome do volume que deseja acessar. Você pode descobrir como acessar unidades físicas ou lógicas de um aplicativo em Windows NT/2K no artigo Q100027 da Base de Dados de Conhecimento da Microsoft. Para acesso do Windows 9x a unidades lógicas, você pode basear seu código no código de exemplo fornecido no artigo Q174569 da Base de Dados de Conhecimento da Microsoft. Se você precisar executar o acesso direto de unidade de disquete do seu aplicativo no Windows 9x, use a VWIN32_DIOC_DOS_INT13 IOCTL do Win32, que está documentada no MSDN.
Baixar VolumeID em http://www.sysinternals.com/misc.htm.
EFSDUMP
O Windows 2000 será a estreia da tecnologia interna de criptografia de arquivos da Microsoft, o Encrypting File System. Com o EFS vem uma série de novas APIs para manipular arquivos criptografados, incluindo um, QueryUsersOnEncryptedFile, que permite que você veja quais usuários estão registrados para ter acesso a arquivos criptografados e quais usuários são registrados como Agentes de Recuperação para esses arquivos. Escrevi um pequeno programa chamado EFSDump que permite que você veja facilmente essas informações para arquivos criptografados em seu sistema.
Embora eu esteja no assunto das APIs do EFS, há um número de novas APIs que não foram documentadas a partir do MSDN de abril, algo bastante perturbador neste estágio final do ciclo de lançamento do Windows 2000. Mais notavelmente, OpenEncryptedFileRaw, ReadFileEncryptedRaw, WriteFileEncryptedRaw e CloseEncryptedFileRaw (todos são exportados pelo ADVAPI32.DLL do Win2K) não estão documentados no momento. O uso dessas APIs é exigido por qualquer aplicativo que deseje fazer backup de arquivos criptografados, o que significa que a Microsoft está passando informações sobre eles apenas para selecionar parceiros, ou as empresas de software de backup terão que lutar para tirar seus produtos da porta quando a Microsoft eventualmente os documentar publicamente. Uma coisa é certa: os desenvolvedores do programa NTBACKUP do Windows 2000 já tiveram acesso à documentação da API: o NTBACKUP do Win2K Beta 3 está usando ativamente as APIs.
Se você estiver interessado em internos do EFS, certifique-se de ler minha próxima série de duas partes de junho/julho no EFS na minha coluna "NT Internals" na Revista Windows NT. No artigo, descrevo exatamente onde os FEKs (Chaves de Criptografia de Arquivo) e as chaves EFS do usuário são armazenados, como o processo de criptografia é executado pelo NTFS, pelo driver EFS e pelo LSASRV (o Servidor subsistema da Autoridade de Segurança Local) e, claro, como a descriptografia funciona.
Baixar o EFSDump com código-fonte completo em http://www.sysinternals.com/misc.htm.
LISTDLLS PARA COMPAQ ALPHA
O número de utilitários disponíveis para o Alfa nos Sistemas Internos continua crescendo. A adição mais recente é ListDLLs, um utilitário de linha de comando que permite exibir informações de DLL para processos em execução. Minha ferramenta HandleEx permite que você veja essas informações, bem como informações sobre os identificadores (arquivos, processos, threads, objetos de sincronização) que os processos abriram, mas o HandleEx é uma ferramenta de GUI para que nem sempre seja conveniente (ele não pode ser executado dentro de um arquivo em lotes, por exemplo).
Você está curioso sobre a proporção de downloads da versão x86 do utilitário típico Systems Internals para sua versão Alfa correspondente? É cerca de 20:1, que acompanha de perto as estimativas do setor da base de usuários NT Alfa instalado como sendo 5% do mercado total do NT.
Você pode baixar ListDLLs e outras portas Alfa, incluindo HandleEx, em http://www.sysinternals.com/alpha.htm.
"DENTRO DO PROCESSO DE INICIALIZAÇÃO, PARTE 2"
Minha coluna "Internos do NT" de janeiro do Windows NT Magazine agora está disponível on-line por meio do site da Revista Windows NT. Você pode encontrar um link para ele, bem como para as colunas "Internos do NT" da Parte 1 e mais antigas, na página Publicações em Sistemas Internos: http://www.sysinternals.com/publ.htm.
MEU ARTIGO DA REVISTA APRIL WINDOWS NT
Além disso, não se esqueça de dar uma olhada no meu artigo de recurso na edição de abril da Revista Windows NT, "Linux e as Empresas". Revelo vários problemas significativos em relação ao kernel Linux 2.2 e aplicativos de servidor de rede (aplicativos "empresariais") que, em última análise, impedirão que essa versão do kernel Linux concorram frente a frente com o NT e outras variantes UNIX em termos de desempenho.
SEM CRÉDITO ONDE É DEVIDO
Em uma observação relacionada, você já deve ter ouvido falar do recém-lançado D.H. Brown (uma empresa analista) sobre a capacidade do Linux como um sistema operacional empresarial. Acontece que o autor do relatório fortemente "emprestou" um e-mail meu que alguém postou publicamente no grupo de notícias Usenet do kernel Linux em Janeiro. Se você tiver acesso ao relatório e ler as páginas (44 e 45) discutindo Linux e vários processadores (o relatório não está disponível publicamente - você deve comprá-lo por uma quantia alta) e, em seguida, ler meu email no Deja News, você verá um paralelo direto, até pequenos detalhes.
COISAS NÃO TÃO NOVAS
Estou usando esta seção do boletim informativo para apresentar alterações recentes no site de Sistemas Internos que talvez você não esteja ciente e/ou para fornecer mais informações sobre um utilitário do que o que está disponível no site. Por exemplo, há algumas semanas lançamos Filemon v4.1. Esta versão do Filemon é capaz de monitorar a atividade de Pipe Nomeado e Slot de Email no Windows NT/2K. O aprimoramento do código necessário para dar suporte a isso foi relativamente pequeno, já que Pipes nomeados e Emailslots são implementados como drivers do sistema de arquivos. A parte difícil (tediosa) era descobrir os IOCTLs (Comandos de Controle de E/S) privados que esses sistemas de arquivos especiais dão suporte para que Filemon possa mostrá-los. Você pode baixar o Filemon (que funciona no Windows NT/2K e no Windows 9x) em http://www.sysinternals.com/filemon.htm.
Se você quiser saber mais sobre como o Filemon funciona internamente, consulte minha coluna "Internos do NT" da Revista NT do Windows de fevereiro, que tem o título "Inside NT Utilities". O artigo descreve como usar Filemon, Regmon, NTFSDOS, NewSID e HandleEx e informa um pouco sobre como eles funcionam.
NOTÍCIAS DO INTERNALS
VERIFICADOR DE DRIVER DO WINDOWS 2000
O Windows 2000 Beta 3 está introduzindo um avançado auxílio de desenvolvimento de driver de dispositivo chamado Verificador de Driver. Essa ferramenta funciona com código no kernel para obter o controle do driver e exercê-lo para adesão às regras do modo kernel de uma maneira que não era anteriormente antes possível. Os drivers de dispositivo com bugs são de longe a contribuição mais significativa para a reputação entre muitas pessoas de que o NT é um sistema operacional instável, e essa ferramenta visa reparar essa reputação ajudando os gravadores de driver a encontrar seus bugs antes que os usuários o façam.
Vários tipos de problemas sutis podem passar por testes de driver casuais (o tipo mais comum de teste realizado sob restrições apertadas de tempo para o mercado) e até mesmo passar por testes sérios de estresse. Um tipo de problema de driver comum é um driver acessando memória paginada em "IRQL elevado" (prioridade de interrupção alta). Se a memória acessada pelo driver estiver fisicamente presente no momento do acesso (ela não foi paginada para o arquivo de paginação), o acesso ilegal passará despercebido. Libere um driver que viole essa regra para o mundo selvagem dos usuários e seu limite para aparecer, resultando em uma falha na Tela Azul.
Outro tipo de erro de programação de driver comum é que um desenvolvedor escreva o código com a suposição de que a memória paginada e/ou não paginada sempre estará disponível, ou seja, não marcar os valores retornados para alocações. Se o pool se esgotar e o driver receber um endereço de buffer NULL, o driver desreferencia o sistema em uma Tela Azul. Embora o esgotamento do pool seja uma ocorrência rara, não é algo que deve dar a um Administrador do Sistema uma Tela Azul. Um bug de memória relacionado é um estouro de buffer ou subexecutado, em que um driver lê ou grava fora de um buffer alocado.
O Verificador de Driver resolve problemas de IRQL substituindo chamadas para todas as funções que manipulam IRQLs em um driver (por exemplo KeRaiseIrql, KeAcquireSpinLock) com funções de kernel verificadora correspondentes (VerifierKeRaiseIrql, VerifierKeAcquireSpinLock) no momento em que o driver é carregado. Sempre que o IRQL é gerado para DISPATCH_LEVEL ou superior, o código verificador chama uma função interna do Gerenciador de Memória, MmTrimAllPageableSystemMemory(), para forçar todos os dados paginado a sair da memória física. Assim, no instante em que um driver quebra a regra IRQL de não acessar dados pagináveis ou código de DISPATCH_LEVEL ou superior, o Gerenciador de Memória detectará a tentativa de acessar uma página não presente e lançará uma Tela Azul. Isso permite que um desenvolvedor capture rapidamente esses tipos de bugs antes que o driver saia da porta, pois ele pode depurar a falha e ver o driver sentado na pilha de falhas.
O Verificador de Driver realiza testes de uso de memória com ele corrigindo a tabela de importação do driver a ser verificada para que o driver chame funções de memória do verificador em vez das versões de kernel padrão. Por exemplo, uma chamada para ExAllocatePool é substituída por uma chamada para VerifierAllocatePool. Há duas técnicas que o Verificador usa para ajudar um desenvolvedor a encontrar rapidamente bugs de memória. A primeira é que ele usa um pool especial de memória em que uma página de proteção (uma página de proteção é uma página inválida) é colocada logo após o final do buffer. Além disso, a parte da página na qual o buffer é alocado que precede o buffer é preenchida com uma assinatura. Os estouros que estão dentro de uma página além do fim de um buffer são detectados imediatamente, pois resultarão em falhas de página ilegais na página de proteção. Subexecuções que envolvem modificação em dados anteriores a um buffer são detectadas pelo Verificador quando o driver desaloca a memória, pois a assinatura terá sido alterada.
Os drivers que sempre esperam pool não vazio serão enganados para gerar falhas pelo Verificador com o uso de sua "injeção de falha de memória". Você pode configurar o Verificador para falhar aleatoriamente nas alocações de pool de um driver.
Há alguns outros tipos de erro que o Verificador de Driver verifica, incluindo consistência IRP (pacote de solicitação de E/S) e proteção somente leitura de páginas de código do sistema e do driver.
Se você for um desenvolvedor de driver de dispositivo, fará um favor a si mesmo, à sua empresa e à comunidade NT testando com o Verificador. Observe que você também deve testar os drivers NT 4.0 compatíveis com o Win2K assim que tiver acesso ao Verificador de Driver (a maioria dos desenvolvedores obterá com a remessa do Win2K Beta 3 do MSDN no final de abril ou maio).
Para obter mais informações, consulte Verificador de Driver.
TESTE Y2K COM BOOT.INI
Se você marcar frequentemente o site de Sistemas Internos, provavelmente já está ciente da nova opção de BOOT.INI sem documentos do Win2K, /YEAR. Não menção no site que a opção também é compatível com o NT 4.0 Service Pack 4. Essa opção permite que você falsifique o NT e todo o software em um sistema NT para pensar que é um ano diferente. Por exemplo, /YEAR=2001 faria o sistema pensar que era 2001 em vez de 1999. Portanto, a opção é ideal para testar problemas de Y2K em qualquer nível de software e a vantagem de usá-lo em vez de redefinir manualmente o relógio BIOS (por meio do applet Relógio, por exemplo) é que a alteração é temporária e só ativa quando você inicializa para uma instalação que tem a opção presente em sua linha BOOT.INI. Isso facilita a criação de uma instalação Y2K especial simplesmente pegando uma linha de inicialização existente do BOOT.INI, duplicando-a e adicionando a opção /YEAR.
O QUE ESTÁ POR VIR
Espere o próximo boletim informativo em algumas semanas. A dica interna que terei para você na próxima vez é sobre Spinlocks enfileirados, um novo tipo de spinlock que o Windows 2000 usa para seus spinlocks globais. Aqui estão os spinlocks globais que existem no Windows 2000:
- KiDispatcherLock: o bloqueio de banco de dados do agendador
- KiContext-SwapLock: o bloqueio de troca de piso
- MmPfnLock: o bloqueio de banco de dados de quadro de página física
- MmSystemSpaceLock: o bloqueio de espaço de endereço no modo kernel
- CcMasterSpinLock: o spinlock global do Gerenciador de Cache
- CcVacbSpinLock: o bloqueio de matriz de mapeamento do Gerenciador de Cache
Em vez de usar spinlocks de kernel regulares (KeAcquireSpinLock, KeReleaseSpinLock) para esses bloqueios globais como o NT 4.0 fez, o kernel do Windows 2000 usa spinlocks enfileirados (KeAcquireQueuedSpinLock, KeReleaseQueuedSpinLock). Esses bloqueios têm algumas propriedades interessantes que minimizam a atividade do barramento em SMPs. Da próxima vez, direi como os spinlocks enfileirados são implementados.
Em breve em Sistemas Internos é Tokenmon, mais uma ferramenta de monitoramento. Tokenmon mostrará informações detalhadas sobre todas as atividades relacionadas a tokens em seu sistema, incluindo logins, logoffs, uso de privilégios e representação.
Obrigado por ler o Boletim Informativo dos Sistemas Internos.
Publicado quarta-feira, 14 de abril de 1999 19:16 por ottoh