Em um Win7 x64 totalmente atualizado, de vez em quando o sistema trava por cerca de um minuto. Isso já vem acontecendo há alguns meses. Ao parar, quero dizer que o mouse responde e posso mover as janelas, mas qualquer janela, qualquer programa aberto, fica esbranquiçado quando eu o seleciono E nenhum programa novo será aberto. Não importa que tipo de programa seja. Quando o travamento parar, todos os cliques que fiz (abrir novos programas, por exemplo) terão efeito.
Nada aparece de forma consistente (como sempre que isso acontece) no log de eventos. Hoje consegui encontrar algo, mas não revela muito além do "sistema não respondia". É um 7009 para "Um tempo limite foi atingido (30.000 milissegundos) enquanto aguardava a conexão do serviço Windows Error Reporting Service."
Não importa se eu tenho algum plug-in de dispositivo USB ou não. Executei o Microsoft Security Essentials e o Malwarebytes.
Enquanto a máquina não responde, notei que a Unidade D (a outra partição no único HD interno deste laptop) é exibida assim no Explorer. Isso nunca ocorre com a unidade C ou qualquer outra unidade da máquina. 
.
Relatório SMART para a unidade fí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 suposto problema? 
Aqui está 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 tem menos de 1 ano. Eu tenho uma unidade com defeito? O diagnóstico do Seagate Tools diz que não há nada de errado com a unidade...
ATUALIZAR: notei que o serviço de relatório de erros do Windows entrou no estado de execução e depois no estado parado e o espaço entre os dois eventos foi de exatamente 2 minutos. Qual erro ele estava tentando relatar eu não sei. Eu verifico o "Monitor de Confiabilidade" e ele não mostra nenhum erro a ser relatado. Desativei o serviço de relatório de erros do Windows para ver se o problema foi resolvido.
Responder1
Com base nas novas informações que você forneceu, posso dizer que, de fato, não há problema algum. Então por que ele “fica off-line” por alguns segundos por até três minutos após suspender o sistema operacional convidado? Porque, como você disse, a luz LED do HDD permanece acesa enquanto a unidade não responde porque está sendo muito usada.
O que está acontecendo é que quando você termina de usar o VMWare e deseja suspender o sistema operacional convidado, você usa o recurso de espera ou hibernação em vez de desligar. Isso faz com que o VMWare copie o conteúdo da RAM da VM para o disco para que possa continuar de onde parou sem precisar inicializar tudo novamente. Dependendo de quanta memória você atribuiu à VM e de quanto estava sendo usado, isso pode significar que o VMWare precisa gravar muitos dados (gigabytes) no disco.
Quando o VMWare copia a memória para o disco, a unidade deixa de responder mais ou menos às novas operações do disco até que as operações atuais do disco (gravar a RAM em um arquivo) sejam concluídas. Como resultado, quando você abreMeu computador, o Windows tenta atualizar os dados, mas não consegue ler a unidade para buscar os dados necessários porque já existem todos aqueles comandos de gravação na fila esperando para acontecer. Portanto, ele o deixa vazio e parecendo offline 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 por um tempo ou irá abri-la e piscar na barra de endereço com uma barra de progresso verde, como acontece sempre que há uma operação demorada de arquivo ( como procurar milhares de arquivos).
Em resumo, não há nada de surpreendente ou misterioso nesta situação. Se, em vez de colocar um sistema operacional convidado VMWare em 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 consertar isso? Além de mudar para uma unidade mais rápida (ou usar uma unidade interna, se D:for externa), sua melhor aposta é desfragmentar a unidade. Se D:estiver muito fragmentado, quando o VMWare tentar liberar a RAM para o disco, isso fará com que ele se debatabastanteao gravar pedaços do arquivo gigante em áreas diferentes (é claro, isso pressupõe que não seja um SSD, que se D:ainda for uma partição na mesma unidade 0ST320LT007 C:, então não é).
Se você desfragmentar a unidade (assumindo que haja espaço livre suficiente), o sistema poderá gravar o arquivo RAM com apenas algumas operações de arquivo em grandes áreas (por exemplo, write 1GB of data at cluster X) em vez de muitas, muitas pequenas operações ( write 1MB here, write 245.18MB there, 4KB here, another 18.1MB somewhere else…) Então dormir a VM terminará muito mais rápido e a unidade responderá melhor.
Para descobrir exatamente qual é o acesso que está fazendo com que a unidade fique ativa e ocupada, você pode usar uma ferramenta comoMonitor de Processo. 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 interrompê-la assim que começar a inundar com o que provavelmente serão as operações de disco do VMWare.
Responder2
Os sintomas descritos são de fato endêmicos de uma má condução. Quando um disco não responde, o sistema espera por um período de tempo aparentemente imensurável antes de atingir o tempo limite e gerar um erro.
Dito isto, é curioso que isso pareça acontecer apenas com o D:volume (que você insinuou ser uma partição na mesma unidade física C:). Se fosse um problema de software (por exemplo, sistema de arquivos corrompido em D:), então não deveria estar acontecendo de forma intermitente, enquanto um problema de hardware poderia de fato acontecer de forma intermitente se, por exemplo, houvesse apenas alguns setores defeituosos no interior do prato e o sistema só ocasionalmente toca neles. Claro que você já disse que o HD Tune não relatou nada. No entanto, como você pensou, as unidades modernas realmente escondem setores defeituosos. Eles geralmente têm vários setores sobressalentes para os quais podem remapear setores defeituosos e, sim, fazem isso de forma transparente para que o sistema operacional não saiba sobre eles (além de informações genéricas via SMART).
Se oDadoscoluna está relatando dados brutos, então sim, 2.465 setores realocados é muito. Se isso acontecer apenas com D:, então os setores defeituosos provavelmente estarão agrupados no 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 estiver sendo usado para coisas como armazenar o tempdiretório e onde o sistema operacional ou programas fazem acesso ocasional a ele, entãopoderiaser um sistema de arquivos corrompido (é claro que você disse que executou chkdsk, entãodevenão seja).
Você pode verificar/confirmar se é um problema físico com sua unidade abrindo o Visualizador de Eventos ( eventvwr.exe) e verificando o Systemlog de eventos com umFontede Disk. Você pode fazer referência cruzada ao número do disco indicado noGerenciamento de DiscoSnap-in MMC ( diskmgmt.msc).
Responder3
O problema foi atribuído ao VMWare Player. Isso acontece imediatamente após algum tempo após o encerramento do sistema operacional convidado VMWare. Mais informaçõesaqui.
A solução no meu caso foi desabilitar o VMware Authorization Service. Este serviço só é necessário quando a máquina virtual precisa ser executada por não administradores.
Atualizar: Desativar o serviço de autenticação VMware E reativar o Application Experience Service (que desativei porque considerei desnecessário) resolveu o problema.
A unidade D: ainda fica “offline” por alguns segundos, mesmo depois de eu ter substituído o HD. Isso não deixa a máquina inteira sem resposta, apenas aplicativos específicos que dependem de dados armazenados em D: (como o Outlook, na minha configuração). Vou considerar o problema da unidade D: offline como um problema separado.
Responder4
Este é um problema difícil de diagnosticar a partir das informações que você forneceu (que eram muitas informações, não me interpretem mal). Uma maneira de diagnosticar isso como um problema de hardware é tentar recriar o problema com uma instalação do Linux, como por meio do wubi.
Já vi coisas semelhantes acontecerem quando há setores defeituosos no HD. Mas também vi problemas semelhantes devido a drivers defeituosos.
Você já tentou o CHKDSK e procurou setores defeituosos?