A user recently complained to me of application hangs. After pressing her, it turns out the entire workstation was hanging randomly and after some time would return to normal. I often refer to these as “soft hangs”, a hang in which the workstation-OS eventually recovers from (opposite a “hard hang” in which the system has halted and needs to be restarted with manual “button-intervention”). Often, this is caused by an excessively large disk queue that needs to be handled or a processor hog. Looking at the Windows Event Viewer under the System logs, I noticed an error on the primary storage device. I sorted the logs by the Source and could see that this had been happening practically everyday. The error was reported as “The device, \Device\Ide\iaStor0\, did not respond within the timeout period.” with an Event ID of 9 and source of iaStor:

Furthermore, she had complained of the issue before with her previous workstation before it was swapped out for the current one so I also decided to look at her previous workstation and noted the same daily errors. Both workstations were of the same model. With that, I decided to setup Event Forwarding for this error and saw that ALL workstations of the same model were reporting the this error. Some quick research pointed me to a known issues with the Intel Array Storage Technology (aka Rapid Storage) and SSDs that do not support one of its features known as Link Power Management.

To resolve

1. Go to HKLM\System\CurrentControlSet\Services\iaStor\Parameters\Portn, where n=the hard disk (often Port0 for the primary storage). If the key Portn does not exist, create it*.
2. Create the following DWORDS with a value of 0: LPM, LPMDSTATE, DIPM.

Since we have hundreds of these, a group policy preference was used to target the PC model hard drives affected (via wmi query) and push the reg hack firm wide. Afterward applying, the errors went away.

*The existence of the Portn key depends on the driver version of the Intel Array Storage driver. Version 10 and higher does not require the existence of the keys and values to enable LPM, only to disable.

We started to see a rash of complaints from users who were encountering a black screen after logging onto their Windows 7 workstations. Except for the mouse cursor nothing else was functional, even the Task Manager couldn’t be started.

Most often this was encountered at the first logon of the day after the workstation has been logged out of the previous day and then left idle for several hours. Recovery required that a hard reboot was performed, and afterwards the user could logon normally. I actually encountered this a few times on one of my test workstations and a review of the event logs reveals the following warning message: “The wnlogon notification subscriber < GPClient > is taking too long to handle the event notification event (StartShell).”

I’m assuming the StartShell is explorer.exe. In a couple cases, if I let it sit long enough, the desktop might load or the TM would launch, but the overall experience was plagued by various performance issues and errors. A corresponding event follows after 10 minutes: “The winlogon notification subscriber < GPClient > took 600 second(s) to handle the norification event (StartShell).”

A brief email to our Microsoft PFE was answered with possible hotfix described here: http://support.microsoft.com/kb/2590550. Results since applying to affected user workstations seems to be promising.

If this doesn’t apply to you, there is also a Mark Russinovich blog on a similar issue he was encountering due to inaccessible mapped drives.

And, finally, another MS Hotfix-KB that you may also want to take examine: http://support.microsoft.com/kb/2525332