Win7 x64 non risponde per circa un minuto. HD in errore?

Su un Win7 x64 completamente aggiornato, ogni tanto il sistema si blocca per circa un minuto. Questo è successo da un paio di mesi. Con lo stallo intendo che il mouse risponde e posso spostare le finestre, ma qualsiasi finestra, qualsiasi programma aperto diventa bianco quando lo seleziono E tutti i nuovi programmi non si apriranno. Non importa che tipo di programma sia. Quando lo stallo si interrompe, tutti i clic che ho fatto (ad esempio, apri nuovi programmi) diventano effettivi.

Nulla viene visualizzato in modo coerente (come ogni volta che ciò accade) nel registro eventi. Oggi però sono stato in grado di trovare qualcosa, ma non rivela molto altro che il "sistema non rispondeva". È un 7009 per " È stato raggiunto un timeout (30000 millisecondi) in attesa della connessione del servizio Windows Error Reporting Service. "

Non importa se ho un plug-in di dispositivi USB o meno. Ho eseguito Microsoft Security Essentials e Malwarebytes.

Mentre la macchina non risponde, ho notato che Drive D (l'altra partizione sul singolo HD interno in questo laptop) viene visualizzato in questo modo in Explorer. Ciò non si verifica mai con l'unità C o qualsiasi altra unità sulla macchina. .

Rapporto SMART per l'unità fisica :

Leggi il benchmark di HD Tune 5 Pro, probabilmente il pezzo più avvincente del puzzle. Questo da solo non è abbastanza per vedere che c'è un problema con l'unità, indipendentemente dal fatto che la mancanza di risposta sia causata da tale presunto problema?

Ecco un breve rapporto sull'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

L'unità ha meno di 1 anno. Ho un disco difettoso? Diag di Seagate Tools afferma che non c'è nulla di sbagliato nell'unità ...

AGGIORNAMENTO : ho notato che il servizio di segnalazione errori di Windows è entrato nello stato di esecuzione, quindi nello stato di arresto e lo spazio tra i due eventi è stato esattamente di 2 minuti. Quale errore stava cercando di segnalare non lo so. Controllo "Monitoraggio affidabilità" e non mostra errori da segnalare. Ho disabilitato il servizio di segnalazione errori di Windows per vedere se il problema si interrompe.

Sulla base delle nuove informazioni fornite, posso dire che in realtà non vi è alcun problema. Quindi perché "non è in linea" per alcuni secondi fino a tre minuti dopo la sospensione del sistema operativo guest? Perché, come hai detto, la luce LED dell'HDD rimane accesa mentre l'unità non risponde perché viene utilizzata pesantemente.

Quello che sta succedendo è che quando finisci di usare VMWare e vuoi mettere in sospensione il SO guest, usi la funzione standby o ibernazione invece di spegnerti. Questo fa sì che VMWare copi il contenuto della RAM della VM sul disco in modo che possa riprendere da dove era stato interrotto senza dover ricominciare da capo. A seconda della quantità di memoria assegnata alla VM e della quantità utilizzata, ciò può significare che VMWare deve scrivere molti dati (gigabyte) sul disco.

Quando VMWare copia la memoria su disco, l'unità non risponde più o meno alle nuove operazioni del disco fino al termine delle operazioni del disco correnti (scrittura della RAM su un file). Di conseguenza, quando apri Risorse del computer , Windows tenta di aggiornare i dati ma non riesce a leggere l'unità per recuperare i dati necessari perché ci sono già tutti quei comandi di scrittura già in linea in attesa di accadere. Pertanto lo lascia vuoto e sembra non essere in linea fino a quando non riesce a scivolare in quelle richieste di lettura (tra le operazioni di scrittura di VMWare).

Se apri l'unità in Explorer, vedrai che o non lo aprirà affatto per un po ', o lo aprirà e lampeggerà la barra degli indirizzi con una barra di avanzamento verde come fa ogni volta che si verifica una lunga operazione sui file ( come cercare migliaia di file).

In sintesi, non c'è nulla di sorprendente o misterioso in questa situazione. Se invece di mettere un SO guest VMWare in standby, avessi appena copiato manualmente un file gigante sull'unità, i risultati sarebbero esattamente gli stessi.

Quindi cosa puoi fare per risolverlo? Oltre a passare a un'unità più veloce (o usarne una interna se D:è esterna), la soluzione migliore è deframmentare l'unità. Se D:è molto frammentato, quindi quando VMWare tenta di scaricare la RAM su disco, causerà un thrashing molto durante la scrittura di blocchi del file gigante in diverse aree (ovviamente supponiamo che non sia un SSD, che se D:è ancora una partizione sulla stessa unità 0ST320LT007 di C:, quindi non lo è).

Se si deframmenta il disco (supponendo che ci sia spazio libero sufficiente), allora il sistema può scrivere il file RAM con poche operazioni sui file in vaste aree (ad esempio, write 1GB of data at cluster X) invece di molti, molti piccoli interventi ( write 1MB here, write 245.18MB there, 4KB here, another 18.1MB somewhere else...) Poi la sospensione della VM finirà molto più velocemente e l'unità sarà più reattiva.

Per scoprire esattamente quale sia l'accesso che sta causando l'attivazione e l'impegno dell'unità, è possibile utilizzare uno strumento come Process Monitor . Eseguilo e fai clic sui filtri di classe per selezionare solo il filtro di classe di file come mostrato di seguito.

Ora puoi vedere a quali file e cartelle si accede. Assicurati di memorizzare il tasto di scelta rapida per avviare e arrestare l'acquisizione di attività ( Ctrl+ E) in modo da poterlo interrompere una volta che inizia a inondare con quelle che potrebbero essere le operazioni del disco da VMWare.

I sintomi descritti sono davvero endemici di una brutta pulsione. Quando un disco non risponde, il sistema attende un periodo apparentemente incommensurabile prima di scadere e generare un errore.

Detto questo, è curioso che sembra accadere solo al D:volume (che implicava una partizione sulla stessa unità fisica C:). Se si trattava di un problema software (ad esempio, file system corrotto attivo D:), non dovrebbe verificarsi in modo intermittente, mentre un problema hardware potrebbe effettivamente verificarsi in modo intermittente se, ad esempio, ci sono solo un paio di settori danneggiati all'interno del piatto e il sistema capita solo occasionalmente di toccarli. Ovviamente hai già detto che HD Tune non ne ha riferito nessuno. Tuttavia, come pensavi, le unità moderne nascondono effettivamente settori danneggiati. Di solito hanno un sacco di settori di riserva in cui possono rimappare settori danneggiati e sì, lo fanno in modo trasparente in modo che il sistema operativo non li conosca (oltre alle informazioni generiche tramite SMART).

Se la colonna Dati riporta dati non elaborati, sì, 2.465 settori trasferiti è molto. Se succede solo con D:, i settori danneggiati sono probabilmente raggruppati verso il centro del piatto dove la testa va a parcheggiare, quindi forse l'unità è stata spinta mentre l'unità si stava spegnendo / ruotando.

A cosa serve quel volume? Se viene utilizzato per cose come l'archiviazione della tempdirectory e tali in cui il sistema operativo o i programmi vi accedono occasionalmente ad esso, allora potrebbe essere un file system corrotto (ovviamente hai detto che hai eseguito chkdsk, quindi non dovrebbe essere).

È possibile verificare / confermare se si tratta di un problema fisico con l'unità aprendo il Visualizzatore eventi ( eventvwr.exe) e controllando il Systemregistro per gli eventi con una sorgente di Disk. È possibile eseguire il riferimento incrociato del numero di disco indicato nello snap-in MMC Gestione disco ( diskmgmt.msc).

Il problema è stato rintracciato in VMWare Player. Accade immediatamente dopo qualche tempo dopo l'arresto del sistema operativo guest VMWare. Maggiori informazioni qui .

Nel mio caso la soluzione era disabilitare il servizio di autorizzazione VMware. Questo servizio è necessario solo quando la macchina virtuale deve essere eseguita da non amministratori.

Aggiornamento : la disabilitazione del servizio di autenticazione VMware E la riattivazione del servizio Application Experience (che avevo disabilitato perché lo ritenevo non necessario) hanno risolto il problema.

L'unità D: rimane ancora "offline" per alcuni secondi, anche dopo aver sostituito l'HD. Questo non rende l'intera macchina non rispondente, solo applicazioni specifiche che dipendono dai dati memorizzati su D: (come Outlook, nella mia configurazione). Considero il problema dell'unità D: offline come un problema separato.

Questo è un problema difficile da diagnosticare dalle informazioni fornite (che erano molte informazioni, non fraintendetemi). Un modo per diagnosticare questo come un problema hardware è provare a ricreare il problema con un'installazione di Linux, ad esempio tramite wubi.

Ho visto cose simili accadere quando ci sono settori danneggiati sull'HD. Ma ho anche visto problemi simliar dovuti a driver difettosi.

Hai provato CHKDSK e scansionato per settori danneggiati?