I'm having a strange lockup issue with my girlfriend's laptop. I think the drive might be dying, but I'm not entirely sure.
Obligatory spec: Win7, Core 2 Duo, 3GB DDR2, 1TB SATA HDD, latest BIOS + drivers.
Checked clean for malware using MS Security Essentials, as well as with a manual sweep on
Symptoms are as follows:
- The app she's currently working with (can be anything, but Firefox / VLC seem to be more common) locks up. Anything intensive tends to cause the problem more.
- At first, the rest of the OS remains responsive, disk access light lights up full.
- Any sound being played stops.
- Makes no crunching noise as would be normal with heavily active mechanical drives, don't think the drive is actually doing much. No nasty clunks or usual failure sounds.
- Shortly after (maybe ~5s) the whole UI on the system locks up. NumLock + CapsLock are still working, so I don't think the CPU is at fault.
- After a while (usually 30s+) the system comes back, seems fully responsive. No obvious changes to system stats.
- Task manager and process explorer don't show any notable increase in page faults, disk queue length, CPU usage, etc. for locked process or system in general.
- SD card was being used for ReadyBoost, removing it temporarily seemed to reduce frequency and severity of lockups, but it seems to be back to its old tricks again. Maybe a red herring / confirmation bias?
- Pressing keys during lockup doesn't result in them getting posted to the message queue, or the queue gets trashed before the machine unlocks.
- Event log shows a few delayed write failures, but they're localised to times where she's done hard shutdowns due to The Sims and other games locking up. Looks unrelated to these issues.
I'm guessing a system thread is getting stuck, perhaps on doing a swapfile write. I tried using
procdump on Firefox and VLC with a lockup trigger, to see where the hang occurred, but it seems that the dump gets interrupted when the system freezes, making it unreadable.
I'd like to not have to go through the hassle of setting up WinDbg and remote kernel debugging to capture this issue. Any ideas?