Meia dúzia de BSODs (erros STOP) em um ano.

Quando eu tive o meu primeiro BSOD neste ano isso foi até digno de uma série de posts sobre o assunto, que começou aqui. De lá para cá ocorreram mais uns cinco. Os dois primeiros ocorreram em outubro, relacionados a win32k.sys, assim:

• No Google Chrome, exatamente no momento em que cliquei em um link (não lembro qual) desta página.
• Ao abrir o Google Chrome, quando este tentou recarregar diversas abas (creio que umas 30) que eu tinha abertas na última sessão;

Cenário

• Windows XP Sp3, com algumas atualizações posteriores, mas com as atualizações desligadas desde 03/04/09;
• Google Chrome 2.0.172.43;
• Win32k.sys versão 5.1.2600.5756

Aparentemente o problema se corrigiu sozinho (talvez num update do chrome), porque eu não fiz nada e ele sumiu. Edit: eu não fui o único a ter esse problema.

Os outros três BSODs ocorreram sempre após sair da hibernação e em "xloader.sys", que é um driver instalado pelo meu plextor convertx. Quando finalmente identifiquei isso simplesmente despluguei o convertX da USB enquanto não uso e os problemas sumiram. O imbecil do driver não sabe lidar com a hibernação (que eu uso todo dia no desktop).

Em resumo: Quatro BSODs foram culpa de drivers mal feitos e dois foram culpa de uma aplicação doida. Sem ter instalado novo hardware ou usado o Chrome teria sido um ano sem BSODs.

Estou falando "um ano" porque em outubro do ano passado eu tive que reinstalar meu XP por causa daquele maldito file infector.

Nota: Eu não estou surpreso por ter visto apenas seis BSODs. Eu estou me achando até azarado. Tenho certeza de que muitos usuários Windows (principalmente power users) passam anos sem ver um erro desses em seus próprios PCs.

Como impedir um usuário administrador de mudar certas configurações.

Nesta dica eu mostro como se protege certas chaves do Registro contra modificação indesejável.

Eu me baseio no fato de que a esmagadora maioria dos "usuários administradores" no mundo Windows tem apenas o privilégio de administrador e não a capacidade. Não é realmente possível impedir um administrador de verdade (ou um power user) de fazer o que quiser com uma conta de administrador. Você pode atrasá-lo e até cansá-lo, mas uma hora ele vai descobrir como se resolve (ou se contorna) o problema.

Por isso esta dica pode ser ainda mais útil e eficaz se o que você está tentando barrar não é um usuário, mas um programa que está fazendo modificações que você não deseja que ele faça, quer seja em suas próprias configurações ou nas configurações de outro programa. Um recente "hack" publicado (não por mim) para se livrar do OGA depende do que vou explicar adiante para funcionar direito.

Vou usar como exemplo a seguinte chave:

HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings

O objetivo é impedir que um usuário com privilégio de administrador consiga mudar a configuração do proxy.

Com o Regedit, vá até a chave que você deseja proteger, clique com o botão direito nela e depois em Permissões. Você deve ver algo assim:

Clique em Avançado

Clique sobre a entrada relacionada com o grupo Administradores (como mostrado acima) e depois em Editar.

Você deve selecionar apenas as entradas mostradas acima, que vão impedir a chave de ser modificada ou excluída. Clique em OK.

Perceba como agora existem duas regras relacionadas com o grupo Administradores, sendo que a que você acabou de criar é do tipo "negar". Clique em OK. O Windows te dará um aviso como este:

E é justamente isso que queremos. Responda Sim.

Você pode testar agora. Logado com privilégio de administrador: Painel de Controle -> Opções de Internet -> Conexões -> Configurações da LAN (as configurações mostradas são da minha rede) .

Tente mudar alguma coisa. Vai parecer que funcionou porque o Windows não vai dar erro algum, mas se você voltar à configuração verá que tudo o que você fez foi revertido (na verdade, nem chegou a ser feito).

Esta configuração específica afeta o IE e o Google Chrome. Se a máquina tiver Firefox você precisa também proteger a chave usada por ele. Isso reforça meu aviso de que esse tipo de "proteção" não vai funcionar indefinidamente contra usuários. Um power user pode instalar outro programa e contornar o problema sem nem sentir que está contornando alguma coisa.

Para reverter, basta remover a entrada do tipo "negar".

Edit: Mesmo diante de todos os meus avisos de que isso não barra power users, tenha em mente que 99% dos usuários não conseguirão passar por essa proteção. Mesmo que um usuário comum saiba o que você fez (mesmo que você dê a ele uma cópia deste texto) ele ainda precisa saber qual chave você protegeu. E isso está longe de ser óbvio. Pode ser que seja possível escrever um programa que varra o Registro movendo todas as negações, mas esse programa ainda não existe (não que eu saiba).

Aplicações possíveis (não testei):

• Impedir a modificação de chaves que provocam execução automática raramente modificadas legitimamente mas muito populares no círculo do malware;
• Impedir a criação de chaves que são criadas por determinados softwares, impedindo então que esses softwares sejam (ao menos corretamente) instalados.

Notas:

• Não é aconselhável que você tente proteger todo o Registro dessa forma. Pode ser feito, mas não dá para antecipar todos os possíveis efeitos colaterais. E se você vai proteger todo o Registro precisa avaliar se não seria melhor simplesmente dar uma conta limitada ao usuário;
• Você pode provocar problemas enlouquecedores se usar isto de forma arbitrária e depois "esquecer" o que fez. Por exemplo, se você proteger alguma chave contra leitura pode provocar travamentos difíceis de diagnosticar;
  
• Não é possível proteger apenas valores. Somente chaves tem atributos de permissão;
• É possível reverter permissões por software, mas é complicado e a maioria dos softwares (incluindo os da própria Microsoft) nem "imagina" que irá ter que fazê-lo e muito menos "sabe" como;
  
• No exemplo eu protegi uma chave sob HKCU (Current User) e isso provavelmente só vai ter efeito sobre o usuário corrente. Se você escolher cuidadosamente a chave sua modificação vai ter efeito sobre todos os usuários.
  

Texto relacionado: "Algumas chaves estão abertas pelo sistema ou outros processos."

Como editar "offline" o Registro do Windows.

Neste texto eu assumo que você já leu meu texto anterior Recuperando-se de desastres no Registro do Windows e está familiarizado com todos os termos e conceitos que abordei nele. Esta é a Segunda Parte.

O que eu vou explicar aqui é algo poderoso. Se você é um power user ou técnico de manutenção, precisa saber pelo menos que isso é possível. Com essa técnica muitas instalações do Windows tidas como irrecuperáveis "porque você não consegue nem entrar no Windows" podem ser salvas em minutos com uma precisão maior (você nem precisará reinstalar drivers) do que a explicada na Primeira Parte deste texto. Agora eu vou mostrar apenas a técnica sem ensinar a resolver nenhum problema específico, mas em futuros textos eu vou mostrar problemas "de arrancar os cabelos" que são facilmente resolvidos com este método.

Eu não "inventei" isto aqui, como ficará óbvio logo no início da explicação. Diversos textos de suporte da Microsoft usam este método. Mas se você não estiver familiarizado pode ler o texto uma, duas, diversas vezes e não conseguir entender o que danado o autor está tentando explicar. Aqui eu tento dar a base necessária para isso.

------------------------------

---

Editar o Registro "offline" é editar o Registro de uma instalação do Windows que não está sendo usada. Existem diversos programas que se propõem a fazer isso, mas hoje eu só vou falar do meu método preferido, que é usar o próprio regedit.exe.

1) Abra o regedit e selecione HKLM
2) Arquivo -> Carregar Seção (Load Hive)

Nota: Além de HKLM a única chave root que permite carregar um hive é HKU. As outras não permitem porque são "virtuais" (apenas atalhos para outras chaves em HKLM e HKU).

3) Procure pelo arquivo que contém o hive que você quer examinar ou editar. Pode ser até um arquivo isolado trazido em um pendrive. No exemplo, vou carregar o hive System:

Notas:

• Perceba a inconsistência. O diálogo chama de "ramificação" o que o menu chama de "seção". Eu prefiro "hive" mesmo;
  
• O hive Software também pode ser carregado desta maneira e isso tem uma certa utilidade na hora de caçar vírus. Mas neste texto eu vou dar ênfase ao hive System porque é nele que se concentram os problemas que causam BSODs (provocados por vírus ou não) e te impedem de entrar no Windows.

4) O Regedit pede um nome para a chave que vai ser criada para conter esse hive. Pode ser qualquer coisa, mas eu vou tentar padronizar todos os meus textos com "temp_remover":

Hive carregado. Perceba como sua estrutura é parecida (mas nunca poderá ser igual) com a da chave SYSTEM:

Nesse ponto você já pode explorar o hive e fazer edições manuais sem qualquer problema.

Quando tiver terminado, descarregue o hive:

A parte intuitiva termina aqui. A partir de agora você precisa prestar atenção ao que vou explicar e certificar-se de que entendeu alguns conceitos importantes, ou você poderá tanto se frustrar (nada que você fizer funcionará) quanto bagunçar o Registro do Windows que você está usando como suporte.


Faça um backup antes

O que você vai fazer pode ficar bastante confuso. Sempre existe o risco de por bobeira você piorar as coisas. Se isso acontecer você vai querer ter feito um backup de todos os arquivos de hive (não apenas o que você está editando) da instalação defeituosa, para poder recomeçar do início.


Arquivos .reg precisam ser especialmente preparados

Primeiro, uma ótima notícia: Você pode carregar várias modificações automaticamente no hive clicando duas vezes em um arquivo .reg. A má notícia (que nem é tão má assim) é que você não pode utilizar um arquivo .reg "normal" destinado a uma instalação "viva" do Windows. Por exemplo, uma modificação a se fazer em ControlSet001 normalmente começa assim:

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001]

Mas o hive que queremos modificar está carregado sob outra chave. Se quisermos fazer uma modificação em ControlSet001 desse hive a linha acima precisa ser mudada para:

[HKEY_LOCAL_MACHINE\temp_remover\ControlSet001]

Isso não é nenhum problema, desde que você saiba que precisa ser feito. Até mesmo no notepad você pode mandar substituir todas as ocorrências de "MACHINE\SYSTEM\" por "MACHINE\temp_remover\" e salvar um novo arquivo .reg pronto para ser carregado.

Notas:

• O notepad serve, mas não é otimizado para longas substituições. Isso pode demorar um bocado se o arquivo for grande, mas funciona, é confiável e está disponível onde outros editores não estão;
  
• Nunca caia na besteira de por preguiça substituir apenas "SYSTEM" ou "\SYSTEM\". Quanto mais longa a string de referência, mais difícil é você substituir a string errada em algum lugar.
  

CurrentControlSet não existe e nem pode existir

Meu texto "O Papel dos ControlSets no Registro" é leitura essencial agora (você finalmente sabe por que eu escrevi aquilo, não é?). Como você pode ver na penúltima figura acima, a chave CurrentControlSet não aparece sob temp_remover, porque ela não existe fisicamente no arquivo. Qualquer arquivo .reg que você precise importar no hive precisa ser analisado e qualquer referência à chave CurrentControlSet precisa ser renomeada para o ControlSet apropriado.

Por exemplo, se "current" tiver o valor "1" (você leu meu texto com atenção, não leu?), todas as ocorrências de "CurrentControlSet" precisam ser renomeadas para "ControlSet001". A mesma lógica se aplica a edições manuais.

Falhe em observar essa exigência e além de não resolver seu problema ainda vai ganhar mais um erro BSOD/STOP para resolver.

Se você abrir um hive SYSTEM para edição offline e encontrar a chave CurrentControlSet, pode apagá-la sem medo, porque ela não deveria estar ali e pode ser a causa dos seus problemas.

Cuidado para não apagar chaves "extras" que podem ser necessárias para a operação de algum software no outro sistema. Você pode até fazer isso se desconfiar que justamente essa chave extra é responsável pelos seus problemas, mas faça um backup do hive antes.


Tirando o máximo proveito disso

O modo mais óbvio de efetuar esse trabalho é trazer os hives do Windows problemático para uma máquina sadia, seja por cópia num pendrive ou conectando o HDD inteiro como escravo/secundário, mas isso requer outro PC. Se você se lembra de minhas dicas anteriores, sabe que existem outros modos de se ter acesso ao Regedit ainda na máquina problemática. Por exemplo, usando o Console de Recuperação do Vista você pode consertar o Registro defeituoso (mesmo do XP ou Windows 2000) sem precisar de outro PC. O mesmo vale para qualquer liveCD que carregue uma versão simplificada do Windows, como os WinPE/BartPE.

Por incrível que pareça você pode até usar o o estranho prompt SHIFT+10 do windows em alguns casos bem específicos (Sim, aquilo tem utilidade. Eu já usei.).

Aguardem outros textos meus dando exemplos de solução de problemas com esta técnica.

STOP: 0x00000067 CONFIG_INITIALIZATION_FAILED

Esse erro ocorre quando o Windows tenta criar a chave virtual CurrentControlSet, mas já existe uma no hive. É algo raro, porque só vai acontecer se alguém tiver "feito uma lambança" no Registro.

Eu me deparei com esse problema ao fazer uma edição offline do Registro incorretamente. Durante a edição eu inadvertidamente criei (por mescla de arquivo .reg) uma chave CurrentControlSet no hive, quando na verdade essa chave é para ser virtual. Ao tentar inicializar, o Windows tentou criar a chave virtual mas foi impedido pela existência de uma chave física de mesmo nome.

Apenas pelo código do erro não é fácil descobrir a causa (a ajuda da MS é bem fraca), mas como o erro apareceu depois que eu editara o Registro eu iniciei novo processo de edição offline para ver o que estava errado e de cara percebi a chave CurrentControlSet que não deveria estar lá.

A solução é simples: basta abrir offline o hive SYSTEM da instalação com problema e deletar a chave CurrentControlSet que estiver lá.

O papel dos ControlSets no Registro.

ControlSets são chaves no Registro que contém cópias paralelas de praticamente toda a configuração de hardware do Windows. Podem existir vários ControlSets (são geralmente dois), mas apenas um ControlSet está ativo em uma determinada sessão do Windows.

Pontos importantes:

• Valores na chave HKLM\System\Select é que determinam qual o papel de cada ControlSet;
• CurrentControlSet é apenas um atalho para o ControlSet apontado pelo valor Current. A chave CurrentControlSet não existe físicamente e por isso geralmente não aparecerá em procedimentos offline de edição do Registro;

No gráfico abaixo eu tento mostrar como os ControlSets se relacionam com os valores na chave Select:

É o ControlSet apontado por LastKnownGood que é carregado quando escolhemos a opção "última configuração válida" no menu de inicialização do XP:

Outros pontos importantes:

• Embora geralmente CurrentControlSet aponte para ControlSet001 isso não é garantido. Se o atalho CurrentControlSet estiver aparecendo, use-o. Se não estiver, não assuma que deve editar este ou aquele ControlSet. É necessário sempre consultar os valores na chave Select para não piorar as coisas ou perder tempo;
• No dia-a-dia os ControlSets tem conteúdo idêntico, pois a cada boot bem sucedido o ControlSet Current é copiado para o ControlSet LastKnownGood. É apenas "na hora do pau" que seus conteúdos podem ser diferentes;
  

"Última configuração válida" muitas vezes é capaz de resolver os problemas de inicialização provocados por instalação mal sucedida de hardware. Mas infelizmente o mesmo programa mal comportado que bagunça a chave apontada por CurrentControlSet também tem o poder (e a audácia), de mexer também em LastKnownGood. Nem sempre isso é feito com más intenções: quem programou o instalador pode simplesmente não saber o papel dos diferentes ControlSets ou da chave Select e racionalizar que "na dúvida, é melhor alterar todos".

Na verdade, sem saber disso aqui você pessoalmente pode fazer uma caca dessas editando o Registro. Você sabe que precisa alterar um determinado valor e, encontrando o mesmo valor nos dois ControlSets, edita ambos. No próximo boot se você fez besteira, sente os efeitos de uma dupla besteira.

A Navalha de Hanlon resume esse tipo de coisa: "Nunca atribua à malícia o que pode ser adequadamente explicado pela estupidez."

Seja lá qual foi a intenção, na hora do pau escolher "Última configuração válida" acaba não surtindo qualquer efeito.

Recuperando-se de desastres no Registro do Windows.

Nota: O método descrito a seguir foi o que usei inicialmente para me recuperar do dano ao meu Windows descrito neste post, que envolveu um erro STOP : C000021a com status de 0xC0000022. Eu já testei um método ainda melhor e mais preciso, que vou descrever em outro post.


O Registro do Windows, como vemos pelo Regedit, é uma representação em memória do conteúdo de um ou mais arquivos, que tem essa finalidade exclusiva.

No Windows 2000 e XP esses arquivos ficam armazenados em:

%windir%\system32\config\

No momento em que a instalação ou reinstalação do Windows é concluída o programa de instalação faz uma cópia-base desses arquivos em:

%windir%\repair\

Essa cópia tem o estado do seu Registro com todo o software e hardware que o Windows pôde instalar sozinho. E a melhor parte é que o hardware está bem separado do software. São dois arquivos: SYSTEM e SOFTWARE (sem extensão).

Edit: Esses arquivos que contém seções do Registro são chamados de "hives".

O arquivo %windir%\system32\config\SYSTEM tem todo o conteúdo da chave HKLM\SYSTEM do Registro, com todos os drivers e serviços instalados e não muito mais que isso. Se você substituir a cópia em "config" pelo backup em "repair", seu Windows volta, do ponto de vista da instalação do hardware, ao estado em que estava quando o Windows foi instalado.

Nota: Você não precisa e nem deve mexer com o arquivo SOFTWARE a não ser que você queira reverter o Registro totalmente para o estado em que estava na instalação, perdendo toda a configuração do software instalado.

Problemas dessa solução:

• Qualquer driver que foi instalado após a instalação do Windows terá que ser reinstalado. Isso inclui hardware virtual como o Daemon tools e o CPUIdle;
  
• Qualquer software que instale um serviço (como o Cobian Backup e todos os programas antivirus e de firewall) terá que ser reinstalado. Uma exceção possivelmente é o maldito GBplugin, cujo módulo não-serviço irá detectar o que está faltando e reinstalar silenciosamente (eu não testei).
• Alguns raros programas podem não gostar, mesmo não requerendo drivers nem serviços. Eu só tive problemas com o Delphi 5 e o Delphi 7 e ainda assim com controles de terceiros específicos.
  

Não é possível fazer isso com o Windows rodando, mas se vai apelar para essa solução você provavelmente nem está conseguindo mesmo entrar no Windows, porém existem várias alternativas:

• Usar o Console de Recuperação do XP;
• Usar o prompt de comando no DVD do Vista;
  
• Usar um LiveCD qualquer que tenha a capacidade de escrever na sua partição. Todos, se sua partição for FAT32, mas só alguns recentes se sua partição for NTFS.
  
• Colocar o HDD como escravo em outro PC;
• Instalar outra cópia do Windows em um HDD secundário no mesmo PC;
• etc.
  

O meu procedimento no console de recuperação é o seguinte:

Note que a primeira coisa que fiz foi fazer um backup do arquivo SYSTEM defeituoso. Nunca esqueça de fazer um, porque ele vai fazer muita falta depois se algo der errado.

Após reiniciar você já deverá poder entrar normalmente no Windows. Consulte o Gerenciador de Dispositivos para ver o que falta reinstalar. Daemon Tools e CPUIdle reclamam na hora.

Windows 9X

A mesma técnica pode ser usada no Windows 9x, com algumas diferenças. Primeiro, os arquivos do Registro são esses dois:

%windir%\system.dat

%windir%\user.dat

Muitos programas ao se instalarem fazem cópias de backup do Registro mudando apenas a extensão. Por exemplo:

Coreldraw

%windir%\system.cor

%windir%\user.cor

Norton Utilities

%windir%\system.nu

%windir%\user.nu

Edit: A cada inicialização bem sucedida o Windows 9x faz o seu próprio backup de user.dat e system.dat, mas não me lembro agora se a extensão que ele coloca é .old ou .bak.

É por essas cópias que você deve procurar primeiro, por serem mais recentes. No prompt do DOS em %windir% eu faço assim:

attrib -h -r -s user.*
attrib -h -r -s system.*

dir system.*
dir user.*

Mas cuidado para não confundir backups de system.ini (sempre menores que 64KB) com os de system.dat (sempre bem maiores).

O Windows 9x também faz uma cópia ao terminar a instalação, mas apenas do arquivo System.dat. Essa cópia fica oculta como %systemdrive%\system.1st ("1st" significa "primeiro"). Eu cansei de consertar instalações do Windows 9x realmente bagunçadas simplesmente colocando esse arquivo no lugar de system.dat e reinstalando os drivers.

Este texto continua em Como editar "offline" o Registro do Windows.

Como verificar se uma atualização do Windows está instalada.

Esses procedimentos e dicas devem funcionar em todas as versões do Windows desde o Windows 2000, mas só testei no Windows 2000 SP4 e no XP.

Método 1 (baixa confiabilidade)

Verifique dentro do diretório %Windir%. Cada hotfix cria um sub-diretório oculto e comprimido.

O método tem baixa confiabilidade porque como esses sub-diretórios não são necessários para a operação do Windows (só são usados para desinstalar) e podem ocupar um espaço considerável na partição do sistema (no PC da minha irmã são 300MB neste momento), costumam ser apagados ou movidos durante uma manutenção. Se o diretório estiver lá, o HotFix está instalado. Se não estiver, pode estar instalado ou não.

Método 2 (alta confiabilidade)

Edit: Este método funciona mesmo que os updates tenham sido pré-aplicados usando o nLite.

Cada hotfix instalado cria uma chave sob:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\HotFix\

E também sob (no XP):

HKLM\SOFTWARE\Microsoft\Updates\Windows XP\

No Windows 2000:

HKLM\SOFTWARE\Microsoft\Updates\Windows 2000\

Edit: Segundo este artigo da MS, o caminho para as várias versões do Windows é:

HKLM\Software\Microsoft\Updates\[Sistema Operacional]\

Esta segunda chave tem mais informações e segundo o Process Monitor é a única das duas consultada pelo freeware WinUpdatesList, que ajuda bastante nessa verificação:

Como verificar um determinado Hotfix por arquivo batch

@ECHO OFF

ECHO.

ECHO Este exemplo verifica se o hotfix que

ECHO desabilita o Autorun esta instalado.

ECHO.

REG Query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\HotFix" | find /I "\Hotfix\KB951748" >NUL

If errorlevel 1 GOTO NOTFOUND

Echo Hotfix instalado

GOTO FIM

:NOTFOUND

Echo Hotfix Não instalado

:FIM

O trecho em azul deve ser digitado como uma única linha.

Substitua "KB951748" pelo Hotfix cuja presença você quer verificar, depois substitua as linhas "Echo Hotfix..." pelos comandos que você quer executar em cada caso.

Edit: Tenha em mente que, por exemplo, um hotfix criado quando não existia o XP SP3 e foi incorporado pelo mesmo não vai aparecer nas listas quando você procurar por ele no SP3.

O propósito da extensão .local

Na segunda parte da minha análise do vírus Wplugin apresentei duas questões que na época ficaram sem resposta:

• Por que o vírus criou um arquivo chamado "explorer.exe.local"?
  
• Como o vírus fez para a ws2help.dll infectada ser carregada no lugar da legítima?

Hoje eu descobri que as duas coisas estão relacionadas.

A extensão .local é um "redirecionador de DLLs". O conteúdo do arquivo é irrelevante (pode até ter zero bytes) e sua mera existência faz com que o Windows procure primeiro qualquer DLL chamada pela aplicação dentro do diretório da aplicação, mesmo que a aplicação declare um caminho explícito para a DLL.

No caso, o vírus colocou uma cópia infectada de ws2help.dll no mesmo diretório que explorer.exe e criou um arquivo explorer.exe.local. No próximo boot explorer.exe tentou carregar %windir%/System32/ws2help.dll, mas por causa da presença de explorer.exe.local, a cópia infectada foi carregada em seu lugar.

As DLLs listadas em KnownDLLs (veja no Process Explorer) não podem ser redirecionadas, mas infelizmente ws2help.dll não está nesta lista.

Talvez seja o caso de incluí-la :)

   

A MS finalmente permite desabilitar completamente o Autorun.

Atenção: Este post está em rascunho ainda. Estou liberando agora pois se trata de algo muito importante. Mas o texto pode mudar substancialmente .

Qualquer Power User Windows deve estar careca de saber que desabilitando o Autorun pelo método oficial da Microsoft (NoDriveTypeAutorun no Registro) ainda era possível ser infectado por um vírus de Autorun caso não se tomasse certos cuidados (que o usuário comum em geral não toma). Por isso o hack "@SYS:DoesNotExist" era usado, pois efetivamente fecha todas as brechas por onde o código malicioso apontado por Autorun ainda podia ser executado por imperícia/ignorância/descuido do usuário. Infelizmente esse hack, como visto no post anterior, tem efeitos colaterais.

Pois graças à preocupação mundial com a ameaça do Conficker a MS finalmente elaborou um patch que faz o Windows 2000/XP/2003/Vista/2008 respeitar completamente o desligamento do Autorun. Até onde pude apurar esse patch foi liberado em 24 de fevereiro, que é a data do respectivo Security Advisory. Segundo teste feito pelo US-CERT, esse patch tem exatamente o mesmo efeito do hack "@SYS:DoesNotExist" e (isso quem acrescenta sou eu) presumívelmente sem os efeitos colaterais.

O que fazer agora?

• Se você tinha aplicado o hack "@SYS:DoesNotExist", desative-o;
  
• Leia com atenção o Artigo 967715 da Knowledge Base . Lá você encontrará o link para o Hotfix correspondente à sua versão do Windows e o procedimento completo para desativar o Autorun. Se você deixa o seu Windows atualizar automaticamente (eu não deixo) você já tem o Hotfix instalado mas precisa seguir o procedimento manual de desligamento.
  

Multifuncional HP PSC1315: Setup não roda.

Este problema não está documentado no site de suporte da HP e impede a instalação de todas as impressoras das séries PSC1310 e Officejet 4200. É importante que você familiarize-se com ele, porque sua causa pode afetar outros programas.

A explicação curta: 

O acesso ao arquivo autorun.inf está sendo bloqueado por algum mecanismo de proteção anti-virus. Remova a causa e o setup rodará. Parece absurdo? Leia a explicação a seguir.

A explicação longa:

O cliente me telefonou porque não conseguia instalar sua PSC1315 no notebook (PC1). Ele havia baixado o driver do site da HP e setup.exe simplesmente não rodava, não importando o quanto se clicasse nele. Eu lembrei-o que ele tinha o CD original de instalação e disse que tentasse com ele. Mesmo problema.

Eu mesmo já havia instalado essa mesma impressora com o mesmo CD diversas vezes nesse mesmo cliente sem problema algum (quer dizer: tirando a enorme demora habitual para se instalar os "drivers" enormes da HP). Fui até lá para tentar resolver e constatei com o Process Explorer que setup.exe até começava a rodar, mas encerrava silenciosamente um segundo depois. Nenhuma mensagem de erro.

Parti para o mais complexo Process Monitor, mas nada no (longo) log de execução me deu qualquer pista útil (ou assim pensei) do que estava ocorrendo.

Desconfiado de que fosse algo no XP SP3, testei em outro computador do cliente onde eu instalei o SP3 do zero na mesma época que no notebook e o setup rodou (PC2), então não era o SP3. Testei num terceiro PC do cliente com o SP3 e também não rodou (PC3). Depois de apanhar muito tentando entender o que poderia haver em PC1 e PC3 mas não em PC2, joguei a toalha e disse ao cliente que iria pesquisar em casa. Decidi instalar os drivers no meu PC para analisar como deveria ser uma instalação bem-sucedida vista pelo Process Monitor e para minha surpresa, setup.exe também encerrava silenciosamente no meu PC (PC4).

Eu fiquei perplexo. Tentei encontrar algo em comum entre PC1, PC3 e PC4 que não estivesse também instalado no PC2 e não estava encontrando nada. Até que me deu um estalo: quando eu coloquei o CD no PC2 apareceu automaticamente o setup e naquele momento mesmo eu pensei que não deveria ter aparecido, porque neste cliente eu desabilitara o Autorun de todas as máquinas seguindo o hack "@SYS:DoesNotExist". Mas como eu estava ocupado com um problema mais importante, não dei muita atenção. Nota: mais tarde eu cheguei à conclusão de que esquecera de desabilitar o Autourun nesta máquina específica após uma reinstalação.

E no meu PC o Autorun também está desabilitado da mesma forma. Não fazia sentido porque eu estava executando o programa diretamente, mas como era minha única pista, reativei o Autorun no meu PC (apagando a chave HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf) para ver o que acontecia.

E o maldito setup.exe rodou como deveria.

Fui examinar o autorun.inf do CD da HP e as coisas começaram a fazer sentido. A maioria esmagadora desses arquivos tem no máximo umas quatro linhas e uns poucos tem uma ou duas dúzias por usarem funcionalidade avançada (que a maioria dos usuários ignora), mas a HP decidiu fazer de Autorun.inf o "INI" do instalador. O arquivo tem 996 linhas (Edit: o da Photosmart C4200 series tem 10932 linhas) de parâmetros/diretivas e se parece com isso:

[Version]

CDGuid={18E0918E-1060-48f3-925C-56C82E88551B}

SoftwareGuid={1A5C2933-7A90-41df-97E6-2845F67834D8}

InfrastructureDatabaseList=hpomdl03.dat

LanguagesInthisCD=enu,esn,fra,ptb

DefaultLanguageInThisRelease=enu

DIVISION=hpo

ICE_REV=03

FIRST_IO_REVISION=08

LAST_IO_REVISION=08

VCD_FILEVER=09

Manufacturer=HP

RegistryManufacturer=Hewlett-Packard

ProductSeries=All-In-One Series

Pre-Install=%ProgramFiles%%Manufacturer%

SilentInstall=No

PreloadICEEngineToGUIDFolder=hpzprl01.dat

PreloadRecoveryMechanism=hpzprl02.dat

Verifiquei a versão que se baixa do site e, claro, também tinha um autorun.inf do mesmo calibre.

O problema é que o mecanismo do hack "@SYS:DoesNotExist" se baseia justamente em redirecionar toda tentativa de acesso a autorun.inf. Como setup.exe não conseguia encontrar seus parâmetros, o programa era encerrado sem explicações.

Ainda intrigado, fui checar no Process Monitor se ele não era capaz de mostrar o problema. Armado com as informações que agora eu tinha e com a ajuda da função Localizar do PM (procurei por "autorun.inf") foi fácil achar, no meio dos 1249 eventos gerados por setup.exe antes de se encerrar, evidência de que com bastante atenção teria sido possível encurtar o diagnóstico:

Perceba que cada operação bem sucedida de leitura de autorun.inf é seguida por uma ou mais falhas ao ler algo sob a chave HKLM\Software\DoesNotExist\ no Registro. É lógico que não ajuda muito quando você não sabe que conteúdo deveria ter "DoesNotExist" e você ficaria ainda mais intrigado ao perceber que "DoesNotExist" realmente "não existe" em nenhum computador. Mas nesse caso específico uma rápida busca no Google por "HKLM\Software\DoesNotExist\" traria algum esclarecimento. 

É claro que estabelecer a ligação entre o erro e o bloqueio do Autorun não ajuda muito quando você sabe que ao clicar direto em setup.exe, autorun.inf não deveria ter qualquer efeito, mas pelo menos você estaria no caminho certo. Eu, pelo menos, apesar de achar sem sentido fiz o teste quando me vi sem opções e percebi (por outro caminho) a conexão. Lembre-se da famosa frase de Arthur Conan Doyle/Sherlock Holmes: "Quando você tiver descartado todo o impossível, o que sobrar, embora improvável, deve ser a verdade".

E agora você já pode ter em mente: Qualquer tentativa bem sucedida de ler um arquivo de configuração qualquer (INF, INI, etc)  seguida de tentativas fracassadas de ler uma chave no Registro pode ser culpa de algo sob a chave IniFileMapping do Registro.

Como se pode ver, o uso do hack "@SYS:DoesNotExist" tem efeitos colaterais que podem ser enlouquecedores. Por sorte, não são muitos os instaladores que "pervertem" a finalidade de autorun.inf como a HP fez e além disso surgiu recentemente outro modo eficiente de bloqueio do Autorun.

Sysinternals Process Monitor

Uma explicação que estou preparando para um problema curioso (e importante) requer que eu apresente antes mais essa ferramenta do genial Mark Russinovich. Se você acompanha o blog, já leu posts meus sobre outras duas criações dele praticamente indispensáveis: Process Explorer (PEx) e Autoruns.

Process Monitor (PM) é uma ferramenta bem mais técnica. Enquanto é perfeitamente possível mostrar a um leigo como tirar algum proveito de PEx e Autoruns (ainda assim, com ressalvas), para entender o PM você precisa ser pelo menos um power user.

O programa mostra, em tempo real, toda a atividade do Registro, do sistema de arquivos e de rede, indicando que processo/thread é o responsável. E não é pouca coisa. A quantidade de informação captada por segundo é tamanha que muita atividade (principalmente a "burocracia" do NTFS) já é pré-filtrada para tentar minimizar a bagunça. E por default o programa roda em modo Basic, porque o modo Advanced (Filter -> Enable Advanced Output) é ainda mais difícil de assimilar.

Por default, se você não acrescentar nenhum filtro, PM já mostra toda a atividade das suas aplicações e dos processos do Windows. Só o que o Explorer é capaz de fazer em um único segundo já é suficiente para dar um nó no seu juízo, por isso geralmente você vai filtrar para enxergar apenas a atividade de um processo/thread específico.

O básico que você precisa ter em mente para não se perder:

• Se você não criar nenhum filtro, PM mostra tudo, exceto as exclusões default;
  
• Se você criar filtros "exclude", PM continua mostrando tudo, exceto as exclusões default e as suas.
  
• Mas se você criar um único filtro "include" que seja, PM inverte seu funcionamento e considera que tudo é "exclude" por default, ou seja, só aparece o que você acrescentar como "include".
  

Por exemplo, para excluir o Explorer e visualizar todo o resto:

E para enxergar apenas a atividade do Chrome:

Cuidado: PM "lembra" dos filtros criados por você. É aconselhável clicar em RESET antes de criar novos filtros se você não quiser que nada seja excluído do log por acidente.

Dica: Familiarize-se com o menu de contexto do PM. O menu se adapta à linha/coluna onde você clicar com o botão direito, facilitando muito o trabalho de filtragem.

Dica: As opções acessíveis pelos botões não são atalhos para opções presentes no menu e são importantes. Familiarize-se com o efeito de todas elas.

Entender realmente o poder de Process Monitor requer prática e familiaridade com todas as suas opções. Explore o menu principal, o menu de contexto e os botões. Eu não vou nem tentar explicar cada função do programa, até mesmo porque eu só arranho a superfície ainda. Eu prefiro mostrar a utilidade dele através de exemplos práticos que virão em posts futuros. 

Como instalar o GpEdit.msc no Windows XP Home.

Eu já havia mencionado isso de passagem no meu último post sobre esse assunto, mas agora eu testei e comprovei que funciona.

O processo é explicado aqui, que vou reescrever do meu jeito. [05/10/09] A página do link não está mais disponível.

Coleta de arquivos no XP Professional

Vá na pasta %Windir%\System32\ e copie os seguintes arquivos:

• appmgmts.dll
• appmgr.dll
• fde.dll
• fdeploy.dll
• gpedit.dll
• gpedit.msc
• gptext.dll

Vá na pasta %Windir%\System32\GroupPolicy\Adm\ e copie os seguintes arquivos:

• conf.adm
• inetres.adm
• system.adm

Instalação manual No XP Home

• Crie a pasta %Windir%\System32\GroupPolicy\Adm\
• Copie os três arquivos .adm para esta pasta
• Copie os outros sete arquivos para %Windir%\System32\

Registre as DLLs:

regsvr32 gpedit.dll

regsvr32 fde.dll

regsvr32 gptext.dll

regsvr32 appmgr.dll

regsvr32 fdeploy.dll

Instalação automática

Eu organizei da seguinte forma em um pendrive:

WindowsSystem32GroupPolicyAdm <- Pasta com os três arquivos .adm
WindowsSystem32 <- Pasta com os outros sete arquivos
instalar.bat

Conteúdo de instalar.bat:

copy .\WindowsSystem32\*.* %windir%\system32\

MD %windir%\system32\GroupPolicy\Adm\

copy .\WindowsSystem32GroupPolicyAdm\*.* %windir%\system32\GroupPolicy\Adm\

regsvr32 /s gpedit.dll

regsvr32 /s fde.dll

regsvr32 /s gptext.dll

regsvr32 /s appmgr.dll

regsvr32 /s fdeploy.dll

É preciso executar como administrador, claro.

Variáveis de ambiente que vou usar com freqüência.

Isso é conhecimento básico do Windows (funciona assim desde o DOS), mas como eu vou fazer uma mudança brusca no meu modo de escrever, achei melhor deixar registrado aqui.

Se você abrir um prompt de comando no Windows e digitar o comando SET verá várias variáveis de ambiente que se referem a diretórios. 

• AllUsersProfile
  
• UserProfile
  
• APPDATA
  
• CommonProgramFiles
  
• ProgramFiles
  
• SystemDrive
  
• SystemRoot
  
• TEMP
  
• Windir
  

Estas estão presentes desde o Windows 2000.

Eu vou passar a usar esses nomes de variáveis em meus textos no lugar dos caminhos reais, usando o formato padrão. Por exemplo, vou passar a me referir ao diretório "system32" do Windows assim:

%WINDIR%\System32

Se você copiar e colar exatamente desse jeito na barra de endereços do Explorer ou na janela Executar e der ENTER, verá que o Explorer vai expandir a variável e abrir o alvo indicado. Também funciona exatamente assim em arquivos batch.

Motivos:

• Encurta o texto na maioria das situações;
  
• Independe do layout da instalação - Se eu colocar o caminho "c:\windows" e por algum motivo no sistema alvo o Windows estiver em D: é claro que não vai dar certo.
  
• Permite fazer atalhos que independem do nome do usuário corrente;
• Independe do idioma do Windows - %ProgramFiles% aponta da mesma forma para"C:\Arquivos de Programas" e "C:\Program Files"

Vou substituir os diretórios "hardcoded" por variáveis também à medida que eu for editando textos antigos.