Windows 7: Missing System Restore Points

I was using Windows 7 with System Restore (Start > Run > SystemPropertiesProtection.exe) turned on for drive C only.  It was set to allocate 16GB of the drive to store System Restore points.  Yet it was storing only two such points.  Clicking "Show more restore points" did not increase the number. 

By way of background, I was not running a dual-boot system and had been making daily backups.  Recently, I had been making those backups manually by running "start "" SystemPropertiesProtection.exe" in a daily batch file, so that I could watch the situation.  (The purpose of the empty internal quotes ("") was to provide a null argument.  It probably wasn't necessary in this case; it seemed to be helpful sometimes.)  Previously, I had been using a VBS script triggered by a Task Scheduler entry.  I had also not rebooted recently.  According to Moo0, at this particular time my system had been up for nearly three days, but my only restore points were from within approximately the past 24 hours.

This problem seemed to have many possible causes.  Glancing through a list of potential fixes provided on a website oriented toward Windows XP, I saw a reference to Event Viewer (Start > Run > eventvwr.msc).  I was not very familiar with that, so I ran a search and found a suggestion to focus on VSS entries.  VSS stood for Volume Shadow Copy or Volume Snapshot Service.  The basic idea was that VSS would allow Windows to make a copy of a file even if that file was in use, which would be the situation for some Windows 7 system files while the system was running.  Apparently System Restore used VSS.  The suggestion was, in other words, to see what Event Viewer would say about VSS-related problems.  To do that, I went into Event Viewer > Filter Current Log > Event Sources > VSS > OK.  This gave me a list of items.  (Later -- see below -- I saw that I had taken incomplete notes here.)  I clicked on the Date and Time column heading to get the most recent ones.  These were all Information-level notices.  They were all the same:  "The VSS service is shutting down due to idle timeout."  This did not seem relevant to my problem.  VSS was running.  I was getting System Restore points.  They were just being deleted prematurely for some reason.

Another suggestion was to check Services (Start > Run > services.msc) to verify these settings:  Volume Shadow Copy = manual or automatic; Task Scheduler = automatic; Windows Backup = manual or automatic.  Again, these suggestions seemed irrelevant, since the restore points were being made.  In any case, they were set correctly on my system.  Along with those suggestions, though, was a worthier one:  go back into Event Viewer and look for System Restore entries with Event ID numbers 8194, 8195, 8196, or 8198.  Of these, the ones that seemed most likely to be relevant were 8195 (System Restore Deactivated) and 8198 (Restore Point Deleted).  A search focusing on 8198 did not turn up anything immediately obvious, so I shelved it for the moment.  In Event Viewer, I sorted by clicking on the Event ID column.  It took a while to sort.  It showed no errors anywhere near 8194 to 8198.

A seemingly related suggestion was to run Task Scheduler (Start > Run > taskschd.msc) > Task Scheduler Library (left pane) > Microsoft > Windows > System Restore > select an item in the top pane > History tab (middle pane).  There didn't seem to be a relevant item in the top pane, but I just clicked on something.  I saw that the History tab said "History (disabled)."  A search yielded the suggestion that I go into Task Scheduler's right pane > Enable All Tasks History.

One obvious suggestion was to make sure I had ample space on my drive for the System Restore points.  In Windows Explorer > right-click > Properties > General tab, drive C showed only 2.1GB free on an 80GB partition.  I was not sure whether that included what I had already allocated for System Restore points.  To figure this out, I wanted to see the size of the System Volume Information folder, which was where Windows 7 stored those points.  In Windows Explorer > right-click > Properties, System Volume Information was shown as having size zero.  To change that, I followed the suggestion to go into Properties > Security tab > Edit > Add > Administrators > Check Names > OK > Full Control > OK.  This gave me an error:

Error Applying Security

An error occurred while applying security information to:

C:\System Volume Information\WindowsImageBackup

Acesss is denied.

I got recurring messages like that.  At some point, I clicked Cancel.  I got a warning that I should Continue to avoid inconsistencies, but there was no option to Continue.  The box was now showing Full Control despite the error message.  It now reported that the System Volume Information folder had a size of 6.45 GB.  That roughly agreed with System Restore, which was reporting that my Current Usage was 6.10 GB.  I had made one or two more restore points; System Restore said I now had four.  I reduced the size allocated to System Restore from 16GB to 12GB and took another look at the Properties for drive C.  It still reported 2.1GB free.  So apparently the space allocated for System Restore was not marked as unavailable until it was actually used; the allocation was just a ceiling for System Restore, telling it when to start jettisoning old restore points.  As long as I remembered to exclude the System Volume Information folder from drive image backups (so as to prevent those backups from being unnecessarily inflated), there did not seem to be any particular drawback to allocating large amounts of space, just in case I would want to have access to historical backup points.  As a side note, it occurred to me that it might be possible to archive such points.  I could have experimented with making a ZIP copy of the contents of System Volume Information, to see if System Restore would work from a restored ZIP.

The next day, now that I had enlarged drive C, it showed plenty of space.  System Volume Information was back to showing zero bytes, so I repeated the steps above.  This time I went all the way through, clicking Continue until it stopped asking.  It only asked a half-dozen times.  Properties was still showing only about 6.6 GB allocated.  I still had only those restore points that had been made in the last 24 hours.  Disk space was not the issue.

It seemed that I must have overlooked something in Event Viewer.  I couldn't tell, from these notes, which part of Event Viewer I had examined the previous day.  Evidently I had selected something in the left pane in order to get the Filter Current Log option.  Maybe I had selected the wrong thing.  I saw, now, that the original suggestion was to click Windows Logs > Application in the left pane.  Filtering there for VSS still produced no errors numbered around 8194 to 8198.  Instead of filtering for VSS, I went to the top of the list and clicked "All Event Sources."  That produced nothing -- maybe it was still calculating -- so I changed the top line, "Logged," to "Last 7 days."  Sorting by the Event ID column, I saw an 8193 item (created restore point) but no indications that any restore points had been deleted.

I had rebooted in order to change the size of the partition.  Maybe restore points were being deleted during reboots?  I didn't plan to reboot during the next day or more, so I decided to let it sit another day and then take another look.  This time, I had the same restore points, now going back two days, plus some new ones.

Over the next several days, my restore points accumulated.  Apparently I had fixed something.  Rebooting may or may not have been removing them previously; if so, that was no longer happening.  At the time when I was writing these words, the system had been up for only about one day, but the available restore points stretched back almost a week.

So now I had an opportunity to distill a lesson from these remarks, because my secondary computer was doing the same thing.  It was keeping restore points going back only a day or two.  So what had I done to fix the problem?  I wasn't sure.  I went back through some of the foregoing steps.  First, I closed System Restore.  I went into System Volume Information > right-click > Properties > Security tab > Edit > Add > Administrators > Check Names > OK > Full Control > OK.  I clicked Continue through a half-dozen error messages.  I went back into System Restore (i.e., Start > Run > SystemPropertiesProtection.exe > select drive C > Configure > reserve 10GB > OK.  It was 6GB before; it was possible (but seemed unlikely) that that was the problem.

I let it go for a few days.  The problem was solved.  I was now getting restore points going back several days and surviving reboots.

Ubuntu 10.04 & Windows Dual-Boot: Customize GRUB2 Boot Menu

I had a dual-boot machine with Windows XP and Ubuntu 10.04 (Lucid Lynx) on it.  I wanted to clean up and customize the GRUB menu that came up whenever I booted the system.  There were several parts to this.

I started with The Grub 2 Guide.  The Guide's point 6, "Adding Entries to Grub 2," said that files named 10_linux and 30_os-prober would search for installed Linux kernels and other operating systems.  I typed this:

cd /etc/grub.d
ls

and, sure enough, I had files called 10_linux, 20_memtest86+, 30_os-prober, and 40_custom, along with 00_header and 05_debian_theme files.  There seemed to be useful ways to change several of these items, so I went down the list in numerical order, starting with 10_linux.  I typed "sudo gedit /etc/grub.d/10_linux."  The thing to do here was to stop GRUB from listing Recovery Mode options in the startup menu.  I did a Ctrl-F to see if 10_linux contained this line:

GRUB_DISABLE_LINUX_RECOVERY=true

It didn't appear to have that, so I added it near the start of the file, right before the first "if" statement.  That was all for 10_linux, so I saved and closed it.  Now, how about controlling the menu so that it wouldn't list older kernels?  At this point, I thought about going with their "Building a Totally Customized Menu" option.  But the Grub 2 Guide said that a fully customized menu would not be updated with the addition of any new kernels.  The reason seemed to be that I would make 10_linux non-executable, so it would no longer go sniffing around to see what's new.   I didn't want to have to mess with updating the list manually every time a new kernel came along.  For guidance, I looked to the Grub 2 Title Tweaks Thread.  That, and the Grub 2 Guide, led to the following approach:

uname -r
sudo update-grub
ubuntu-tweak

The "uname" command told me what kernel I was now using.  At present, that was 2.6.32-22-generic-pae.  The "sudo update-grub" step told me what else was being listed on the Grub menu.  There was the option of seeking out other kernels in Synaptic, but running ubuntu-tweak (available via Synaptic, if you have the right repository) gave me an easier way of removing older kernels.  In Ubuntu Tweak, I went to Applications > Package Cleaner > Unlock > Clean Kernels.  This showed all installed kernels other than the one currently in use.  They said it was a good idea to keep one previously working kernel, so I skipped the first one on the list and checked the others.  Then I clicked Cleanup.  Ubuntu Tweak did its thing, and then I closed it.  It turned out there was another way to do this, that didn't require the Ubuntu Tweak step:  just tell 10_linux how many kernels to display.  This method required me to type "sudo gedit /etc/grub.d/10_linux" and then search for the place that had these two lines:

list=`echo $list | tr ' ' '\n' | grep -vx $linux | tr '\n' ' '`
done

and change it by inserting another list line between those two:

list=`echo $list | tr ' ' '\n' | grep -vx $linux | tr '\n' ' '`
list=`version_find_latest $list`
done

I found that right at the end of the 10_linux file.  So I made that change and then saved and closed 10_linux.  Next, I didn't want memtest+ to appear in the GRUB menu list, so I typed this:

sudo chmod -x /etc/grub.d/20_memtest86+

I looked for a quick way to confirm whether a file was executable, but there didn't appear to be an option for that in chmod, and the first several webpages I tried in response to a Google search didn't tell me.  Moving on, GRUB on my laptop had gotten confused, and it now pointed to two different Vista installations, only one of which was working.  The Grub 2 Title Tweaks Thread said I could hide it, but it seemed like I should also be able to remove it.  It seemed like a bad idea to have it hanging around.  Here's how those lines looked in GRUB:

Windows Vista (loader) (on /dev/sda1)
Windows Vista (loader) (on /dev/sda2)

The first one was not working.  If I hit it, I got "Disk error.  Press any key to restart."  I actually had to power down the laptop to get past that.  I didn't yet have a very well configured Ubuntu setup on the laptop, so I rebooted with a GParted CD (an Ubuntu Live CD would have worked too).  In GParted, I looked at sda1 and, well, no wonder it was showing up.  I had a Windows XP installation on a hidden partition in there!  I'd had some troubles installing Vista on the laptop, and apparently I had decided to keep the WinXP installation just in case.  So, OK, that was interesting.  I could have tried to rejigger the setup so that I'd have a triple boot system, but I didn't plan to be using XP very often on the laptop, and I could use GParted within Ubuntu (once I finished tweaking the laptop) to hide and unhide as needed.  For now, what I needed to do, in the GRUB menu, was to change the entry so that it would report the situation more informatively.  I typed this:

sudo cat /boot/grub/grub.cfg | grep "menuentry" | cut -d '"' -f 2
sudo gedit /etc/grub.d/30_os-prober

The first line gave me the current list of GRUB menu entries from grub.cfg (in case I hadn't already written down the names I wanted to change).  Precisely what I wanted to change was the first of the two "Windows Vista (loader)" entries.  So:  around the middle of 30_os-prober, I found this:

for OS in ${OSPROBED} ; do
  DEVICE="`echo ${OS} | cut -d ':' -f 1`"
  LONGNAME="`echo ${OS} | cut -d ':' -f 2 | tr '^' ' '`"
  LABEL="`echo ${OS} | cut -d ':' -f 3 | tr '^' ' '`"
  BOOT="`echo ${OS} | cut -d ':' -f 4`"
  if [ -z "${LONGNAME}" ] ; then
    LONGNAME="${LABEL}"
  fi

Following their advice, I could have changed those last three lines to five lines that read as follows:

  if [ "${LONGNAME}" = "Windows Vista (loader)" ] ; then

    LONGNAME="Windows XP (hidden)"

  elif [ -z "${LONGNAME}" ] ; then

    LONGNAME="${LABEL}"

  fi

In this case, unfortunately, both of those items were named "Windows Vista (loader)," so I figured they would both change to "Windows XP (hidden)."  What I needed had to be more specific, so instead I left their last three lines unchanged and added this after them:

  if [ "$LONGNAME" = "Windows Vista (loader)" ] && [ "${DEVICE}" = "/dev/sda1" ] ; then

    LONGNAME="Windows XP (hidden)"

  fi

And that worked.  The one other thing I wanted to change was to get GRUB to remember which operating system choice I had used last time, and default to that one again this time unless I selected something else.  In previous Ubuntu installations, the steps I had taken to do that had been to type "sudo gedit /etc/default/grub"; change one line to say GRUB_DEFAULT=saved instead of GRUB_DEFAULT=0; save and close that file; and then type "sudo update-grub."  But now I saw this in the Grub 2 Guide:  "The default OS will not be set merely by an interactive selection of an OS from the menu."  So that was apparently a change from Grub 1.5, or whatever I had been using previously.  So now, one option was to set up a custom menu, except that it wouldn't be updated for the latest kernels.  But then, confusingly, the Grub 2 Basics seemed to say that there was a simple solution after all.  I typed "sudo gedit /etc/default/grub" and made sure it said that "GRUB_DEFAULT=saved" and I also added a line right after that (since there wasn't already a line for this):

GRUB_SAVEDEFAULT=true

So I saved that, typed "sudo update-grub," and watched as it generated its list.  It looked like it was only going to show one Linux image, but I reserved judgment and rebooted.  Sure enough (speaking, here, of the desktop computer on which I had been making most of these changes), GRUB now showed only two items:  the latest Ubuntu kernel and Windows XP.  I chose Windows, the second of the two items.  I hit Enter and immediately hit F8, in the theory that Safe Mode would load faster than Normal Mode.  I guess it did, but it still wasn't in a hell of a hurry.  I clicked "Turn off computer" > Restart and watched to see if GRUB would remember that I had just booted Windows, not Ubuntu.  It did.  Excellent.  That seemed to be working.  I chose Ubuntu instead and rebooted again.  This time it went into Ubuntu.  Likewise, on the laptop, after some tinkering, sudo update-grub eventually produced the desired list, and it remembered the last boot too.