Windows Explored

Everyday Windows Desktop Support, Advanced Troubleshooting & Other OS Tidbits

Archive for April, 2013

Check Your IE Bitness

Posted by William Diaz on April 26, 2013

Not too long ago we began to see a rash of IE problems when trying to install or run various ActiveX controls and plugins. Often, there was no literal error, the ActiveX control would just try to install again after revisiting the page, often indicating that it was successfully installed, but then only fail to run. We would initially troubleshoot by running IE elevated because standard users could not install ActiveX controls. The odd thing was that this always resolved the issue temporarily, so long as we left that session of the browser opened. Once closed, the problem resumed. Eventually, after much head scratching, we realized that the affected users Internet Explorer pinned in the Taskbar was pointing to C:\Program Files\Internet Explorer but when we would troubleshoot, we were elevating from the proper C:\Program Files (x86)\Internet Explorer folder since we are a 64 bit shop now. The question still remain, though, how the IE shortcut pinned to the taskbar was getting its path changed to the 64 bit version of IE. Since most, if not all the users, were recent Windows 7 migrations, we are guessing something went funky in the task sequence.


Even after writing this it still didn’t occur to me that IE Bitness was again the issue when encountering a Java error in IE for a Citrix published app.

Manually logging into the server confirmed that Java was installed and working. It didn’t come to me that IE might be running in the wrong bitness until after I looked at the HKU\S-1-5-21…SID\Software\ key of the user profiles on the Citrix box and saw that the JavaSoft key was not being created. A script was used to launch the app and went something like this.

Option Explicit
Dim WSHShell, objNet, strusername, IE
Set WSHShell = WScript.CreateObject("WScript.Shell")
Set objNet = WScript.CreateObject("WScript.Network")

On Error Resume Next

Call openIE()

Sub openIE()
     Set IE = CreateObject("InternetExplorer.Application")
     ie.Navigate “http://www.someplace.html”
End Sub

The InternetExplorer.Application object in a 64 bit OS will launch the 64 bit version of IE since the OS will default to the 64 bit wscript engine. To work around this, force the 32 bit wscript engine:


Sub Main()
Force32bit()’Need to call IE 32Bit
    Dim objExplorer : Set IE = CreateObject("InternetExplorer.Application")
    IE.Navigate “”
End Sub

Sub Force32bit()
     If InStr(UCase(WScript.FullName), "SYSTEM32") > 0 Then
          Dim objShell : Set objShell = CreateObject("WScript.Shell")
          objShell.CurrentDirectory = "C:\Windows\SysWOW64"
          objShell.Run "wscript.exe " & WScript.ScriptFullName, 1, False
     End If
End Sub

Posted in Troubleshooting | Tagged: | Leave a Comment »

Random Workstation Hangs

Posted by William Diaz on April 26, 2013

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.

Posted in Troubleshooting | Tagged: | Leave a Comment »

A Failure To Print

Posted by William Diaz on April 16, 2013

We saw a rash of complaints in one of our offices where users were unable to print to any HP printers. They would contact the helpdesk, they would delete the printer and add it back again but the issue kept returning after the initial successful print. The was no error message but the print balloon in the notification area would not indicate a printed job was sent to the printer while at the same time the print icon appeared in the notification area showing 0 pending jobs in the print queue. In the past, I had seen this in isolated instances, and it can be resolved by

  • First removing the printer (or printers if they share the same print driver, .e.g. HP Universal Print Driver)
  • Stopping and restarting the print spooler (CMD > net stop spooler > net start spooler)
  • Opening the Print Management console (Control Panel > Administrative Tools)
  • Opening All Driver
  • Select the driver package for the problem printer > right-click Remove Driver Package. This has the effect of removing the print drivers from the Windows driver file repository (64 bit Windows – C:\Windows\System32\DriverStore\FileRepository) and deleting the registry key that’s holds the various values for the driver package (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Drivers\Version-3\HP Universal Printing PCL 5 (v5.4))
  • Reconnecting to the printer. This would download the print drivers from the print server to the file repository and install them locally into C:\Windows\System32\spool\drivers\x64.

To try and determine what was causing this to occur, I asked the local office tech to contact me when he encountered another user with the same issue so I could compare the drivers in spool\driver and the file repository folders on the problem workstation with those on a behaving workstation for the HP universal print driver package but everything looked identical. Next, I compared the registry key of the two workstations and spotted the problem.

On the problem workstation:


On the working workstation:


As a proof of concept, I deleted the data for the Dependent Files value, rebooted the workstation and was able to reproduce the issue. Manually importing the missing registry data then corrected. The other two values affected are Help File and Monitor. The why of why this is happening is not fully known but there is some further discussion about the issue here:


After seeing another rash of this outbreak in another office, I encountered issues trying to remove the HP Universal Printing PCL 5 (v5.4) package from the Print Management console:


Not sure why, but the print spooler hooks one of the print driver files after it restarts. To remove the hook, got to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Print Processors\ and delete the key that corresponds to the print driver you are trying to remove, .e.g hpcpp118, stop and restart the print spooler, then remove the driver package from the Print Management Console.



This should be resolved with KB3001232

Posted in Uncategorized | Tagged: | Leave a Comment »