In my last blog, “What Gets Lost When Using Win8 Refresh,” I recounted my adventures after running the “Refresh your PC” facility built into Windows 8 on a machine that refused to let me use the record image (recimg) command to set up a current system image as my refresh basis. After additional work with the newly-refreshed system, I have to point out that what happened to my test machine was a worst-case scenario — namely, what happens when you permit the refresh to take your system back to the state it occupied just after you installed the OS.
Even so, this proved to be an extremely helpful maneuver for that system, and here’s why:
- Before refresh, the recimg command would not complete successfully. After refresh, it worked like a charm. As I pointed out in my last blog (having already captured a current image that included all the new drivers I’d had to install, as well as all of the apps and desktop applications that I decided were worth installing once again), this means even if you do have to try the worst case, you will probably only have to do that once.
- Before refresh, Hyper-V wasn’t working properly for me, either. I’d exported, then imported, my collection of virtual machines, to move them from a slower to a faster drive, only to discover that I couldn’t get them to work properly with an external switch to permit those virtual machines to access the Internet. None of the tweaks, tricks, or re-configurations I tried would fix this problem before the refresh. After the refresh, I had to redefine my Hyper-V settings and re-import my virtual hard disks (.vhdx files in all cases). But as soon as I did so, and defined a new external switch, everything worked just as it should have all along.
The stated purpose for refresh is to restore a troubled Windows installation to normal and stable operation. In this case, it took an install that was having issues with several key capabilities and replaced it with an install that showed none of those problems. Having troubleshot and noodled around with mysterious Windows gotchas for years, this strikes me as nothing short of miraculous. And if you take the time to create a custom refresh image for yourself at good opportunities (following a clean install, adding all Windows update that policy permits, updating all drivers, then installing all apps and applications to which users are allowed access, then after updates, driver changes, and adding new apps or applications thereafter), you can get back to a normal, stable state with minimal effort any time after that.
But the wonder and beauty of refresh comes with one interesting caveat: you should get in the habit of recording the complete file specification for the refresh images you save, especially those you don’t save on the system drive in the default directory (if your user systems are like mine, many of these use smaller SSDs for boot/system purposes, and nobody wants them cluttered up with big backup files). The following screencap illustrates why this is the case, showing the results of the recimg /showcurrent command, which displays the location for the most recently collected refresh image on a given system:
The mappings between Windows disk drive numbers and drive letters isn’t always obvious. For example, on this particular test system, the image file’s full specification in File Explorer is: F:/RefreshImage/CustomRefresh.wim. That’s what you have to use as the target when invoking the recimg command to restore that particular image, so it’s wise to record it somewhere, so you can provide the right specification should you ever need to use the recimg command to perform a refresh operation.