Creating a Bootable Windows 7 USB Drive for Installation / System Repair / Recovery - First Cut

Normally, if I booted a computer from a Windows 7 installation DVD, I could get into System Recovery Options (e.g., Startup Repair, System Restore, Command Prompt) that would let me run various diagnostics.  Unfortunately, my laptop did not have a CD/DVD drive.  So if I wanted to see those Windows 7 startup repair options, it seemed that I would have to find a way to do so by booting the computer from a USB flash drive instead.  This post describes the steps I took to develop a USB drive that would give me those options.  It also incidentally describes how to make a bootable copy of the Windows 7 installation DVD on a USB drive.

One approach was to put the entire Windows 7 installation DVD on a USB drive.  The DVD contained about 3GB of material, so this would require a USB drive of 4GB or larger.  Another approach was to put just a Windows 7 System Repair or Recovery CD on a USB drive.  This would require only about 150MB, so I could use a smaller, older, cheaper, or otherwise unused USB flash drive.  The Recovery CD option might load faster than a full Windows CD, but it would not be useful for installation or for recovering system files.

Either way, the first step was to get the necessary files.  The Windows installation files would traditionally be purchased on a DVD, but it was also possible to download them.  Similarly, the Windows 7 System Repair Disc was ordinarily a CD, but it could be copied or converted to files on a hard drive.

To get a System Repair Disc, I had to search my computer for "system repair disc."  That didn't work in my case -- I must have renamed the relevant shortcut -- so I searched for various combinations of "create," "system," "repair," and "recovery."  I could also have used Control Panel > Backup and Restore > Create a system repair disc.  The option of downloading the file(s) needed for a system repair CD was apparently disappearing.  In any case, eventually I found and used the link to a little Windows 7 program whose title bar read simply, "Create a system repair disc."  This created the recovery CD.

Next, the files that weren't already in ISO format needed to be converted to ISO.  The downloaded versions of Windows 7 evidently came in ISO format.  By contrast, the installation DVD and the recovery CD were not in ISO format.  To convert them to ISO, I started by using Magic ISO Maker.  It warned me that it would not create an ISO larger than 300MB, but this seemed to be a bluff to motivate an immediate purchase.  Format Factory would apparently have been one among many freeware alternatives.  When I remembered that ImgBurn would create ISOs from files or discs, however, I deleted the Magic ISO output and used ImgBurn instead, since it had worked well for me in other sorts of projects in the past.

Once I had an ISO, I had a choice between two different approaches to get it properly unpacked and operational on the USB drive.  A dedicated USB drive would focus solely on one version of Windows 7 (e.g., 32-bit vs. 64-bit, Home vs. Ultimate).  This dedicated approach seemed likely to be relatively simple and reliable, and would probably be all that most users would need.  By contrast, a multiboot USB drive would allow the user to install and/or run two or more different operating systems (potentially including e.g., Windows XP and Linux).  I decided to go with the dedicated, single-system approach.

I started with the Windows 7 system recovery CD, which ImgBurn had now converted to a file I called Win7SysRepair.iso.  There seemed to be several ways to put this ISO onto a bootable USB drive.  One approach involved using Grub4DOS.  Another was to use Microsoft's Windows 7 USB/DVD Download Tool.  I ran that Tool.  It called for a few simple steps.  First, I plugged in the little 512MB USB flash drive on which I was going to install the Windows 7 system recovery CD files.  Then I pointed the Download Tool toward the newly created Win7SysRepair.iso.  I clicked the USB Device button, and the Tool found the USB drive.  I clicked Begin Copying and confirmed that it was OK to erase the USB drive.  The tool said, "Creating bootable USB device."  The first time I tried it, it failed, with this error message:

We were unable to copy your files.  Please check your USB device and the selected ISO file and try again.

I assumed this was due to interference from AntiRun, which I was using to keep an eye on USB drives.  I shut down AntiRun and tried again.  But no, the Tool failed the second time too.  To troubleshoot this problem, I ran a search and saw that this was a rare error.

The problem seemed to be that the Tool was formatting the USB drive as NTFS.  I thought the solution would be to go to Start > Run > diskmgmt.msc and quick-reformat the USB drive with a FAT32 file system (using a volume label of no more than eight characters).  But I still got the same error.  Another source said the problem was that the Microsoft programs (diskmgmt.msc and also the Tool) failed to use the Clean command.  In other words, my USB stick had residual formatting from some previous use.

The advice was to fix this problem by opening a command window with Administrator rights and type "diskpart" at the prompt.  This started the DiskPart program, with its own DISKPART> prompt.  The next step was to type "list disk" to see what drives were connected to the computer.  This showed me that, as expected, the last disk was the smallest:  491MB.  That was surely my USB drive.  (It seemed pretty important not to be reformatting the wrong drive.)  That 491MB drive was Disk 2.  So I typed "select disk 2."  It informed me that Disk 2 was now selected.  I typed "list disk" again to check and, sure enough, there was an asterisk next to Disk 2.  So I was ready to type "clean."  It said, "DiskPart succeeded in cleaning the disk."  With that done, I could type these remaining commands in DiskPart, one at a time:

create partition primary
select partition 1
active
format quick fs=fat32
assign
exit

I exited the command window and tried Microsoft's Windows 7 USB/DVD Download Tool again.  It still failed.  I tried again, this time using a different USB drive.  This time was even worse:  previously, it had failed at the 99% mark, but with this drive the copying process didn't even start.  I tried using an ISO built from a System Recovery CD created on another computer, running a different version of Windows.  But the Windows Download Tool said this:

Invalid ISO File

The selected file is not a valid ISO file.  Please select a valid ISO file and try again.

I got that error twice, with ISOs created by ImgBurn and also by Magic ISO Maker.  It was time to give up on the Microsoft Download Tool, reformat the USB drive, and try another approach.

I went back to look at the Grub4DOS approach mentioned above.  I wouldn't be using it to install multiple bootable operating systems on my little 512MB USB flash drive, but it looked like a straightforward process anyway; I figured maybe the education would come in handy later.  For this approach, I needed to download and install MultibootISO.  I found what appeared to be a popular, current version of this program on a Pendrivelinux webpage.

On closer inspection, what we downloading was now called YUMI (short for Your Universal Multiboot Installer).  YUMI was apparently a successor to both MultibootISO and Universal USB Installer.  YUMI was portable; no installation required.  YUMI didn't have a built-in option for installing Windows 7.  I got the feeling that YUMI was not going to replace MultibootISO for this particular task.  Nonetheless, I tried.  In YUMI, I selected "Try an Unlisted ISO."  YUMI didn't complain that the ISO was invalid.  It seemed to think it had succeeded.  Sadly, the USB drive wasn't bootable, at least not in the laptop where I tried it.  I tried again and, whoa, success!  Apparently I had just not hit Esc quickly enough to bring up my laptop's bootable USB drive menu when the laptop was first starting up, or maybe I had hit Esc too many times and escaped my way right out of that menu.  But now, on this second go, YUMI gave me the Windows 7 recovery CD functionality, running from my USB drive.

Well.  This YUMI thing was pretty cool.  When I started this post, I thought I would just be content with the Windows 7 installation DVD. For that purpose, my spare 4GB USB flash drive was sufficient.  But now I wanted to try YUMI with a large USB drive that would accommodate the Windows 7 installation DVD as well as other operating systems and other bootable CDs.  But this would have to await purchase of a 16GB or larger USB flash drive.

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.

Windows 7: Setting and Maintaining Accurate System Time

I wanted to keep two computers' clocks set the same, for purposes of synchronization, so that they would have an accurate sense of whether the version of File X on computer A was newer than the version of File X on computer B.  I had previously installed (or, more accurately, just added a copy of) Judah Levine's portable NISTIME 32 in something of a rush, when installing Windows 7, and, later, had vaguely recognized that it was not working right and/or I had not set it right.  Now I decided to work out the kinks in this function.

NISTIME-32BIT.EXE

I started with the National Institute of Standards and Technology (NIST), from which programs like NISTIME 32 would draw the current time.  It developed that NIST had a program called nistime-32bit.exe.  It turned out to be the same as NISTIME 32, just slightly updated.  The webpage's instructions were to start by going into File > Select Server and then Query Server > Now.  Somewhere I saw advice to choose a server near me.  I was tempted to choose two different ones, one for each computer, so as to have accurate time in case there was some terrible disruption of the national timekeeping system.  Then I realized that this could have the effect of making rivers run upstream, where my files were concerned, to wit:  new could be replaced by old.  Being up-to-date on the latest developments in American chronology suddenly seemed less important than making sure I didn't accidentally overwrite today's crossword puzzle.

When I went to the Query Server > Now menu pick, I got a dialog indicating that NISTIME 32 was prepared to adjust my computer by 0.953 seconds.  I told it to go ahead.  I also went into Query Server > Periodically and told it to update the computer every 12 hours.  Query Server > Server Status confirmed these settings.  File > Help in Choosing Dirs told me to hit File > Save Config to save my settings.  This gave me "File Error:  Cannot open file to save configuration."  That problem may have been caused by nesting the program too deeply in a subfolder.  I moved it elsewhere and tried again. Now it seemed to confirm that it had saved my settings, and it created NISTIMEW.CFG in the same folder as the program's portable executable (nistime-32bit.exe).  I exited and restarted, and it remembered what I had told it.  But I had to remember to hit File > Save Config; it would not remember anything.

But then, when I did go into Query Server > Periodically, specified 12 hours, and hit File > Save Config and then File > Exit, I could not get it back.  The program refused to become visible.  I tried a couple of times, and then looked at Windows Task Manager (Start > Run > taskmgr.exe) > Processes tab.  Taskmgr showed four separate instances of "nistime-32bit.exe *32."  I selected them and clicked End Process, one by one, and then ran nistime-32bit.exe again.  It returned to taskmgr.exe, but not to the screen.  I minimized all windows, one by one, but, no, it was not lurking anywhere.  There didn't seem to be a taskbar or system tray icon for it.  It was here, and yet not here.  I killed the processes again, now that I had started one or two new ones.  I renamed NISTIMEW.CFG to be something else, and now it would start, and it saved new settings in a new NISTIMEW.CFG.  Apparently the config file had gotten corrupted.  I had originally created that file manually in lowercase (nistimew.cfg); possibly something about the program needed the uppercase filename.

But now, same thing again.  Exiting and restarting gave me a hidden program:  visible in Task Manager's Processes tab, but not visible onscreen.  When I right-clicked on nistime-32bit.exe *32 in Task Manager and selected Properties, I got an error:  "Windows cannot find [pathname] nistime-32bit.exe."  I ended the process again.  I created a shortcut to the .exe and tried starting it that way.  I had no reason to think that would make any difference, and in fact it didn't.  I tried moving all of the files from the folder where I had put nistime-32bit.exe, and placed them all instead in C:\Windows, with a shortcut to the executable in my Start Menu.  That wasn't the answer; I still got lurking program sessions that appeared in Task Manager but nowhere else.  I deleted the CFG again and tried again.  Now it ran.  I went directly to File > Save Config without making any changes.  It indicated that it had saved the config file.  I exited and restarted the program.  It ran.

Now I saw something that may have explained the config file problem.  The server list had changed.  The Colorado server that I had selected previously was no longer listed in File > Select Server.  I had previously gone into File > Update Server List, and that had generated a message:  "New server file is C:\Windows\NIST-SRV.LST."  It did that again now, when I designated a new server.  I hit File > Save Config and then File > Exit, and then restarted the program.  Now it was running normally.  I moved the three files (the exe, cfg, and nist-srv.lst files) from C:\Windows back to the folder where I really preferred to have them.  It seemed that the server list had not properly updated when the files were in that folder originally.  I restarted and went through the same steps -- update server list, choose a new server, save config -- and now I was exiting and restarting without a problem.

But no, I spoke too soon.  When I restarted, saved a 12-hour periodic refresh, and exited, it would not restart.  Deleting the config and moving the other files back to C:\Windows did not fix it.  The problem seemed to relate specifically to the attempt to set up recurrent time checks.  I was doing something wrong, or perhaps the program had a bug, or maybe it was not suited for 64-bit Win7.  I went to the NIST webpage cited in the program's Help > More Help and sent an email to the Webmaster link at the bottom of that page, pointing them here.

The Built-In Windows Time Sync Option

I decided to look for an alternative time-updating program.  I ran a search and discovered that there was apparently some kind of automatic time-updating arrangement built into Windows.  The advice there was, however, that "The W32Time service is not a full-featured NTP solution that meets time-sensitive application needs."  That was consistent with the fact that my two computers' timeclocks tended to be somewhat inconsistent with one another.  I had not tried to see how inconsistent they could be, or how long they could remain that way.  I did see an indication somewhere that Windows defaulted to a weekly time update, so maybe it would verify that it was accurate to within a minute, or something, every week or so.

That appeared to be steered by Control Panel > Date and Time.  That dialog could also be opened by right-clicking the clock in the system tray and choosing Adjust Date/Time.  Or, as I now learned from Eric Phelps, it could also run from the command line via "rundll32.exe shell32.dll,Control_RunDLL timedate.cpl."  The latter option would facilitate the option of opening the Date and Time dialog for manual adjustment via, say, a batch file that would open it automatically (to the correct tab) every day, week, or whatever.  (Later, I found a How-To Geek webpage that said I could just run "w32tm /resync" as administrator to resynchronize the clock without even going into the Date and Time dialog.  That, too, could be incorporated into a scheduled batch file.)

The Date and Time dialog > Internet Time tab > Change Settings option gave me a choice of synchronizing with time.nist.gov, which I understood to be the most accurate (though others in that list, not counting time.windows.com, appeared to be cousins of NIST).  I noticed that the dialog told me, here, that "This computer is set to automatically synchronize on a scheduled basis."  The previous sync site, as I saw on the other computer, was time.windows.com."  I wasn't sure how synchronizing with that site could have left my two computers with different times -- differing by seconds, that is, not by minutes -- unless maybe time.windows.com was just not that worried about the seconds.  Or maybe it was trying to synchronize when my router was doing its daily self-restart, and was therefore not getting access to the online clock?  I wasn't sure.  (Note:  Fouzan said that this whole process wouldn't work if the computer was on a domain.)

Curious about the timing, I went into Start > Run > taskschd.msc > Task Scheduler Library.  There were maybe 15 items in the list, and none of them were obvious time sync tasks.  So another possibility was that some bug or tweak, brought into my system somewhere along the line, was preventing the creation or execution of the scheduling function.  Another emerging possibility was that, as stated in a How-To Geek webpage, time.windows.com (which my systems had been using by default) had "a ton of problems with uptime."  So possibly I had already fixed my problem, just by switching the machines to use time.nist.gov in the Date and Time dialog.  (I did notice, as soon as I made that switch and clicked the update button, that both computers' clocks showed exactly the same time.)

Other Possibilities

I ran another search and found a Gizmo recommendation for Dimension 4 as a time correction utility.  It occurred to me, at this point, that possibly I had fixed my problem, just by switching away from time.windows.com (above), and that maybe I should just let things slide for a week or two.  I decided mostly just to record some notes, here, for possible future reference.  So instead of installing Dimension 4, I just dragged the icon for its webpage from my browser's Address bar over to the Time subfolder in my customized Start Menu.  If I ever needed it, I could follow the link at that time.

There also appeared to be more to know than I had realized, regarding Task Scheduler (taskschd.msc).  In Task Scheduler's left-hand pane, I went down the tree into Task Scheduler Library > Microsoft > Windows > Time Synchronization.  Now I saw that my machine was indeed set to synchronize time at 1 AM every Sunday.  I saw advice from Tina Sieber on a way to adjust and improve the scheduling via Task Scheduler.  Tina seemed to believe, however, that using a separate program might be the simpler and more accurate approach.  Tina pointed toward two other programs, Atomic Clock Sync and AtomTime.  The webpage for the latter seemed very old.  I was not sure how it would fare in a 64-bit Windows 7 world.

For now, the solution seemed to be simply to go into the system's clock and change its time source to NIST.  My monthly batch file brought up the NIST/USNO timepage on the first of every month, so I could observe, later, whether my two computers were again diverging from one another and/or from the time on that webpage.  If they didn't stay in line, I would have two options.  One would be to add one of the foregoing command lines to my daily or weekly batch files, to permit manual and/or automatic checking and/or resynchronization.  Another would be to try one of the several freeware utilities just mentioned, particularly Dimension 4 or Atomic Clock Sync.

Warning: System Memory Usage High

Summary

A sudden announcement from my computer speakers appeared to be due to a bug in Rizone Memory Booster (MB).  The solution seemed to be to change, rename, or delete the MP3 files in MB's Sounds folder.  I used this problem as an opportunity to look at some related freeware.

Description

I was working along as usual in Windows 7, and suddenly a voice announced from my computer speakers, "Warning:  System memory usage high!"  I had recently reinstalled Windows and all sorts of software, so it wasn't immediately obvious what piece of hardware or software would keep repeating this announcement every few minutes.  I ran a search and saw that nobody else seemed to be reporting exactly this problem, so I thought I had probably better log, here, my efforts to resolve it.

I first checked to see whether the warning was correct.  There were all sorts of things to know about memory, such as whether I was using 32-bit or 64-bit operating systems and hardware.  Getting an accurate and informative impression of the current status of my system could be tricky.  I was using the Windows 7 Task Manager (Start > Run > taskmgr.exe > Performance tab) and the Windows 7 Resource Monitor (Start > Run > perfmon.exe > Open Resource Monitor), but I wasn't entirely sure what they were telling me.  I thought maybe another tool would help to clarify the situation, so I did a search on CNET.

Among the several highly rated options there, it seemed that Iolo's System Mechanic Free might give me a good memory tool and might incidentally address some other needs.  On Iolo's website, I saw that their "standard" version of System Mechanic cost $40, so I was a little concerned that I might actually be installing shareware.  Not that I shouldn't pay for useful software, but I was already running behind in that department, and there were other programs of long service that had first dibs on my financial resources.  It developed, in any case, that flipping the switch from "Disabled" to "Enabled" on System Mechanic's option to "Automatically repair low memory problems" brought up a prompt to upgrade to the $40 version.  System Mechanic did have manual cleanup and reporting options.  For instance, by the time I got to the point of writing these words, its IntelliStatus report more or less agreed with Task Manager that about 70% of my RAM was free, and the adjacent Optimize button opened up a memory defragmentation process that ran for maybe 10 seconds and claimed to recover another 5% of RAM.  I decided to keep System Mechanic for a while and play with it some more.  Using Windows Explorer, I added a link to System Mechanic to the Startup folder in my Start Menu, so that System Mechanic's options window would open up when I started the computer.

At some point, I noticed that CNET's editors and users ranked Advanced SystemCare Free pretty highly.  It was another program, like System Mechanic, for cleaning and optimizing the system.  It appeared to be a lot more popular.  I had used a previous version for years, but I think I fell away from it when I transitioned from Windows XP to Windows 7.  I decided to try it too.  It seemed likely that I would join the crowd and prefer it over System Mechanic.

For present purposes, an automatic memory optimizer appeared to be what I needed, so I went back to CNET and looked at the popular MemInfo.  Its purpose seemed to be to provide fast, system-tray access to memory information and a manual RAM defragmenter.  But then I saw the widely used Moo0 SystemMonitor Portable.  I tried it and liked it.  It took me a minute to catch on to it.  I had to right-click on its onscreen display to get options.  It was easier to access and more configurable than Windows 7 Task Manager or Resource Monitor; it took less screen space; and it could be made to minimize to the system tray.  It didn't seem to have a measure of graphics performance, though, so it seemed I would have to use the Windows Experience Index for that (Start > Control Panel > Performance Information and Tools).

At some point in this inquiry, I remembered that I actually had already installed an automatic memory optimizer:  Rizonesoft's portable Rizone Memory Booster.  I hadn't tried to tweak it or anything; it had just sort of faded into the background or, more accurately, the system tray.  But now I thought, well, of course, that had to be where this phantom voice was coming from.  I right-clicked on its icon, which now seemed terribly obvious there in the tray, and looked at its options.  Yes, it did have an option to "Play warning every 3 minutes if load exceeds 80" (percent, I assumed).  The default values of 3 and 80 were adjustable.  But, oddly, this option was turned off.  I turned it on and changed it to 1% and clicked Apply.  Nothing happened.  I retried with 30%.  Still nothing.  Memory Booster's main screen said 50% of memory was used, so I should have gotten something.  Ah, but when I closed out of the dialog altogether and let Memory Booster retreat to the system tray, the voice came back.  "Warning:  system memory usage high."  So that was the culprit.  The program's readme file seemed to indicate that there had been a previous issue with saving the sound settings, so maybe the fix for that problem had created this new one where apparently the program would sometimes turn on the sound on its own initiative.

I played with Memory Booster (MB) for a few minutes and then sent Rizonesoft a link to this blog post.  MB had options to Optimize or Defrag memory.  Its writeup and an Addictive Tips review agreed that, unlike many other memory optimizers, MB's Optimize option used a safe method, involving "a Windows API call."  This would reportedly leave programs and data in memory and, as such, would only free up a minor amount of memory -- but it might also cure memory leaks and unfreeze programs.  By contrast, the writeup said that the Defrag option was an experimental (presumably potentially unstable) function that, unlike Optimize, would force most of the contents of memory into the pagefile (i.e., the portion of hard drive space set aside as a memory overflow area).  It seemed that Defrag was the more extreme option, carrying a risk of (temporarily) screwing up the system and requiring a system reboot.

The Defrag option was not included in the version that Addictive Tips reviewed.  Possibly it was previously a feature available only in the Gold ($14.95) version of MB.  Then again, I wasn't entirely sure whether a gold version continued to exist.  The writeup (dated July 7, 2011) said that MB "is now part of the Doors system," and explained how to install MB by installing Doors.  But I hadn't had to do that.  Maybe things had changed since the time of that writeup.  I wasn't familiar with the Doors system.  It seemed to be Linux-related.  So that part was a mystery.  One source had said that MB had only a nine-day trial period.  Maybe that had changed too -- maybe it had been removed or lengthened.  Rizonesoft's webpage said, "Demand no nonsense freeware," so apparently there were no worries there, unless the Doors situation had changed that.

I did like the program -- it was informative, and it seemed to be accurate, and its Intelligent Memory Optimization seemed to be working.  While some might not understand or appreciate the sarcasm on the website or in the readme file, it seemed that the programmer was responsible and meant to be helpful.

It occurred to me that I might be able to fix the sound problem myself.  I looked into the program's Sounds subfolder.  There, I saw five MP3 files.  One was called mem-high.mp3.  I played it.  Sure enough, that was the one I'd been hearing.  I created a subfolder called "Originals" and put these MP3s into it.  I wondered whether identically named replacement MP3 files would work.  First, I inserted a song MP3 into the Sounds subfolder, renamed as my new mem-high.mp3 file.  At first it didn't seem to be working, but I fiddled with it for a few minutes, and then it did.  Of course, I realized immediately that this had some prank possibilities.  But for my purposes, I removed all MP3s from the Sounds folder.  The program didn't crash when it failed to find a mem-high.mp3 file to play, and it seemed to continue to work.  I didn't want MB to make sounds, so that was the way I left it.

Windows 7: Notes on the System Imaging Feature

I decided to make a drive image using Window 7's system image feature. I had made an image previously, but System Recovery couldn't find it when I needed it.  As I was starting the system imaging process, I saw this warning:

Backing up to dynamic disk gives you limited functionality while performing system image restore.

I wondered whether my previous image would have been visible, when I tried to restore from it, if I had copied my Win7 image to a partition that was not on a hard drive containing any RAID arrays -- more specifically, to what Disk Management (diskmgmt.msc) would show as a "basic" rather than a "dynamic" drive.  I had originally saved the image to a basic drive, but had then moved them to a partition on a dynamic drive.  If I had originally tried to save it to the dynamic drive , maybe I would have gotten this "limited functionality" notification at that point.

My mission at this point was to see whether Win7's system imaging could do what Acronis True Image Home 2011 apparently could not.  Could it restore a bootable Windows 7 partition to a new drive C located on a RAID0 array?

I went into Control Panel > Backup and Restore > Recover system settings or your computer > Advanced recovery methods > Use a system image.  It gave me the option to create a backup now.  I took that, just in case.  I tried saving to a partition on the dynamic drive, just to see what would happen.  It did give me a warning, "The selected volume is on a dynamic disk."  I clicked on its "More information" link.  That opened this dialog:

Set up backup

When restoring a system image from this volume, the disks on your computer cannot be formatted to match the layout of the disks in the backup.  To have full restore functionality, select a volume on basic disk as your backup location.

It wasn't clear whether that meant that the very process of creating a backup on a dynamic drive would have this effect, or if they were just saying that trying to *restore* from a dynamic drive would be difficult.  I decided to save to the partition on the dynamic drive nonetheless.  But as I proceeded, it appeared that I was only setting up an ordinary backup.  The option wasn't available to "Include a system image of drives: PROGRAMS (C:)."  The explanation, which didn't entirely persuade me, was, "Because you are trying to restore your computer to a previous state, you can only back up data files" -- not program files, that is.

I canceled out of that and clicked Restart to continue the system recovery -- bearing in mind, here, that I was hoping to restore to the RAID0 array, which had not yet entered service, whereas this backup program was sounding like it intended to restore to (and overwrite) my current drive C.  I was actually willing to let it do that -- the system had been through a rough night -- but upon rebooting, it said, "Windows cannot find a system image on this computer."  It defaulted to the "Select a system image" option," so I went with that.  Then Advanced.  But still, we weren't able to find those images that I now had on two separate partitions.

So now I wondered if the failure to find my previous system images was due to the fact that I had changed their names.  I thought it made sense to do so.  They were all called WindowsImageBackup.  I changed them to put the date in front, e.g., 2011-01-07 WindowsImageBackup.  Maybe this kind of rigidity was calculated to make the program easy to use.  I suddenly realized that, contrary to my assumption, perhaps later backups would not overwrite the previous WindowsImageBackup folder.  I looked inside the WindowsImageBackup folder, and it did appear that images might be saved in subfolders with different dates in there.

So, OK, back in the partition on the dynamic drive, I changed the name of one of those folders back to plain old WindowsImageBackup.  It was still in a subfolder, not in the root folder.  I went again to Control Panel > Recover system settings or your computer > Advanced recovery methods > Use a system image you created earlier to recover your computer.  I skipped the backup step, this time, and clicked Restart.  The "scanning for system image disks" process still said, "Windows cannot find a system image on this computer."  I canceled that automatic search and again tried "Select a system image" and then Next.  Still no joy.

That was the story for the search for the WindowsImageBackup folder on the dynamic drive.  Back in Win7, I tried renaming the copy of the WindowsImageBackup folder that I had copied to the basic drive.  I went through the same steps again.  "Scanning for system image disks" and this time, praise Jesus and pass the tequila, we had a discovery!  We had liftoff!  We had a window that said, "Select a system image backup."  So the answer to this little mystery was that (a) you were not supposed to change the name of the WindowsImageBackup folder and (b) it had to be on a basic (i.e., not dynamic) drive.  Since this worked, I did not try the alternative of going into the WindowsImageBackup folder, in Win7, and just double-clicking on various files to see if they would spontaneously fire up and run the system recovery software.

So now that we had a system image ready to be restored, the question was whether it would insist on being restored only to the basic drive, or whether I would have an option to restore it to the RAID0 array I had set up to be my boot drive.  Actually, it did not say where it was going to restore.  It said that it was going to restore drive C, but it did not say where it believed drive C was located.  But surely it would not wipe out data partitions, at least.  I went ahead with it.  After five minutes or so, it said, "Restore completed successfully," and it rebooted back into Win7.  It had restored the image to the existing drive C, the one I had booted from.  So there did not appear to be an option to choose a different target drive.

So I now had restored my original hard drive to its original condition as of about midnight the previous evening, before things started getting funky.  Along the way, I had learned a bit about how Win7's system recovery feature functioned.

The remaining unknown was whether I could just munge my various copies of the WindowsImageBackup together into one.  Keeping backup copies, I went into Windows Explorer and did a simple copy-and-replace operation to combine those WindowsImageBackups, into one properly named WindowsImageBackup folder.  I didn't try to figure out which versions of the same file to keep; I just copied and replaced, more or less at random.

I left this combined WindowsImageBackup on the dynamic drive for the moment.  Then I went into System Image and let it do its reboot thing.  Its scan for system image disks failed to detect the ones on the dynamic drive.  So it seemed to be pretty much confirmed that it didn't want to save to, or restore from, dynamic drives.

I moved the WindowsImageBackup folder, containing the munged combination of two different backups, to the basic drive, and tried System Recovery again.  This time, it found the folder, but it detected only the older of the two backups within it.  So it seemed my file munging process had probably replaced the newer versions of some of the indexing files in that folder with older versions.  Apparently the imaging program looked at those small files when deciding which images were available.  I didn't test whether overwriting older indexing files with newer ones might have shown only the newer images.  Tentatively, it seemed that the best solution, when there were two distinct WindowsImageBackup folders, was just to keep them separate and eventually delete one of them, rather than try to combine them.

Making Space on a Windows XP System Drive

I wanted to make space on my computer's C drive.  For some purposes, it could be more sensible to just install a bigger hard drive or make a larger partition for drive C.  But for other purposes (in my case, where drive C was in a virtual machine (VM) in VMware Workstation and you really didn't want to deal with the slowness and overhead of a huge virtual drive), there might be no alternative but to make space.  Drive C had a habit of just continuing to grow and grow, if you let it; I had one that got up to around 35GB.

I started with a general-purpose Web Developers Notes cleanup page.  I was already doing one thing they suggested, which was to use portable versions of various utilities.  IrfanView, for example, was available in both an installed version and a portable version.  Typically, there was no difference in functionality; the main thing was just that you had to create a link to the portable version if you wanted to have it listed in your Start > Programs list.  Portable versions could be run from anywhere, which means they wouldn't have to be on drive C.  So could installed versions, in theory; but in practice, programs didn't always run correctly and updates were not always applied, when the program was not located where the programmers expected it to be.  Back in the late 1990s, I did spend an enormous amount of time trying to figure out which installed programs could safely be installed somewhere other than the default location, but ultimately I concluded it wasn't worth the hassle.  In short, if it was a portable version, I put it in a folder labeled "Installed Here" on drive D; otherwise, I installed it on C.  Those who hadn't done this during installation could, as advised, uninstall from C and reinstall on D.

I was also doing another thing they suggested, which was to keep data files (including e-mail) on a separate partition.  Program files went onto drive C if they had to be on drive C, or if they would be a lot less hassle if they were on drive C (e.g., see previous paragraph).  Stuff generated by me and by the rest of the world went on drive D whenever possible.  It helped, for this purpose, to relocate those folders (unwanted by me, at least) that Windows automatically created, including "My Documents" and "My Pictures" and "Microsoft, I Need Your Help in Telling Me Where to Put Everything."  Also, in Microsoft Office programs (among many others), I could change settings to store files by default in a folder that was not on drive C.  Then you could back up drive C once every couple of months - whenever you had accumulated enough new program installations and adjustments -- using Acronis or some other drive mirroring program, while continuing to back up your drive D (data) partition on a daily if not hourly basis.

Another suggestion was to delete programs that were not being used via Control Panel > Add or Remove Programs.  It was unwise to remove programs that you need, or to remove programs whose function was unclear.  No point making extra work for yourself or screwing up your system.  (Incidentally, the command to open Add or Remove Programs was this:

rundll32.exe shell32.dll,Control_RunDLL appwiz.cpl,,,

That was a pretty funky command, and for future reference I saved a webpage containing others like it.  I will be combining these commands in a single batch file (below) for one-click all-purpose cleanup.)

Another space-saving step they recommended, which I rejected for my purposes, was to empty out the browser cache (in e.g., Internet Explorer, Firefox).  Why bother?  It would fill up again -- I would want it to fill up again, so as to load pages faster and save the cookies that would store my login information for many webpages -- and I would still need the disk space to accommodate it.  This step would make sense for a one-time task, like making an image of drive C.  For more enduring space saving, the more sensible step was to go into those browsers and make the cache smaller.

A step they should have recommended, but didn't, was to move the page file.  It could be huge.  After moving it and rebooting, I made sure there was not still a copy on drive C.  There was also apparently a Microsoft utility to protect against performance degradation due to pagefile fragmentation.

Moving the paging file was more complicated in my case, because I was using VMware.  (In other words, those who are not using VMware should skip this paragraph.)  In the case of my virtual machine, it seemed to be preset to about 2GB.  Then I came across a mention of the option of setting up a separate virtual drive, within my virtual machine, for the paging file.  The advice, there, was to go into VMware Workstation for this virtual machine and choose VM > Settings > Hardware tab > Add > Hard Disk > Next > Create a new virtual disk > IDE, Independent, Persistent > Next.  I set the disk capacity at a 4GB single file, which seemed like plenty when combined with the 2GB of RAM I was allocating to the VM.  Then, continuing with the advice, I powered up the VM and, with a series of right clicks, I initialized, partitioned, and formatted that drive, set its drive letter to I (so that it would not interfere with D or other drives I was already using), and set its pagefile.  I varied somewhat from the advice on one point; I set the size of the drive I pagefile to a minimum and maximum of 3.5GB, having heard that making the system enlarge the file could take a hit on performance.  (I originally tried 4GB, but Windows gave me warnings that the pagefile drive was running out of free space.)  Finally, they advised me to reboot again and set drive I to nonpersistent. This, it seemed, would take care of the problem of pagefile fragmentation.

They also recommended defragmenting the hard drive.  I used Smart Defrag for this purpose.  It was supposedly running all the time, but I included it in my batch file anyway because it always seemed to have things that needed to be done whenever I did open it.

They suggested using WinXP's Disk Cleanup (command line:  cleanmgr).  Good idea, but typically this made less space than one might have imagined.  Again, there was a tradeoff:  you could make more space by deleting things that might cost you extra time (e.g., Office setup files) whenever you did next need them.

Another possibility was to run a program to see which files and folders were most space-consuming. Raymond recommended TreeSize Free and JDiskReport, both of which were portable freeware.

Someone at HelpWithWindows.com recommended deleting unneeded old files.  Some of this was already being taken care of, for me, via Advanced WindowsCare 2, which I had included in my Startup folder.  Still, I used a complex command to open a search dialog, where I could search for files matching these patterns.

*.bak
*.chk
*.gid
*.old
*.tmp
*.~mp
*.$$$
*.000
~*.*
*~.*

Not every file coming up in those searches would deserve deletion, but many would.

These steps, combined, freed up about 2GB (10%) of my drive C.  The batch file I wrote to automate some of these steps looked like this:

start rundll32.exe shell32.dll,Control_RunDLL appwiz.cpl,,,
start "" "C:\Program Files\IObit\IObit SmartDefrag\IObit SmartDefrag.exe"
start cleanmgr
start "" "D:\Miscellany\Installation\Installed Here\TreeSizeFree.exe"
start "" "D:\Miscellany\Installation\Installed Here\JDiskReport.exe"
type nul > %temp%\1.fnd & start %temp%\1.fnd & del /q /f "%temp%\1.fn

It ran slowly, but it did tend to automate the steps needed in the process.