Win7 x64 sem resposta por um minuto ou mais. HD falhando?

Question

Em um Win7 x64 completamente atualizado, de vez em quando o sistema fica parado por um minuto ou mais. Isso já dura há alguns meses. Ao parar, quero dizer que o mouse responde e posso mover as janelas, mas qualquer janela, qualquer programa que esteja aberto, fica branco quando eu o seleciono E nenhum novo programa será aberto. Não importa que tipo de programa seja. Quando a tenda parar, todos os cliques que fiz (novos programas abertos, por exemplo) entrarão em vigor.

Nada aparece de forma consistente (como sempre acontece) no log de eventos. Hoje, porém, consegui encontrar alguma coisa, mas ela não revela muito além do que "o sistema não estava respondendo". É um 7009 para " Um tempo limite foi atingido (30000 milissegundos) enquanto aguarda a conexão do serviço Serviço de Relatório de Erros do Windows. "

Não importa se eu tenho algum plug-in de dispositivos USB ou não. Eu executei o Microsoft Security Essentials e o Malwarebytes.

Enquanto a máquina não está respondendo, notei que o Drive D (a outra partição no HD interno único neste laptop) é exibido assim no Explorer. Isso nunca ocorre com a unidade C ou qualquer outra unidade na máquina. .

RelatórioSMARTparaaunidadefísica:

Leia o benchmark do HD Tune 5 Pro, provavelmente a peça mais reveladora do quebra-cabeça. Isso não é suficiente para ver que há um problema com a unidade, independentemente de a falta de resposta ser causada por esse problema?

Este é um breve relatório de hardware:

Computer:      LENOVO ThinkPad T520
CPU:           Intel Core i5-2520M (Sandy Bridge-MB SV, J1)
               2500 MHz (25.00x100.0) @ 797 MHz (8.00x99.7)
Motherboard:   LENOVO 423946U
Chipset:       Intel QM67 (Cougar Point) [B3]
Memory:        8192 MBytes @ 664 MHz, 9.0-9-9-24
               - 4096 MB PC10600 DDR3 SDRAM - Samsung M471B5273CH0-CH9
               - 4096 MB PC10600 DDR3 SDRAM - Patriot Memory (PDP Systems) PSD34G13332S
Graphics:      Intel Sandy Bridge-MB GT2+ - Integrated Graphics Controller [D2/J1/Q0] [Lenovo]
               Intel HD Graphics 3000 (Sandy Bridge GT2+), 3937912 KB 
Drive:         ST320LT007, 312.6 GB, Serial ATA 3Gb/s
Sound:         Intel Cougar Point PCH - High Definition Audio Controller [B2]
Network:       Intel 82579LM (Lewisville) Gigabit Ethernet Controller
Network:       Intel Centrino Advanced-N 6205 AGN 2x2 HMC
OS:            Microsoft Windows 7 Professional (x64) Build 7601

A unidade com menos de um ano. Eu tenho um disco defeituoso? O Seagate Tools diag diz que não há nada errado com a unidade ...

UPDATE : notei que o serviço de relatório de erros do Windows entrou no estado de execução, em seguida, o estado parado e o espaço entre os dois eventos foram exatamente 2 minutos. Qual erro que estava tentando denunciar eu não sei. Eu verifico o "Monitor de Confiabilidade" e não mostra erros a serem reportados. Desativei o serviço de relatório de erros do Windows para ver se o problema é interrompido.

    

Answer 1

Com base nas novas informações que você forneceu, posso dizer que não há problema algum. Então, por que “fica offline” por alguns segundos por até três minutos depois de suspender o sistema operacional convidado? Porque, como você disse, a luz do LED do HDD permanece acesa enquanto o drive não responde, porque está sendo muito usado.

O que está acontecendo é que, quando você termina de usar o VMWare e deseja adormecer o sistema operacional convidado, usa o recurso de espera ou de hibernação em vez de desligá-lo. Isso faz com que o VMWare copie o conteúdo da RAM da VM para o disco, para que ela possa continuar de onde parou sem ter que inicializar novamente. Dependendo da quantidade de memória que você atribuiu à VM e de quanto estava sendo usada, isso pode significar que o VMWare precisa gravar muitos dados (gigabytes) em disco.

Quando o VMWare copia a memória para o disco, a unidade fica mais ou menos sem resposta a novas operações de disco até que as operações atuais do disco (gravar a RAM em um arquivo) tenham terminado. Como resultado, quando você abre Meu computador , o Windows tenta atualizar os dados, mas não consegue ler a unidade para buscar os dados necessários, pois há todos os comandos de gravação já prontos para acontecer. Por isso, ele fica vazio e parece estar off-line até conseguir inserir essas solicitações de leitura (entre as operações de gravação do VMWare).

Se você abrir a unidade no Explorer, verá que ela não será aberta durante algum tempo ou será aberta e piscará na barra de endereço com uma barra verde de progresso, como acontece sempre que houver uma longa operação de arquivos (como procurar por milhares de arquivos).

Em resumo, não há nada de surpreendente ou misterioso nessa situação. Se, em vez de colocar um sistema operacional convidado VMWare no modo de espera, você tivesse copiado manualmente um arquivo gigante para a unidade, os resultados seriam exatamente os mesmos.

Então, o que você pode fazer para corrigir isso? Além de mudar para uma unidade mais rápida (ou usando uma unidade interna se D: for externo), sua melhor opção é desfragmentar a unidade. Se D: é muito fragmentado, quando o VMWare tenta liberar a RAM para o disco, ele faz com que ele gire muito enquanto grava partes do arquivo gigante em diferentes áreas (claro que isso é assumindo que não é um SSD, que se D: ainda é uma partição na mesma unidade 0ST320LT007 como C: , então não é).

Se você desfragmentar a unidade (supondo que haja espaço livre suficiente), o sistema poderá gravar o arquivo RAM com apenas algumas operações de arquivo em grandes faixas (por exemplo, write 1GB of data at cluster X ) em vez de muitas, pequenas operações ( write 1MB here , write 245.18MB there , 4KB here , another 18.1MB somewhere else …) Em seguida, dormir a VM terminará muito mais rápido e a unidade responderá melhor.

Para descobrir exatamente o que o acesso está fazendo com que a unidade esteja ativa e ocupada, você pode usar uma ferramenta como Process Monitor . Execute-o e clique nos filtros de classe para selecionar apenas o filtro de classe de arquivo, conforme mostrado abaixo.

Agora você pode ver quais arquivos e pastas estão sendo acessados. Certifique-se de memorizar a tecla de atalho para iniciar e parar a captura de atividades ( Ctrl + E ) para que você possa pará-lo quando começar a inundar o que provavelmente serão as operações do disco da VMWare.

    

Answer 2

Os sintomas descritos são de fato endêmicos de um mau impulso. Quando um disco não responde, o sistema aguarda por um tempo aparentemente incomensurável antes de expirar e lançar um erro.

Dito isso, é curioso que isso só pareça acontecer com o volume D: (que você sugeriu ser uma partição na mesma unidade física que C: ). Se fosse um problema de software (por exemplo, sistema de arquivos corrompido em D: ), ele não deveria estar acontecendo de forma intermitente, enquanto um problema de hardware poderia acontecer intermitentemente se, por exemplo, houvesse apenas alguns setores defeituosos o prato e o sistema só ocasionalmente tocam neles. Claro que você já disse que o HD Tune relatou nenhum. No entanto, como você pensou, as unidades modernas realmente escondem setores defeituosos. Eles costumam ter um monte de setores sobressalentes que eles podem remapear setores defeituosos e sim, eles fazem isso de forma transparente para que o sistema operacional não sabe sobre eles (além de informações genéricas via SMART).

Se a coluna Data está reportando dados brutos, então sim, 2.465 setores relocados é muito. Se isso só acontece com D: , então os setores defeituosos são provavelmente agrupados em direção ao centro do prato onde a cabeça vai estacionar, então talvez a unidade tenha sido empurrada enquanto a unidade estava desligando / girando.

Para que esse volume está sendo usado? Se ele está sendo usado para coisas como armazenar o diretório temp e tal, onde o sistema operacional ou programas fazem acesso ocasional a ele, então poderia ser um sistema de arquivos corrompido (é claro que você disse que correu chkdsk , então não deveria ser)

Você pode verificar / confirmar se é um problema físico com sua unidade abrindo o Visualizador de Eventos ( eventvwr.exe ) e verificando o System log para eventos com uma Origem de Disk . Você pode fazer referência cruzada ao número de disco indicado no snap-in Gerenciamento de disco do MMC ( diskmgmt.msc ).

    

Answer 3

O problema foi rastreado até o VMWare Player. Isso acontece imediatamente após algum tempo depois que o sistema operacional convidado VMWare é desligado. Mais informações aqui .

A solução no meu caso foi desativar o VMware Authorization Service. Este serviço só é necessário quando a máquina virtual precisa ser executada por não administradores.

Update: Disabling the VMware auth Service AND re-enabling the Application Experience Service (which I had disabled because I deemed it unecessary) solved the problem.

The D: drive still goes "offline" for a few seconds, even after I have replaced the HD. This doesn't render the entire machine unresponsive, only specific applications that depend on data stored on D: (like outlook, in my config). I'm going to consider the D: offline drive issue as a separate issue.

    

Answer 4

Este é um problema difícil de diagnosticar a partir das informações que você forneceu (o que foi muita informação, não me entenda mal). Uma maneira de diagnosticar isso como um problema de hardware é tentar recriar o problema com uma instalação do Linux, como o wubi.

Eu vi coisas semelhantes acontecerem quando há setores defeituosos no HD. Mas eu também vi problemas semelhantes devido a drivers defeituosos.

Já experimentou o CHKDSK e procurou setores defeituosos?