[Arquivo de boletins informativos ^] [Volume 1, Número 2 >]
O Boletim Informativo Interno dos Sistemas Volume 1, Número 1
14 de abril de 1999 - Nesta edição:
O QUE HÁ DE NOVO NA SYSTEMS INTERNALS
- VolumeID para Windows 9x
- EFSDump
- ListDLLs para Compaq Alpha
- "Dentro do processo de inicialização, Parte 2"
- Meu artigo de abril do Windows NT Magazine
- Sem crédito onde é devido
- Coisas não tão novas
NOTÍCIAS INTERNAS
- Verificador de driver Win2K
- Testes Y2K com Boot.ini
O QUE VEM POR AÍ
- Spinlocks enfileirados no Win2K
- Tokenmon
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 à primeira edição da Newsletter da Systems Internals. Tenho o prazer de dizer que a newsletter já adquiriu 1000 assinantes desde o seu anúncio, há pouco mais de uma semana.
Meu objetivo no boletim informativo é dar-lhe informações oportunas sobre novos utilitários e artigos que estão aparecendo na Systems Internals, além de dar-lhe informações sobre internos do Windows que não têm um fórum apropriado no site da Systems Internals. Se você tiver quaisquer comentários ou sugestões sobre a newsletter, sinta-se livre para passá-los para mim em mark@.... Além disso, por favor, encaminhe a newsletter para qualquer pessoa que você conheça que possa estar interessada nela. As instruções para subscrever, cancelar a subscrição ou modificar a sua subscrição são fornecidas no final da newsletter.
Obrigado!
-Marcar
O QUE HÁ DE NOVO NA SYSTEMS INTERNALS
VOLUMEID PARA WINDOWS 9X
Embora o Windows NT e o Windows 9x permitam alterar o rótulo em uma unidade lógica ou disquete usando o comando "label", eles não fornecem nenhum meio 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 Systems Internals há mais de um ano, acaba de ser portado para o Windows 9x. Este applet permite alterar os IDs de volume em discos rígidos e disquetes para o que quiser.
O VolumeID usa APIs que permitem que os aplicativos leiam e gravem diretamente em unidades lógicas e, no Win9x, unidades físicas (disquetes), ignorando sistemas de arquivos. No Windows NT/2K VolumeID usa ReadFile e WriteFile regulares para acessar dados brutos da unidade - o truque está em como ele especifica o nome do volume que deseja acessar. Você pode descobrir como acessar unidades físicas ou lógicas de um aplicativo no Windows NT/2K no artigo Q100027 da Base de Dados de Conhecimento Microsoft. Para acesso do Windows 9x a unidades lógicas, você pode basear seu código em código de exemplo fornecido no artigo Q174569 da Base de Dados de Conhecimento Microsoft. Se você precisar executar o acesso direto à unidade de disquete do seu aplicativo no Windows 9x, use o Win32 IOCTL VWIN32_DIOC_DOS_INT13, que está documentado no MSDN.
Faça o download do VolumeID em http://www.sysinternals.com/misc.htm.
EFSDUMP
O Windows 2000 será a estreia da tecnologia de encriptação de ficheiros integrada da Microsoft, o Sistema de Encriptação de Ficheiros. Com o EFS, vêm várias novas APIs para manipular arquivos criptografados, incluindo uma, QueryUsersOnEncryptedFile, que permite ver quais usuários estão registrados para ter acesso a arquivos criptografados e quais usuários estão registrados como agentes de recuperação para esses arquivos. Eu escrevi um pequeno programa chamado EFSDump que permite que você veja facilmente essas informações para arquivos criptografados em seu sistema.
Embora eu esteja falando sobre APIs EFS, há várias novas APIs que não foram documentadas até o 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) estão atualmente não documentados. 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 parceiros selecionados, ou as empresas de software de backup terão que se esforçar para obter seus produtos 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 componentes internos do EFS, não deixe de conferir minha próxima série de duas partes de junho/julho sobre o EFS na minha coluna "NT Internals" na Windows NT Magazine. No artigo, descrevo exatamente onde FEKs (File Encryption Keys) e chaves EFS do usuário são armazenados, como o processo de criptografia é executado pelo NTFS, o driver EFS e LSASRV (o Local Security Authority Subsystem Server) e, claro, como a descriptografia funciona.
Faça o download do EFSDump com o 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 Alpha na Systems Internals continua a crescer. A adição mais recente é ListDLLs, um utilitário de linha de comando que permite visualizar 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 HandleEx é uma ferramenta GUI, portanto, nem sempre é conveniente (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 Systems Internals típico para sua versão Alpha correspondente? É cerca de 20:1, que acompanha de perto as estimativas da indústria da base de usuários Alpha NT instalada como sendo 5% do mercado NT total.
Você pode baixar ListDLLs e outras portas Alpha, incluindo HandleEx, em http://www.sysinternals.com/alpha.htm.
"DENTRO DO PROCESSO DE INICIALIZAÇÃO, PARTE 2"
A minha coluna "NT Internals" de janeiro da Windows NT Magazine está agora disponível on-line através do Web site da Windows NT Magazine. Você pode encontrar um link para ele, bem como para a Parte 1 e colunas mais antigas "NT Internals", na página Publicações em Systems Internals: http://www.sysinternals.com/publ.htm.
MEU ARTIGO DE ABRIL WINDOWS NT MAGAZINE
Além disso, certifique-se de dar uma olhada no meu artigo de recurso na edição de abril da Windows NT Magazine, "Linux and the Enterprise". Eu revelo vários problemas significativos com relação ao kernel Linux 2.2 e aplicativos de servidor de rede ("aplicativos empresariais") que, em última análise, impedirão esta versão do kernel Linux de competir frente a frente com NT e outras variantes do UNIX em termos de desempenho.
NENHUM CRÉDITO ONDE É DEVIDO
Em uma nota relacionada, você já deve ter ouvido falar do recém-lançado D.H. Brown (uma empresa de analistas) sobre a capacidade do Linux como um sistema operacional corporativo. Acontece que o autor do relatório "pegou emprestado" de 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 multiprocessadores (o relatório não está disponível publicamente - você deve comprá-lo por uma soma elevada), e depois ler meu e-mail 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 exibir alterações recentes no site da Systems Internals que você pode não estar ciente e/ou para fornecer mais informações sobre um utilitário do que as disponíveis no site. Por exemplo, há algumas semanas, lançamos o 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 suportar isso foi relativamente pequeno, uma vez que Named Pipes e Mailslots são implementados como drivers de sistema de arquivos. A parte difícil (tediosa) foi descobrir os IOCTLs privados (Comandos de Controle de E/S) que esses sistemas de arquivos especiais suportam para que o Filemon possa mostrá-los. Você pode baixar Filemon (que funciona no Windows NT/2K e Windows 9x) em http://www.sysinternals.com/filemon.htm.
Se você quiser saber mais sobre como Filemon funciona internamente, consulte minha coluna "NT Internals" da Windows NT Magazine de fevereiro, intitulada "Inside NT Utilities". O artigo descreve como usar Filemon, Regmon, NTFSDOS, NewSID e HandleEx, e conta um pouco sobre como eles funcionam.
NOTÍCIAS INTERNAS
VERIFICADOR DE DRIVER DO WINDOWS 2000
O Windows 2000 Beta 3 está introduzindo um auxílio ao desenvolvimento de driver de dispositivo muito poderoso chamado Driver Verifier. Esta ferramenta trabalha com código no kernel para obter o controle do seu driver e exercê-lo para a adesão às regras do modo kernel de uma forma que não era possível anteriormente. Drivers de dispositivo buggy 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 esta ferramenta visa reparar essa reputação, ajudando os criadores de drivers a encontrar seus bugs antes que os usuários o façam.
Vários tipos de problemas subtis podem passar por testes casuais ao condutor (o tipo mais comum de teste realizado sob restrições apertadas de tempo até ao mercado) e até mesmo passar por testes de stress sérios. Um tipo de problema de driver comum é um driver acessando a memória paginada em "IRQL elevado" (alta prioridade de interrupção). Se a memória que o driver acessa 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 seja obrigado a aparecer, resultando em uma falha na tela azul.
Outro tipo de erro comum de programação de driver é um desenvolvedor escrever o código com a suposição de que a memória paginada e/ou não paginada estará sempre disponível, ou seja, eles não verificam os valores de retorno para alocações. Se o pool se esgotar e o driver receber um endereço de buffer NULL, o driver alegremente desreferencia o sistema em uma tela azul. Embora a exaustão da piscina seja uma ocorrência rara, não é algo que deva dar a um administrador de sistema uma tela azul. Um bug de memória relacionado é uma saturação ou execução insuficiente do buffer, onde um driver lê ou grava fora de um buffer que ele alocou.
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 correspondentes do kernel do verificador (VerifierKeRaiseIrql, VerifierKeAcquireSpinLock) no momento em que o driver é carregado. Sempre que o IRQL é elevado para DISPATCH_LEVEL ou superior, o código do verificador chama uma função interna do Gerenciador de Memória, MmTrimAllPageableSystemMemory(), para forçar todos os dados paginados para fora 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 ou superior, o Gerenciador de memória detetará a tentativa de DISPATCH_LEVEL acessar uma página não presente e lançará uma tela azul. Isso permite que um desenvolvedor detete rapidamente esses tipos de bugs antes que o driver saia pela porta, já que eles podem depurar o acidente e ver seu 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 verificado para que o driver chame as funções de memória do verificador em vez das versões padrão do kernel. 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. O primeiro é que ele usa um pool especial de memória onde 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. As saturações que estão dentro de uma página além do final de um buffer são detetadas imediatamente, pois resultarão em falhas de página ilegais na página de proteção. Underruns que envolvem modificação de dados que precedem um buffer são detetados pelo verificador quando o driver deslocaliza a memória, uma vez que a assinatura terá mudado.
Os drivers que sempre esperam pool não vazio serão induzidos a 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á um punhado de outros tipos de erro que o Verificador de Driver verifica, incluindo a consistência IRP (I/O Request Packet) e a proteção somente leitura das páginas de código do sistema e do driver.
Se você é um desenvolvedor de driver de dispositivo, estará fazendo um favor a si mesmo, à sua empresa e à comunidade NT testando com o Verificador. Observe que você também deve testar seus drivers NT 4.0 que são compatíveis com Win2K assim que você tiver acesso ao verificador de driver (a maioria dos desenvolvedores irá obtê-lo com a remessa do MSDN do Win2K Beta 3 no final de abril ou maio).
Para obter mais informações, consulte Verificador de driver.
TESTE Y2K COM BOOT. INI
Se você freqüentemente verificar o site Systems Internals, então você provavelmente já está ciente do novo Win2K não documentado BOOT. INI switch, /ANO. Eu não mencionei no site que a opção também é suportada pelo NT 4.0 Service Pack 4. Esta opção permite falsificar 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. Assim, o switch é ideal para testar problemas Y2K em qualquer nível de software, e a vantagem de usá-lo em vez de redefinir manualmente o relógio do BIOS (através do miniaplicativo Clock, por exemplo) é que a mudança é temporária e só ativa quando você inicializa em uma instalação que tem o switch presente em seu BOOT. Linha INI. Isso facilita a criação de uma instalação especial do Y2K simplesmente pegando uma linha de inicialização existente do BOOT. INI, duplicando-o e adicionando a opção /YEAR.
O QUE VEM POR AÍ
Espere a próxima newsletter dentro de algumas semanas. A dica interna que terei para você na próxima vez é sobre Spinlocks em fila, 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 do 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ísico
- MmSystemSpaceLock: o bloqueio de espaço de endereço do modo kernel
- CcMasterSpinLock: o spinlock global do Cache Manager
- CcVacbSpinLock: o bloqueio da matriz de mapeamento do Gerenciador de Cache
Em vez de usar spinlocks regulares do kernel (KeAcquireSpinLock, KeReleaseSpinLock) para esses bloqueios globais como o NT 4.0 fez, o kernel do Windows 2000 usa spinlocks em fila (KeAcquireQueuedSpinLock, KeReleaseQueuedSpinLock). Essas fechaduras têm algumas propriedades interessantes que minimizam a atividade de barramento em SMPs. Da próxima vez vou dizer-lhe como os spinlocks em fila são implementados.
Em breve na Systems Internals está o Tokenmon, mais uma ferramenta de monitoramento. O Tokenmon mostrará informações detalhadas sobre todas as atividades relacionadas ao token em seu sistema, incluindo logins, logouts, uso de privilégios e falsificação de identidade.
Obrigado por ler a Newsletter da Systems Internals.
Publicado quarta-feira, 14 de abril de 1999 19:16 por ottoh