 Jefferson,  05 de outubro de 2017,  manutençãoA resposta curta: Verifique se é possível escrever no diretório TEMP do usuário.
A resposta longa:
Era para ser uma operação de rotina. Encontrei o maldito gbplugin na máquina de um cliente e após pedir autorização, já que a máquina estava apresentando um comportamento estranho, dei boot com o Hiren’s Boot CD para removê-lo e nessa operação aproveitei para apagar o conteúdo dos diretórios TEMP da máquina e do usuário. Tudo rotina.
Ao terminar tudo funcionava, exceto o sistema comercial, que acusava “erro ao conectar ao banco de dados”. Testei acesso à internet e ao servidor e nada parecia errado. Por sorte esse sistema comercial pelo menos se dava ao trabalho de exibir uma mensagem de erro, que inicialmente eu não vira por ter ficado em segundo plano, com a única pista que eu tinha: Erro $2B27 “Unknown Internal Operating System Error” ao tentar inicializar a Borland Database Engine.
Eu pensei: “Como isso pode ter acontecido? Eu não mexi em nada relacionado ao BDE!”
Pedir ajuda ao “suporte” era impensável. Eles iam provavelmente dizer que eu tinha que formatar a máquina. Eu tinha um “plano B” na forma de um backup Trueimage da instalação que eu fizera em julho, mas conciliar esse backup com todas as mudanças nos últimos três meses ia levar horas.
Uma rápida pesquisa com o Google não me deu nenhuma informação útil. Fui executar o bdeadmin para ver se encontrava outra pista e a mesma mensagem de erro foi dada. OK, vamos reinstalar o BDE para ver se isso resolve. Fiz um backup do diretório e tentei rodar o instalador. Aí acusou um erro dizendo que não podia escrever no diretório TEMP do usuário. Fui checar com o Explorer o caminho indicado e a mensagem foi de que o diretório estava corrompido.
Ahhhhh…
De alguma forma, o Windows 7 do Hiren’s boot CD corrompeu o sistema de arquivos dessa instalação do Windows 8.1 x64. A única coisa que eu fizera de “diferente” foi mandar alguns arquivos para a lixeira em vez de dar o meu habitual CTRL-DEL.
Mandei rodar o CHKDSK. Aparentemente o dano foi grande, porque teve que reiniciar automaticamente três vezes para consertar. Na segunda vez o Windows estranhou (um caso de “mão direita que não vê o que a esquerda está fazendo”) e ativou o “Reparo Automático”, que nunca repara nada mesmo.
Mas após a terceira execução do CHKDSK aparentemente o problema foi resolvido.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 29 de setembro de 2017, manutenção, toolsA última vez que discuti esse assunto foi há 10 anos no G&G. Na época eu queria remapear uma tecla. Hoje eu precisei desabilitar uma e minha dica de 10 anos não servia.
Esta semana mais um notebook meu apresentou problema no teclado. Na maior parte do tempo não estava conseguindo digitar sequer uma palavra inteira sem interferência. Eu tinha certeza de que era uma tecla não-ASCII que estava disparando ocasionalmente, mas não tinha certeza de qual. Não adiantava usar teclado USB ou o teclado virtual.
O primeiro passo foi aproveitar um momento em que o teclado me deixou digitar uma sentença inteira para acessar este teste online, que me mostrou que era a tecla “Sel” que disparava ocasionalmente. Particularmente importante é o fato de que as teclas do teste permanecem destacadas mesmo após serem desacionadas, o que permite flagrar teclas que disparam sozinhas por uma fração de segundo, que era o meu problema. Se eu não tivesse conseguido digitar o bastante para acessar o site meu plano era criar um atalho para ele em outro computador e copiar esse atalho para um pendrive.
O segundo passo foi baixar e executar o programa Sharpkeys. Um substituto muito melhorado do Remapkey com pelo menos três funcionalidades inexistentes no utilitário da Microsoft:
- Permite mapear uma tecla para “nada”, efetivamente desabilitando-a;
- Oferece a possibilidade de você simplesmente apertar a tecla que deseja remapear/desabilitar para identificá-la. Você não fica limitado às teclas que estão listadas;
- A funcionalidade anterior oferece a possibilidade adicional de testar qual tecla não-ASCII está disparando sozinha. Basta executar o programa, ir até “type key” e esperar.
Note que toda mudança requer que você faça logoff. O Windows só confere os mapeamentos ao fazer login.
Apesar do autor dizer que você precisa estar usando Windows 2000, Windows XP, Windows Server 2003, Windows Vista, ou Windows 7, o programa deve funcionar também com todas as versões mais recentes do Windows. Eu conferi no Windows 8.1 x64.
Isso parece ter resolvido meu problema.
Coisas que o programa não pode fazer, segundo o autor, com alguns comentários adicionados por mim:
- Inverter as posições de duas teclas. Isto é: você não pode trocar a posição do Z com a do Q e esperar que as duas teclas ainda funcionem;
- Mapear um conjunto de teclas em uma tecla. Isto é: você não pode fazer com que apertar uma tecla qualquer tenha o resultado de um CTRL+C;
- Mapear cliques do mouse para teclas (óbvio);
- Suportar certas teclas de hardware que o Windows nunca “vê” como a maioria das teclas Fn (essa tecla geralmente só é “vista” pelo BIOS do notebook);
- Suportar mapeamentos diferentes para usuários diferentes. O mapeamento é para a máquina inteira;
- Proteger você de si mesmo. Se você desabilitar uma tecla essencial e não puder mais fazer login, vai ter que reformatar (não não vai. Isso é o que a maioria das pessoas acha. Basta fazer uma edição offline do Registro para apagar a chave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout), tendo em mente que CurrentControlSet pode ser três chaves diferentes.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 27 de setembro de 2017, manutenção, SegurançaEu comecei a reclamar disto há quase dois anos.
Na semana passada eu comecei a trabalhar com o suporte técnico de mais um sistema comercial e isso serviu para manter a impressão negativa que tenho de todos eles. Eu não tinha tempo nem saco para acompanhar tudo o que eles faziam nas máquinas do cliente mas o que pude ver ou conferir depois que eles terminaram já basta.
- Compartilharam o diretório inteiro do sistema comercial na rede com acesso escrita e leitura para TODOS;
- A aplicação deles foi configurada para rodar com privilégio de administrador no servidor. Pelo menos nas outras máquinas não foi;
- Eu dei acesso remoto via Anydesk em todas as máquinas mas em seguida instalaram o AMMYY e, como o AMMYY tem problemas com isso, desligaram o UAC. No servidor e no caixa. Acho que quem configurou o balcão foi outra pessoa porque não fez isso.
E tudo o que eu posso fazer é ficar contornando as bobagens que eles fazem para tentar garantir alguma segurança para a instalação.
Por que essas coisas me incomodam:
1: Notas fiscais, banco de dados e outros arquivos podem ser apagados por acidente ou maliciosamente por qualquer pessoa que sente na frente de um computador, com qualquer permissão de acesso. Qualquer ransonware meia boca em qualquer máquina pode criptografar o sistema inteiro e pedir resgate. Qualquer file infector rodando em uma máquina pode infectar os executáveis do sistema comercial e assim infectar todas as outras máquinas, etc, etc, etc. Estou acostumado a ver pior. Os “técnicos” de suporte saem compartilhando com permissões de escrita o diretório Arquivos de Programas e até partições inteiras incluindo as de sistema. No Windows XP você ainda flagrava isso só de abrir o explorer mas desde o Windows 7 a Microsoft deixou isso menos óbvio e é preciso executar com regularidade o comando net share para conferir se nenhum compartilhamento novo foi criado. Às vezes você só percebe quando está em outra máquina e nota os compartilhamentos extras aparecendo.
2: Quando uma aplicação precisa de privilégios de administrador ou o usuário vai precisar ser administrador ou vai ter que ter a senha de administrador, o que no final dá no mesmo. O ideal é que todos os usuários trabalhem no menor grau de permissão possível. Isso não impede a ação de ransonwares, mas esse não é o único problema de quem precisa dar manutenção;
3: Hoje, até eu que rodava o Windows 7 com UAC desligado para que ele não me enchesse o saco, acho perigoso.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 10 de setembro de 2017, manutençãoNão é exatamente uma tradução. É melhor que isso. Alguém cansou de quebrar a cabeça tentando descobrir qual era o equivalente no Windows em português para um serviço descrito numa ajuda em inglês e fez uma tabela de correlação.
Simplesmente traduzir não adianta. Por exemplo, a maioria dos tradutores recomendará você traduzir “engine” como “motor” (ugh!), mas a Microsoft, na minha opinião corretamente, traduz como “mecanismo”.
Assim, Basic Filtering Engine = Mecanismo de Filtragem Básica.
Já “Browser” tem a tradução questionável, que eu jamais adivinharia, de “Pesquisador”.
Eu não chequei todos os itens da tabela, mas os que eu vi estão corretos.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 30 de julho de 2017, manutençãoEste post servirá de auxiliar para outro em que estou trabalhando.
Quando você executa o Monitor de Desempenho do Windows (“Performance Monitor” – perfmon.exe) e tenta criar um novo conjunto de coletor de dados, não consegue passar do primeiro passo porque o botão Avançar está desabilitado (“greyed out”).
Isso pode acontecer por vários motivos mas no meu caso foi preciso criar uma pasta vazia chamada “PLA” com o caminho
C:\Windows\System32\Tasks\Microsoft\Windows\PLA
Outro motivos para isso acontecer:
- O serviço Agendador de Tarefas estar desativado;
- Você estar dando o mesmo nome que o de um conjunto existente. Mas este é meio óbvio porque basta mudar uma letra do nome para habilitar o botão.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 12 de julho de 2017, manutençãoEu ainda não estou certo de que tenha encontrado a causa, mas como esse erro vem me incomodando há meses acho melhor publicar pelo menos o pouco que sei sobre ele.
O erro ocorre quando você clica em “Proceed” no final do assistente de backup e o Trueimage vai começar a cópia.
Clicar em “Details” não fornece nenhuma informação útil e clicar em “Ignore” não adianta.
Eu uso o Trueimage há dez anos, desde que um erro de interpretação do funcionamento do Symantec Ghost (e a falta de um backup) me fez perder vários meses de trabalho. Eu nunca vira esse erro, que começou a ocorrer há poucos meses. E uso exatamente a mesma versão do Trueimage, gravada em um LiveCD. Não poderia ter sido corrompida. E supostamente não poderia haver interferência do software na máquina.
Uma vez eu consegui resolver simplesmente invertendo as portas SATA. Outra vez pareceu ser o local no meu HDD externo onde eu salvava o backup que influenciava. Outras vezes tive que desistir porque não conseguia de jeito nenhum. E nada que eu encontrei buscando no Google fez diferença.
Uma coisa havia em comum com todos os casos: só acontece numa das empresas que atendo. Mas em computadores diferentes onde antes o Trueimage funcionara.
Aí o problema aconteceu de novo hoje e eu resolvi experimentar algo. O fato de que “coincidentemente” todas as máquinas envolvidas rodam Windows 8.1 de 64 bits 100% atualizado (é meu único cliente assim) me deixou com uma pulga atrás da orelha. No meu post sobre os 480GB de arquivos que o Windows 10 apagou o leitor Eduardo me lembrou de que o Windows tem outras opções de desligamento ao se apertar o Shift. Desliguei a máquina apertando o Shift e o Trueimage funcionou!
Meia hora depois o problema se repetiu em outra máquina. Deixei o Windows iniciar e desliguei apertando o Shift. O Trueimage novamente funcionou!
Eu tenho experiência suficiente com Gremlins para saber que apenas duas ocorrências não são prova. Mas no momento eu tenho boas razões para crer que a hibernação de drivers do Windows 8.1 interfere com o hardware de alguma forma.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 12 de julho de 2017, manutençãoWindows 7 32 bits
Máquina reiniciando sozinha pouco depois de chegar à tela de login, acusando erro BSOD BAD_POOL_HEADER.
A primeira coisa que fiz foi rodar o MEMTEST86+. Depois de duas passadas sem acusar erro na RAM, parti para olhar drivers. Entrei no Modo de Segurança e ao ver o gbplugin na lista de drivers sendo carregados ele se tornou meu primeiro suspeito. Reiniciei por um LiveCD e deletei o plugin. Não adiantou.
Entrei no Modo de Segurança e desativeis os drivers de vídeo, rede e som. Não resolveu. Como no Modo de Segurança o problema não se manifestava eu já incluí o Avast na lista de suspeitos, porque ele instala drivers que não são carregados no Modo de Segurança. Mas continuei seguindo meu script.
Usei o MSConfig para desabilitar todos os serviços de terceiros, menos o AVAST. Nada.
Aí me ocorreu parar de chutar e verificar o que o BlueScreenView (outro software danado de útil da Nirsoft) podia me dizer sobre o problema. Entrei pelo Modo de Segurança de novo, rodei o software e a primeira coisa que vi me desanimou: o erro era provocado por ntkrnlpa.exe. Genérico demais. Mas ao rolar para a direita confirmei minha suspeita ao ver referências a aswSP.sys. Um driver de kernel do Avast.
Tentei desinstalar o Avast pelo Modo de Segurança mas acusou um erro e não prosseguiu. Mais uma confirmação de culpa.
Baixei e rodei o desinstalador da Avast, que acusou o mesmo erro no início mas prosseguiu e congelou no final do processo. Após esperar meia hora meti o dedo no reset e o problema foi resolvido.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 01 de julho de 2017, manutençãoEra uma operação corriqueira para mim. O HDD do cliente estava com defeito e foi comprado um novo que usei para reinstalar o Windows 10 completamente na máquina dele. Até tive o cuidado de fazer todas as atualizações para que ele não tivesse que passar por elas. Como se tratava de um computador Dell All-In-One sem uma porta sata extra eu retirei o HDD novo da máquina e o instalei juntamente com o antigo para copiar os 480GB de dados do cliente de um para o outro. Essa operação ocorreu sem maiores problemas apesar do defeito no HDD velho.
Ao reinstalar o HDD novo na máquina do cliente os problemas bizarros começaram. O primeiro foi uma nunca vista antes mensagem sobre um “RTC reset”. Fui olhar no setup mas data e hora estavam certos. O Windows 10 pareceu carregar normalmente depois disso, criei um novo usuário para o cliente e ao reiniciar a máquina fui surpreendido por múltiplos erros referentes a NTFS. Depois de umas três tentativas automáticas de reparar o Windows 10, a desagradável surpresa: tudo o que eu havia copiado para o cliente tinha sido deletado. Cada um dos diretórios e nada mais.
Como eu tinha ainda cópia dos dados isso não foi um desastre completo. Mas no dia seguinte o HDD velho do cliente já havia pifado de vez
Ainda não estou certo do que ocorreu. O Windows 10 estava hibernando quando tirei o HDD e eu não notei? Eu mandei desligar e ele hibernou? Eu não creio que tenha falado sobre isso aqui mas há quase uma década eu perdi arquivos por causa de hibernação e até tinha um aviso debaixo de meus notebooks: “saia da hibernação antes de remover esse HDD” justamente por causa disso. O Windows entra em hibernação com a memória conhecendo uma estrutura do disco e quando volta a estrutura é outra mas a memória é a mesma. Desastre certo. A mensagem sobre “RTC reset”? O BIOS dessa máquina é UEFI, que não goza do mesmo total isolamento do SO que o BIOS “legacy”. Quem sabe todas as maluquices que o SO pode provocar?
Ou foi algo relacionado com o problema que relatei em meu outro post?
Ainda é um mistério e tudo o que poso fazer é ampliar meus cuidados ao manipular arquivos de clientes e nessas operações envolvendo partições que tem o sistema operacional.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 01 de julho de 2017, manutençãoAlguns minutos atrás eu me deparei pela terceira vez com esse erro no meu desktop principal. Em nenhuma das vezes eu parei para olhar o motivo porque estava ocupado com outros problemas, bastava dar um reboot para aparentemente resolver e só acontecia imediatamente após alguma mudança no hardware. Eu suspeitei que fosse alguma corrupção naquele tal arquivo de hibernação de driver que a MS cria desde o Windows 8.
Eu acredito ter descoberto a real causa quando tentava manipular o conteúdo do HDD de um cliente que eu acabara de colocar na máquina. O Windows não me deixou apagar o arquivo pagefile.sys. Como eu queria fazer uma imagem do disco e os 12GB do arquivo iam deixar a imagem desnecessariamente grande eu reiniciei pelo Windows XP apaguei o arquivo e voltei.
O arquivo pagefile.sys estava lá de novo!
Depois de considerar algumas explicações mirabolantes me deu um estalo. Fui procurar o pagefile.sys que deveria estar no meu drive C: e como eu suspeitei, não estava lá.
Aparentemente o Windows 8.1 moveu automaticamente meu arquivo de paginação para outro HDD com espaço disponível quando percebeu o espaço livre na minha unidade C: cair. O erro KERNEL_DATA_INPAGE_ERROR então deve estar ocorrendo toda vez que eu substituo o drive que está com o meu pagefile.sys com o de outra máquina.
Espero que o Windows nunca tente fazer isso com o arquivo de hibernação (hiberfil.sys). Eu só consigo pensar em coisas muito ruins acontecendo por causa disso. E assim que eu puder vou reparticionar esse HDD para dar mais espaço para a unidade C:.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 19 de junho de 2017, manutenção, RedesNa semana passada eu comecei a ter um problema com várias contas de e-mail de um cliente para o qual eu também administro o domínio. O sintoma é o Windows Live Mail não conseguir baixar o último e-mail acusando um erro após 60s. Se o usuário clicar em “aguardar” fica permanentemente assim, mas se clicar em “parar” no próximo ciclo de coleta de emails o WLM baixa todos os que tiverem chegado nesse intervalo, menos esse último.
O código de erro, cujo número não lembro agora mas vou descobrir e registrar aqui, apontava para um possível problema no antivirus. Desinstalei o mesmo em uma das máquinas mas nada mudou.
Um mesmo usuário baixando de três contas diferentes podia ter o problema em apenas uma delas. E todos os usuários que baixavam da mesma conta tinham o mesmo problema (com uma curiosa exceção) logo não parecia ser problema no WLM.
Verificando via webmail eu constatei que o email que o WLM tentava baixar não aparecia na caixa postal.
Deletar a conta no servidor de e-mail e criar de novo resolvia o problema imediatamente, mas voltava no dia seguinte.
Como esse cliente estava há uma semana usando um acesso à internet de um provedor local porque a OI estava fora do ar e o erro sugeria ser ser algo causado por “interferência” no processo, eu suspeitei do provedor, mas não tinha como testar isso. Expliquei que eles iam precisar conviver com o problema por algum tempo e ficou assim por mais dois dias até a Telemar resolver o problema da linha. Eu estava ao telefone conversando com um dos usuários sobre o problema quando o acesso foi chaveado para a OI e o problema então “sumiu”.
Os usuários somente acreditaram realmente no que eu estava dizendo quando, dias depois, a OI cortou de novo a linha deles (está uma bagunça no bairro) e o problema imediatamente voltou quando o Load Balance chaveou para o acesso de backup.
Eu ainda não sei o que o provedor faz para provocar isso, até mesmo porque ele não respondeu a mensagem que mandei para ele perguntando se ele fazia alguma idéia do que causava o problema, mas se um dia eu descobrir registrarei aqui.
(Prefira clicar em "Responder" se estiver comentando um comentário)
|
|
.
Muito bom saber disso, BDE é uma caixinha de Pandora.
Mas um defeito que li foi “Windows 8.1”
Nessa empresa tudo foi instalado recentemente, com cópias legalizadas. Eu só podia recomendar entre o Windows 7 e o Windows 8.1 e não me vi recomendando o cliente a gastar milhares de reais em um sistema “saindo de linha”, que nem podia mais ser encontrado com facilidade no comércio.
E eu já estava usando o Windows 8.1 x64 há meses. Quando dá problema é muito pior que o Windows 7 para consertar, mas quando está funcionando é melhor que o Windows 7. Ao menos para mim.