Windows Explored

Everyday Windows Desktop Support, Advanced Troubleshooting & Other OS Tidbits

Archive for February, 2013

My Work Desktop

Posted by William Diaz on February 8, 2013

Pretty tidy, I say:


Five Windows workstation, and, yes (dread), that’s a Mac on the right. I don’t care for it. Yes, that’s Mr. Lebowski (the Dude) above monitor number 2. Above number 4 is the immortal Toshiro Mifune (Sanjuro).

Moving to the cubicle wall are some other immortal greats:


From left to right: Christopher Walken from Balls of Fury, Christoph Waltz from Inglorious Basterds, Big Brother from 1984 (he is always watching), Sugar from No Country for Old Men (by far the best villain ever), Cpt. James T Kirk (evil Kirk episode top), Walken again (ages gracefully), Michael Fassbender, also from the Basterds, Heston and the Apes from Planet of the Apes, Richard Burton from 1984 (there are five of him), and more Samurai Mifune.

Of course, reading material:


Haven’t gotten around to Windows Internals Part II yet. English Ales are the best. BJ’s is great, too. Beer!


Posted in Uncategorized | 2 Comments »

Vague Errors and No, You Can’t Be An Admin on Your Workstation

Posted by William Diaz on February 8, 2013

In real estate, its all about location, location, location. In today’s Windows workplace environment its all about security, security, security. Legacy apps present challenges because they want to do things that are not going to work in our environment. For example, this vague error when our user is trying to run an app:

Not a lot to go on but our helpdesk was able to get to work by running the app in an elevated state and I knew then that this app obviously wasn’t designed with security in mind. No doubt, the app was trying to modify one or more of its files that was in a location that was locked down by the secure Windows 7 file system. The user wanted to be admin to workaround it. “Sorry, but we can’t give you that kinda juice.” But we could likely change the security permissions on the file and grant Users the right to modify it … assuming that was the case. Taking a look with Process Monitor, I ran the app, set a filter for Access Denied on the file system and got the following:

Yep, legacy apps don’t care much for putting stuff inside C:\Windows, but this is bad practice today because standard user accounts will not have the necessary privileges to create and modify any files placed here. The workaround in this case (because the user insists they really need this app) was to change the security permissions of the files the app was trying to write to to give Users Modify permissions:


I wish they were all this easy.

Posted in Troubleshooting | Leave a Comment »

TEMP Profiles vs Username.domain Profiles

Posted by William Diaz on February 7, 2013

There is often confusion between the two. But knowing what each profile type means is an important step in understanding what is going wrong with the profile.

TEMP profiles

These are often created when the local profile and the roaming profile are not the same. For example, a user logs on to their normal workstation and as the local profile is compared against the roaming profile, some file is missing, or some folder or file security rights in either of the profiles have been modified that do not allow it to be read or written so that both the profiles cannot be merged. An example of mismatching profile can be found here.

Another cause of TEMP profiles is when a local profile file is opened (or gets “hooked”) by some system or application process before logon or during logon, preventing, for example, ntuser.dat from opening. An example of this can be found here; and you can also recreate this by remotely opening a handle to the ntuser.dat of any user profile by using the remote Registry > Load Hive in regedit and then trying to log on as that person on the workstation which you loaded their hive. I was both victim and the offender in this example here. In both these cases TEMP profiles protect the integrity of the local profile.

And finally, TEMP profiles are also created when the local user profile folder is renamed or removed but the registry profile remains intact. A registry profile on the affected system means the user has at some point logged on to that workstation but Windows cannot locate the folder profile defined in the ProfileImagePath string of the registry profile (more on that below).

Posted in Inside Windows | Leave a Comment »

Unable to Install (only some) ActiveX Controls

Posted by William Diaz on February 7, 2013

So, we had just validated our latest Windows 7 image and were looking forward to start rolling it out to the next batch of offices. Everything had seemed fine in testing until we hit a little snafu when a user complained that they were unable to access on online training tutorial that required the use of an ActiveX plug-in. Instead of asking the the user to install or run the ActiveX control, it redirected the user to a manual join method, which also failed. The manual join method was just another means of delivering the ActiveX control as a file that could be executed.

I was asked to look and was able to reproduce. This was odd because none of our previous Win 7 images exhibited the problem with this site, which validated that it was not a website issue. I also tested with another page that I knew contained an ActiveX control and was still unable to download the control. The file simply never made it to the system. Actually, I began to suspect that the fact that both sites were internal might be the issue because I was able to go out to the Internet and run a ActiveX test at and also buy visiting Adobe and running an install of Flash Player. So the question was why were some ActiveX controls downloading and others not?

the answer came the next morning when I realized that both ActiveX controls that could not be downloaded were coming from https, secure sites. I didn’t quite recall the setting or where it was (I knew I had come across this in the old WinXP days of Outlook when some users were unable to download calendar appointment files via https hyperlinks in emails) but I knew I could find it with a quick Process Monitor trace and the search phrase “SSL”.


The second hit provided my answer in HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\DisableCachingOfSSLpages. The value was set to 1, which meant it was enabled. The UI setting actually resides in the IE Internet Options Panel under the Advanced tab, Do not save encrypted pages to disk:


When checked, IE will not save files from secure sites to the computer.

As for how it got there, we suspect a Windows update may have enabled it at some point as the new image included several updates that the old image did not. As far as enforcing the setting via group policy to make sure it would not be enabled, this can be found under User Configuration > Admin Templates > Windows Components > Internet Explorer > Internet Control Panel > Advanced Page. This will create a new DWORD with a value of 0 in HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings.

Posted in Troubleshooting | Tagged: | Leave a Comment »