Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

On a fully updated Win7 x64, every so often the system stalls for a minute or so. This has been going on for a couple months now. By stalling I mean the mouse responds and I can move windows around, but any window, any program, that is open becomes whiteish when I select it AND any new programs will not open. It doesn't matter what kind of program it is. When the stall stops all clicks I made (open new programs for example) take effect.

Nothing shows up consistently (as in every time this happens) in the event log. Today though I was able to find something, but it doesn't reveal much other than the "system was unresponsive". It's a 7009 for "A timeout was reached (30000 milliseconds) while waiting for the Windows Error Reporting Service service to connect."

It doesn't matter if I have any USB devices plug-in or not. I've ran Microsoft Security Essentials and Malwarebytes.

While the machine is unresponsive, I've noticed that Drive D (the other partition on the single internal HD in this laptop) is displayed like this in explorer. This never occurs with Drive C or any other drive on the machine. how drive D shows up in explorer in explorer.

SMART report for the physical drive: SMART report

Read benchmark by HD Tune 5 Pro, probably the most telling piece of the puzzle. Isn't this alone enough to see there is a problem with the drive, regardless of whether the unresponsiveness is caused by such purported problem? read benchmark by HD Tune 5 Pro

Here is a short hardware report:

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

The drive less than 1 year old. Do I have a defective drive? Seagate Tools diag says there is nothing wrong with the drive...

UPDATE: I noticed that the windows error reporting service entered the running state then the stopped state and the space between the two events was exactly 2 minutes. Which error it was trying to report I don't know. I check the "Reliability Monitor" and it shows no errors to be reported. I've disabled the windows error reporting service to see if the problem stops.

share|improve this question
I doubt it is the HDD. I've never seen, or heard of, anything like this, but I seriously doubt your HDD is defective. However, it is possible that it is on it's way out, especially since it's a hard drive, and it's a year old. Whether or not it is the cause of this problem, is unlikely. Again, your HDD should be fine – Sylvester the Cat Oct 31 '12 at 2:20
That read benchmark graph does NOT look normal, @Sylvester – Gaia Oct 31 '12 at 2:24
That graph wouldn't load, so I had to base the comment on what I read, which is why I didn't bother posting it as answer. When I get home (home internet has no filters), I will look at graph and repost EDIT: I'd have thought it was just something (i.e. application) causing it to hang. I had a hard time imagining that you would be able to do all that based only on the code currently loaded in RAM without loading more – Sylvester the Cat Oct 31 '12 at 2:30
SMART data indicates it is reallocating sectors, a sign of a failing drive. – Moab Oct 31 '12 at 2:55
Its pretty clear based on the S.M.A.R.T data the hdd is reallocating sectors, which is what causing your problem, I would replace the hdd. I had a similar problem although the drive was much older, I had similar performance problems, resulted in near total failure and unreadable sectors ( which cause the hdd to shutdown if read ). – Ramhound Nov 5 '12 at 17:45
up vote 1 down vote accepted

Based on the new information you have provided, I can say that there is in fact no problem at all. Then why does it “go offline” for a few seconds for up to three minutes after suspending the guest OS? Because as you said, the HDD LED light stays lit while the drive remains unresponsive because it is being heavily used.

What is happening is that when you finish using VMWare and want to sleep the guest OS, you use the standby or hibernation feature instead of shutting down. This causes VMWare to copy the contents of the VM’s RAM to disk so that it can resume where it left off without having to boot up all over again. Depending on how much memory you have assigned to the VM and how much was being used, this can mean that VMWare has to write quite a lot of data (gigabytes) to disk.

When VMWare copies the memory to disk, the drive becomes more or less unresponsive to new disk operations until the current disk operations (writing the RAM to a file) have finished. As a result, when you open My Computer, Windows tries to refresh the data but it cannot read the drive to fetch the needed data because there’s all those write commands already in line waiting to happen. Therefore it leaves it empty and looking like it’s offline until it can manage to slip in those read requests (between VMWare’s write operations).

If you open the drive in Explorer, you will see that either it will not open it at all for a while, or it will open it and flash the address bar with a green progress bar like it does whenever there is a lengthy file operation (like searching for thousands of files).

In summary, there is nothing surprising or mysterious about this situation. If instead of putting a VMWare guest OS into standby, you had just manually copied a giant file to the drive, the results would be exactly the same.

So what can you do to fix it? Aside from changing to a faster drive (or using an internal one if D: is external), your best bet is to defragment the drive. If D: is very fragmented, then when VMWare tries to flush the RAM to disk, it will cause it to thrash around a lot while writing chunks of the giant file to different areas (of course this is assuming it’s not an SSD, which if D: is still a partition on the same 0ST320LT007 drive as C:, then it’s not).

If you defragment the drive (assuming that there is sufficient free space), then the system can write the RAM file with only a few file operations in large swaths (e.g., write 1GB of data at cluster X) instead of many, many little operations (write 1MB here, write 245.18MB there, 4KB here, another 18.1MB somewhere else…) Then sleeping the VM will finish much faster and the drive will be more responsive.

To find out exactly what the access is that is causing the drive to be active and busy, you can use a tool like Process Monitor. Run it and click the class-filters to select only the file-class filter as seen below.

Now you can see what files and folders are being accessed. Make sure to memorize the hotkey to start and stop activity capturing (Ctrl+E) so that you can stop it once it starts flooding with what is likely to be the disk operations from VMWare.

Screenshot of Proccess Monitor with only file class filter active

share|improve this answer
D: is a SSHD hybrid, new, fast and internal. It is fully defragged because I copied the contents from the old drive to the new one in a way that it doesn't clone the fragments. Also, it happens for shorter periods of time regularly, regardless of VMware usage (which BTW is a 2gb virtual HD with 1GB RAM). I have noticed that the hiccup is a short one (non vmware related) and my external is plugged in, D only comes back online after the external drive makes a noise (sounds like the head is parking) I really wish there was something I could run to log what is going on when these failures happen – Gaia Aug 28 '13 at 7:22
Like I said, if the HDD LED is on, then the drive is active. If it is being heavily used, then it will be unresponsive, that’s just how it works. I’ll add some info on figuring out what the access is. – Synetech Aug 29 '13 at 14:47
Did you find out what the file accesses were? – Synetech Aug 29 '13 at 19:47

The described symptoms are indeed endemic of a bad drive. When a disk is unresponsive, the system waits for a seemingly immeasurable amount of time before timing out and throwing an error.

That said, it is curious that it only seems to happen to the D: volume (which you implied was a partition on the same physical drive as C:). If it were a software issue (e.g., corrupt file-system on D:), then it should not be happening intermittently, while a hardware issue could indeed happen intermittently if for example there are only a couple of bad sectors towards the inside of the platter and the system only occasionally happens to touch them. Of course you already said that HD Tune reported none. However, as you thought, modern drives do indeed hide bad sectors. They usually have a bunch of spare sectors that they can remap bad sectors to and yes, they do this transparently so that the OS does not know about them (other than generic information via SMART).

If the Data column is reporting raw data, then yes, 2,465 relocated sectors is a lot. If it only happens with D:, then the bad sectors are likely grouped towards the center of the platter where the head goes to park, so maybe the drive got jostled while the drive was shutting down/spinning up.

What is that volume being used for? If it is being used for things like storing the temp directory and such where the OS or programs make occasional access to it, then it could be a corrupt file-system (of course you said you ran chkdsk, so it should not be).

You can check/confirm if it is a physical problem with your drive by opening the Event Viewer (eventvwr.exe) and checking the System log for events with a Source of Disk. You can cross-reference the indicated disk number in the Disk Management MMC snap-in (diskmgmt.msc).

Bad Disk event in Event Viewer

Corresponding disk number in Disk Management snap-in

share|improve this answer
(Yes, that’s XP’s Event Viewer, but Windows 7 shows the same info for drive-access errors; it’s just more annoying to access because the 7 Event Viewer is slower and more cluttered.) – Synetech Oct 31 '12 at 4:54
Yes, D: is a partition of the same physical drive as C:. I have programs in C and data in D. Filtering the evento log does bring up nearly 4000 events for disk, but they are all "The driver detected a controller error on \Device\Harddisk1\DRXX" or "An error was detected on device \Device\Harddisk1\DRXX during a paging operation.". None of them include the string Harddisk0, which would be the ID for the primary drive. Woudn't the drive firmware make the reallocated sectors invisible to the OS anyways? – Gaia Oct 31 '12 at 11:22
CHKDSK found only some unused index entries and unused security descriptors to clean up. No bad sectors – Gaia Oct 31 '12 at 11:26
If it is mentioning the controller, then what could be happening is that the cable is loose (common with SATA cables). Of course it doesn’t explain why it only happens with D:, but it is a simple check and fix to rule it out. Do you have any external/flash/USB drives or memory cards connected? I find I get problems like that whenever I have a flash drive connected to a specific USB port through an obviously flaky extension cable. – Synetech Oct 31 '12 at 17:32
If it’s still doing it with a new drive, it’s likely a problem with the controller or cable. I’ve had flaky drive behavior like this due to the cable being incompletely inserted into the drive/motherboard connectors. (I’ve never had this happen with IDE, only SATA because the design is incredibly poor.) Make sure the cables are fully inserted at both ends and are not being pushed on by something else. If it still doesn’t work, then the motherboard’s SATA controller is probably faulty, but try each connector (when IDE channel 2 of an old motherboard, I was able to keep using it with channel 1). – Synetech Aug 22 '13 at 19:01

The problem has been traced down to VMWare Player. It happens immediately after on some time after VMWare guest OS is shut down. More info here.

The solution in my case was disabling the VMware Authorization Service. This service is only needed when the virtual machine needs to be run by non administrators.

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.

share|improve this answer
Ah, so you had disabled the Application Experience service? You should have said that in the first place! (I’m kidding; you had no way of knowing that it was related.) But seriously, disabling that service causes Windows to deny access to some files for some time. It seems to be related to Security Essentials in some way, presumably that SE depends on it and when it is disabled, it can’t scan an (executable) file, so it keeps the file locked until some lengthy timeout period elapses. That does fit your symptoms. For the record, you probably don’t need to disable the VMWare Auth service. – Synetech Aug 24 '13 at 14:57
@Synetech i confirmed the VMWare Auth service is unnecessary. i already have a lot of necessary stuff running. And yes, Application Experience did leave some EXEs locked for a period of time. – Gaia Aug 24 '13 at 18:33
Yes, it’s unnecessary when you’re not running VMWare, but you don’t have to disable it; you can set it to manual (it’s really annoying that you have to manually start it since VMWare won’t start it automatically ಠ_ಠ). Either way, what I meant was that it isn’t causing the problem, so simply running Application Experience would fix it even if VMWare Auth is still running. – Synetech Aug 24 '13 at 19:38
the stalling still occurs, though less frequent and only when i shut down vmware. could it be related to a very large file (2gb+) being accessed? – Gaia Aug 25 '13 at 0:40
Do you have an LED that shows disk activity? If so, look at it. I suspect that when you shut down VMWare, it does a bunch of clean up which includes a lot of disk activity (writing RAM to disk, etc.) In fact, this would be a lot worse after shutting down than while the guest OS is actually running. Does it still happen if you wait a long time after VMWare has shut down (e.g., go for lunch and come back)? – Synetech Aug 25 '13 at 3:15

This is a hard problem to diagnose from the information you provided (which was a lot of info, don't get me wrong). One way to diagnose this as a hardware problem is to try to recreate the problem with an install of Linux, such as through wubi.

I have seen similar things happen when there are bad sectors on the HD. But I have also seens simliar problems due to faulty drivers.

Have you tried CHKDSK and scanned for bad sectors?

share|improve this answer
HD tune reports no bad sectors. I haven't ran CHKDSK recently, but I have ran it since the problem started. – Gaia Oct 31 '12 at 2:34
I ran CHKDSK and it gave me no errors at all. I believe that the disk subsystem would hide errors from CHKDSK anyways, no? – Gaia Nov 5 '12 at 17:04
Not for bad sectors, there is no way around them because the hardware can't write or read and hence no hiding is possible. – Mikhail Nov 6 '12 at 6:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .