Por: Yuri Diogenes
1. Introdução
Apesar do tema não ser algo novo, ainda existem muitos temores acerca do erro que gera uma
Tela Azul no Windows, também chamado de “Stop Error” devido a um fator simples: quando este
tipo de problema acontece temos uma parada no servidor, o que significa uma parada na
produção por alguns minutos ou horas.
Este tipo de problema precisa ser depurado com bastante cuidado, até mesmo porque muita
gente interpreta o erro como se fosse sendo algum problema de hardware, ou simplesmente
pensam que é o Windows ou em alguns casos extremos simplesmente vão logo tentando
reinstalar.
2. Revisão dos Conceitos básicos de Sistema Operacional
Para entender os motivos que levam o Windows a ter um problema de parada inesperada é
importante lembrar de alguns conceitos que independem do fabricante do sistema operacional e
está mais ligado ao conceito em si.
Se tratando de conceito, podemos então afirmar que a arquitetura x86 é dividida em quatro
anéis, os anéis por sua vez são mecanismos de dividir o sistema operacional em níveis
diferentes de privilégio de acesso. Na arquitetura x86 existem os anéis 0,1,2 e 3 – nesta ordem
temos o número 0 com o mais alto nível de privilégio de acesso e o número 3 com o nível mais
básico.
O Windows utiliza o anel 0 para o modo Kernel, que é o modo pelo qual é garantido acesso
completo a toda memória do sistema assim como todas instruções de CPU. De outro lado o
Windows também utiliza o anel 3, porém para o modo Usuário. Este modo é responsável pelas
aplicações finais, não tendo acesso direto ao hardware e com isso não comprometendo a
estabilidade do sistema operacional.
3. Por que erros deste tipo ocorrem?
Antes de falar com mais detalhes sobre a tela azul, devemos entender porque um erro desta
natureza ocorre. Vejamos então alguns exemplos:
O sistema pode sofrer uma parada fatal quando algum componente que está sendo
executado em modo Kernel é prevenido de continuar sua normal execução;
São exemplos de componentes que rodam neste modo:
o Drivers de dispositivos;
o Componentes do sistema operacional;
o Drivers de filtros de aplicações;
Sabendo que apenas os componentes que rodam em Kernel podem afetar o sistema operacional
fica mais fácil de encontrar os possíveis causadores de tal problema, que neste caso seriam:
Drivers de terceiros com problema;
Falhas no Sistema Operacional;
Falha de hardware.
4. Entendendo o Erro
É importante interpretar cada parte da tela azul, cada parte da mensagem tem uma explicação
específica e endereça uma determinada área. Somente o fato de saber interpretar essa
mensagem já pode lhe abrir caminhos para entender o problema e a partir daí fazer uma
investigação mais detalhada sobre a causa raiz.
Vejamos abaixo como seria então essa interpretação:

Bem, vejamos então o significado de cada sessão:
1) A primeira parte da tela azul é considerada uma sessão chave na interpretação do erro e
investigação da causa raiz. Neste caso do exemplo temos então as seguintes informações:
Tipo de Erro: 0xD1 - DRIVER_IRQL_NOT_LESS_OR_EQUAL
Parâmetro 1: endereço de memória que foi referenciado;
Parâmetro 2: IRQL ou nível de interrupção de software que foi requisitado naquele
momento;
Parâmetro 3: tipo de referência (0 para leitura e 1 para escrita);
Parâmetro 4: o endereço que referenciou a memória.
OBS: A quantidade de parâmetros assim como o significado vai depender diretamente to tipo de
erro que ocorreu.
2) Nesta parte do erro temos informações sobre o possível driver que causou o problema. Isso
pode variar em alguns casos de acordo com o tipo de erro. Para este exemplo utilizamos o
aplicativo NotMyFault.exe que pode ser baixado do site SysInternals.com. Trata-se de um
software gratuito para fins didáticos e para simular alguns tipos de problemas.
3) A parte 3 poderá conter desde possíveis recomendações para a resolução do problema como
também poderá conter apenas informações de que o arquivo de dump foi gerado com sucesso.
5. Exemplos de erro
São muitas as possibilidades de erros que aparecem em uma tela azul, conforme foi dito o
importante é que se tenha em mente que este erro não é o fim do servidor, isso pode ser
totalmente tratável sem requerer medidas mais drásticas.
Abaixo temos alguns exemplos de códigos de erro que podem estar aparecendo em uma tela
azul. A idéia é apenas mostrar os mais comuns tendo em vista que a quantidade de códigos de
erro é extensa.
0x0000000A: IRQL_NOT_LESS_OR_EQUAL
Em linhas gerais podemos dizer que este erro é causado devido a um processo em modo kernel
ou a um driver que tentou acessar um endereço de memória a qual não tinha permissão.
Mais informações:
Troubleshooting a Stop 0x0000000A error in Windows XP
http://support.microsoft.com/?id=314063
0x00000051: REGISTRY_ERROR
Este tipo de erro pode ter ocorrido por uma falha de hardware ou por uma falha no sistema de
arquivos que causou a corrupção do registro. O importante neste caso é que você tenha o
backup do “System State”, pois na maioria das vezes a restauração do registro pode ser o
caminho mais rápido.
Mais informações:
How to troubleshoot a "STOP 0x00000051 REGISTRY ERROR" error message
http://support.microsoft.com/?id=282501
0x0000007B: INACCESSIBLE_BOOT_DEVICE
Em linhas gerais este erro significa dizer que o Windows perdeu acesso à partição do sistema,
essa perda de acesso pode ser devido a problemas de drivers de dispositivos, problema na
controladora de disco ou problema no disco propriamente dito.
Mais informações:
How to troubleshoot "Stop 0x0000007B" error messages
http://support.microsoft.com/?id=822052
6. O que é sempre bom ter por perto
Muitas vezes o erro de tela azul pode aparecer sem que você esteja preparado, nestes casos é
importante que você tenha sempre a sua disposição os itens abaixo:
Backup do system state
Senha do administrador para entrar na console de recuperação (caso necessário)
Reserve sempre um espaço em disco para que se necessário tenha como fazer uma
instalação paralela do sistema operacional
Estes pequenos cuidados podem ajudar bastante em um cenário de tela azul, a recuperação
rápida do servidor vai depender da sua pro atividade na manutenção.
7. O erro acontece, mas nada de arquivo de dump. O que fazer?
Em alguns cenários específicos você poderá cair neste tipo de situação, que é bem frustrante,
pois na maioria das vezes você espera ter um arquivo para iniciar uma resolução de problemas,
mas por algum detalhe não corretamente revisado o arquivo pode não ser gerado. Vejamos
abaixo o que precisa ser feito para garantir que o arquivo de dump seja gerado:
Inicie a revisar as opções de sistema no Painel de Controle / Sistemas / Avançado /
Inicialização e Recuperação / Configurações. Nesta janela é importante que você verifique
as seguintes opções:
o Escolha o tipo de informação de debug que deve ser escrita no disco. Nesta
categoria temos os seguintes tipos de dump:
Pequeno: este tipo de dump será limitado a um conjunto pequeno de
informações e poderá não ser suficiente para a análise de um problema. São
exemplos de informações que podemos obter com este tipo de arquivo de
dump: o código do erro, a listagem de drivers carregados naquele momento,
informações do processo entre outras coisas.
Kernel: este tipo de dump por sua vez vai registrar apenas informações
relacionadas ao Kernel, não está, portanto incluso neste dump a memória
alocada para aplicações rodando em modo usuário.
Completo: como o nome já diz o dump completo inclui todo o conteúdo
existente em RAM naquele momento, este conteúdo por sua vez será
gravado no arquivo de dump.
o Escolha a localização do arquivo de dump, lembre-se que você precisará de espaço
disponível em disco no mínimo igual ao tamanho da sua memória RAM para receber
este arquivo;
o Assegure que a opção de sobrescrever o arquivo de dump também está
selecionada, caso contrário se o arquivo já estiver lá ele não vai escrever
novamente;
Finalizando essa parte, um aspecto importante para revisar se o arquivo de paginação está
com o tamanho adequado e na localização correta. Este arquivo deverá está localizado na
partição de sistema (%systemroot%) e o seu tamanho máximo deverá ser igual ao tamanho
da sua memória RAM mais 12MB;
Existem alguns cenários em que realmente não é possível você conseguir um dump de memória
completo, isso acontece devido a algumas limitações existentes. Um caso comum é quando o
servidor tem mais de 2GB de memória RAM, para essa situação teríamos duas opções:
configurar o sistema para obter um dump de kernel ou então alterar um valor no arquivo boot.ini
para que o sistema não use mais que 2GB de memória RAM, neste caso usando o parâmetro
/maxmem=2000.
Outro fator importante que também está ligado a servidores com mais de 2GB de RAM é quanto
ao arquivo de paginação. O Windows tem um limite para o arquivo de paginação de 4096 MB,
com isso alguns servidores que tem 8GB de RAM não seguiram a risca o valor de tamanho de
arquivo de paginação sugerido. Neste caso a recomendação seria usar um arquivo de paginação
no C:\ com o valor não maior que 2GB e os outros arquivos de paginação ficariam em diferentes
partições com o tamanho máximo de 4GB para cada um deles. Assim você distribui os arquivos
de paginação e também mantém seu servidor pronto para obter um dump de memória do tipo
kernel.