Recently in Windows Vista Category

Here's a weird problem: At one point I switched Control Panel from the Category view to the Classic view (i.e., icons).  After that, Control Panel wouldn't load any more -- it would crash Explorer instantly.

Turned out the problem was a corrupt folder-view entry in the Registry.  I went to HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell and deleted Bags and BagsMRU.  All was well again.

I ran into a problem with a solution this weekend while preparing to burn a DVD to bring to my parents over the Thanksgiving weekend: Seems that CD/DVD burners attached to a Silicon Image SATA interface aren't recognized as burners in Windows Vista.

The good news: Microsoft knows it's a problem and has a hotfix available for it immediately.  (They've had this hotfix out for some time, as a matter of fact.)  Said hotfix will also appear in Vista SP1, but you can grab it now from the download link listed here.

Today after I switched on my computer, Vista pinged me and let me know there was a download available that solved some previously-logged system issues.  Said download is detailed in Knowledge Base article 941649, and the rundown of items in it is extremely interesting.  Here's some selected quotes.

• "Extends the battery life for mobile devices."  This has been a common canard for Vista users, hasn't it?  My own experiences with battery life, through my Sony VAIO TX series notebook, have been very good, but I know the mileage has varied enormously.
• "Improves the stability of wireless network services."  I take this to mean it addresses the common issue people have where Vista has trouble locating a wireless network for a minute or so on end when you first boot up or after you come out of sleep mode.
• "Shortens the startup time of Windows Vista by using a better timing structure."  This hasn't been a huge problem for me, but I'm curious to see how it plays out across multiple systems.
• "Improves the reliability of Windows Vista when you open the menu of a startup application."  I wonder if this is a cousin to a problem I wrote about elsewhere before.  Vista does try to mitigate resource usage between multiple applications that boot through the Startup folder (read this article on the Microsoft Vista Compatibility Team Blog for more information), but they could still do a better job with it.
• "Shortens the recovery time after Windows Vista experiences a period of inactivity."  I think I have experienced this problem myself before, mostly when coming up out of a screen saver (another fix explicitly described in this package).

All in all, it's heartening to see these things being addressed before Vista SP1. I'll have another report later about how these fixes play out on my machines.

[Note: An earlier version of this tip had some inaccuracies which were brought to my attention.  Thanks to Ed Bott for his keen eye!]

[Note #2: Ed's published a blog entry about this issue, and some additional notes that are well worth reading -- including a super-useful link to a tip on how to customize the way the Disk Cleanup tool runs.]

This is actually not an indictment of Vista alone, but something I've seen in Windows for quite some time now: the user profile \TEMP directory.  It fills up with the most amazing amount of trash imaginable, and over time it can cause programs to malfunction left and right in ways that defy analysis.

Vista does have a way to deal with it: the Disk Cleanup tool. which purges the \TEMP directory on demand.  However, as a safety measure, it doesn't delete anything newer than one week -- for instance, temporary files created as part of a program's installation process.

If you want to manually purge the \TEMP directory without the date cutoff restriction -- just blast everything in there -- here's one way to do it.  Copy the following into a text file with a .BAT extension:

rd /s /q "%localappdata%\temp" && md "%localappdata%\temp"

(That's all one line, by the way.)

When run, it'll erase the entire contents of the TEMP directory and then recreate it anew.

Two caveats:

1. If there are any files that are in use in the directory, they will not be deleted.
2. As hinted above, do not run this command when you're in the process of installing software, such as before a reboot to finalize a program installation.  It may delete components of the installer that are needed after the reboot.  (Note that if you attempted to install a program and the installer failed and left garbage in the \TEMP directory, it might not be a bad idea to purge all of that before attempting to re-run the installation.  Just make sure the installer is not actually running before attempting this!)

Not long ago I posted about using the Reliability and Performance Monitor tool to figure out where all that disk-bashing was coming from in Vista.  After some feedback from people "in the wild" and some work on my own, I've found the two biggest sources of unexpected disk activity are:

1. The defrag application running in the background, and
2. Volume Shadow Services.

The latter is the one most people are not immediately aware of.  I've noticed that VSS kicks in on a notebook when you bring it up out of hibernation or sleep mode, and it's been off for a long enough period of time that a new shadow copy repository is about due to be created.  When this happens, you see a lot of disk activity that doesn't seem to be related to anything -- and, as I've found, if you start doing regular work with the computer, it doesn't seem to affect performance very much, since VSS runs at a lower I/O priority than most other things.  (The same goes for defrag.)

Here's how I figured it out: the next time I fired up my notebook and saw the disk bashing, I used the R&PM to single out disk activity and sort it by writes, and looked at the File column.  Sure enough, the file in question was one of the shadow-copy repositories (found in the hidden C:\System Volume Information directory).  You could turn off System Restore to prevent this behavior, but to me, that's kind of self-defeating -- especially since System Restore and shadow copies have saved my bacon more than a few times.

As it turns out, the scheduling for how System Restore runs is now controlled in Vista by -- you guessed it -- the Task Scheduler.  A default task is created for creating System Restore points, and I'm going to look into seeing if there's some way to tweak how it's triggered so that it works better with my particular habits.