Debug de Emergência

15 de August de 2007 - Fernando Roberto

De repente tela azul. Isso mesmo, aquele seu driver que você já não via o fonte a muito tempo, que era o seu modelo de driver estável, quando foi instalado na máquina do presidente da empresa que você trabalha, resolveu se vingar e dar uma tela azul logo na inicialização do sistema. Ou seja, a máquina liga e reseta e reseta e reseta em um loop infinito que roda em paralelo com a impressão da sua carta de demissão, que por sinal, está sendo impressa em outro micro. Para depurar essa máquina e ver o que está acontecendo, e assim salvar seu projeto, seu emprego, sua dignidade, seu casamento, e por que não dizer, sua vida, você deve configurar seu sistema para entrar em Modo Debug para que o nosso amigo inseparável WinDbg possa entrar em ação. Mas como configurar para Debug uma máquina que não está nem iniciando? Hoje vou falar sobre o suporte que o Windows oferece para evitar esse tipo de situação constrangedora. Como conectar um Debugger em um micro que nunca teve suas configurações de Kernel Debugging habilitadas, seja pelo BOOT.INI ou pelo BdcEdit.

Este post admite que você já sabe como fazer Kernel Debugging e utiliza alguns termos próprios desta prática. A partir do Windows 2000, se você pressionar a tecla F8 enquanto máquina está rodando o NT Loader, mais precisamente, 2 segundos antes de o sistema começar a ser carregado, o sistema paraliza e exibe o menu como mostra abaixo.

Selecione o ítem “Debugging Mode”, isso nos vai levar à lista de sistemas operacionais instalados. Selecione o sistema e o resto fica por conta do WinDbg. Nessas condições, a configuração da conexão serial aplicada seria um Baud rate de 19200 na porta serial mais alta existente em sua máquina. Isto é, se seu micro tem duas portas seriais, então a conexão seria feita a 19200 na COM2. Pelo menos isso é o que a referência nos diz.

Mas na vida real…

Se você fizer alguns testes, também vai concluir que não podemos acreditar em tudo que lemos. Tanto o Windows 2000 como o Windows XP, utilizam sempre a porta COM2 a 19200.

Meu computador é moderno e só tem uma porta serial. Posso me matar? Pois é, mesmo nesses casos, o sistema tenta utilizar a porta COM2, mesmo que ela não exista. Mas não se preocupe, a vida é bela e ainda há uma esperança. Algumas BIOS permitem que você configure o endereço base e a interrupção da única porta serial existente. Isso vai nos ajudar muito, afinal de contas, o NT Loader não é uma aplicação Win32 que solicita um handle para o device COM1 ou COM2 através do Object Manager. Ele simplesmente segue os endereços adotados como padrões.

  • COM1: Address 3F8h, IRQ 4
  • COM2: Address 2F8h, IRQ 3

Desta forma, você poderá configurar a única porta (a COM1) para responder pelos endereços que normalmente são utilizados pela COM2. A BIOS normalmente tem uma lista dos recursos normalmente utilizados pelas portas seriais. Assim, qualquer chinpanzé autista poderia fazer essa troca.

Mas meu computador é mais moderno ainda e não tem nenhuma porta serial. Posso me matar agora? A esperança é a última que morre. Você pode ainda instalar uma placa expansora PCI (ou PCMCIA em caso de notebooks) que nos forneça as portas seriais de que precisamos. É importante notar que esta placa expansora deve criar as portas COM1 e COM2 nos endereços padrões acima descritos.

Você não está entendendo, sou um lazarento que comprou um MacBook 13″, que além de não ter portas seriais, também não oferece nenhum slot PCMCIA ou ExpressCard. Posso me matar agora? Como já comentei em outro post, portas seriais criadas a partir de portas USB não são uma opção para serem utilizadas em uma máquina TARGET durante o Kernel Debugging. Esta conexão é feita pelo NT Loader e as portas seriais que ele conhece são apenas aquelas que respondem pelos endereços acima citados. Agora sim, pode se matar.

Alguma melhoria em Vista?

Já o Windows Vista, este sim ignora a documentação sem dó. A configuração padrão para Kernel Debugging quando pressionamos F8 durante o Boot do Windows Vista é utilizar a porta COM1 a 115200. Mas se você utilizou o aplicativo BcdEdit com o parâmetro /DbgSettings para modificar as configurações de conexão para Kernel Debugging, então serão estas mesmas configurações a serem utilizadas quando F8 for pressionado. Ou seja, se você é um lazarento que, como eu, configurou a porta IEEE 1397 para fazer Debug em seu MacBook, então estas serão as configurações utilizadas quando você pressionar F8.

Pode parecer brincadeira, mas é realmente frustrante ter que ir até à máquina do cliente onde seu driver está dando trabalho, armado dos seus vários aparatos tecnológicos, tais como notebook, porta FireWire, cabo serial e assim por diante, e não poder fazer nada simplesmente porque você não consegue conectar o depurador.

Mais uma vez, espero ter ajudado.
Até mais!

Deixe um comentário