You're most welcome.
Entering a manual restore point works, but is getting old.
When I run System Restore, it never suggests a restore point and displays the manual restore points (cleverly named "manual") only. Please note that the script I am using does /not/ allow my to specify the name of the restore point when I run it, which is just fine with me. Your script used to produce Restore Points that System Restore would display and select.
Hello psperson, and welcome to Ten Forums.
Be sure that you are using the current downloads in the tutorial since they have been updated.
The instant restore points are listed after you click on "System Restore", click on "Next" where it normally shows you only the latest update to see all available restore points.
You're most welcome.
I confirmed that the August 2016 Update for Windows 10 Build 1607 ("Anniversary Edition") has definitely broken the ability to create named restore points via the documented API SRSetRestorePoint in SrRestorePtApi.h in the SDK (which is what WMI CreateRestorePoint uses).
At first I suspected that it was a due to a 64-bit/32-bit problem since the error in the Event Log was reported as "Volume Shadow Copy Service error: Unexpected error calling routine QueryFullProcessImageNameW. hr = 0x80070006", the theory being that it was a 32-bit/64-bit conflict where the 64-bit Volume Shadow Copy service (vssvc.exe) for some reason now wanted to the know the name of the process that initiated the restore point (presumably for reporting or logging), so it tried to open a handle on a 32-bit Visual Basic scripting engine hence the bad handle error.
But it turned out that the problem was deeper than that. It looks like Windows 10 Build 1607 has broken SRSetRestorePoint in multiple ways. The second bug is that it tries to open the handle on the process that created the restore point too late, after it terminates (hence the QueryFullProcessImageNameW error). I suspect it is because SRSetRestorePoint() returns a success indication too soon, before the volume snapshot service (VSS) has actually finished writing the client-accessible and writer-enabled snapshot in the file system. Also it seems to be monitoring the file system and registry for any changes incorrectly, and it wrongly skips creating the restore point if it doesn't detect any between state 100 and state 101 even if such changes were in fact actually made by the application. Then I found a third issue with Build 1607 (too technical to describe here).
The bottom line is after a lot of experimentation I was able to finally develop a tentative workaround for all of the issues listed above that lets you create a named restore point on Windows 10 Build 1607 reliably (including in scheduled scripts) that actually gets committed. The workaround is pretty intricate and I'm not ready to disclose it yet.
Hello Gideon, and welcome to Ten Forums.
I look forward to seeing your findings when ready.
There are at least four bugs with CreateRestorePoint in the August 2016 Update for Windows 10 Build 1607 ("Anniversary Edition"): A process-exit timing problem, a 32-bit/64-bit conflict, a VSS race condition, and a false success indication.
The reason the WMI CreateRestorePoint seems to work with Windows 10 Build 1607 is because of sheer luck. WMI is slow and bloated enough that the timing just happens to work. The problem is that the underlying API (SRSetRestorePoint) now operates asynchronously. If your script quits too fast the operation will fail (QueryFullProcessImageName tries to fetch the name of your script but it is already gone). CreateRestorePoint happens to work because it runs in the WMI service and lives long enough to be seen. However the WMI service itself can quit at any time when idle, so it still can fail if the SR takes too long (see below).
Creating a restore point in a 32-bit scripting engine (like CSCRIPT.EXE) is completely broken because it triggers the use of a DCOM DLL Surrogate (DllHost.exe) that will quit immediately, so the async QueryFullProcessImageName on it always fails.
SR kicks off a series of complex interactions with the Volume Snapshot Service (VSS). The volume snapshot has both the client-accessible flag and the with-writers flag set (normally an impossible combination for mere mortals to create). The involvement of the VSS writers means the time to create the snapshot is very unpredictable. It could take up to a minute or more, particularly on a busy computer.
VSS Writers are pieces of software written by third parties that plug into VSS, e.g., for SQL Server and other data-driven apps that need to quiesce themselves into a stable state. They are sometimes buggy and sometimes hang. I've seen instances where the system grinds on for over a minute to complete the VSS snapshot. If any of the VSS writers decides to veto the volume snapshot for whatever reason (which happens more than you think) then the whole thing fails silently and the SR is not created.
Normally you can control and filter out known balky VSS Writers (seen happen, for example, with older versions of Acronis True Image, StorageProtect, and EaseUS) by using the VSS API (IVssBackupComponents->AddComponent) and just soldier on while skipping the bad actors (and logging them). But with SRSetRestorePoint you have no control whatsoever over the VSS / writer control flow. It all happens in the background and might or might not succeed.
I finally figured out a way to passively hook into the SRSetRestorePoint API chain in order to monitor the srclient calls and detect when the SR completes (or fails) and report it properly, but it is not a trivial fix.
The bottom line: Using WMI CreateRestorePoint in your scripts in Windows 10 Build 1607 is a basically a stroke of luck that might or might not work on your particular system depending on several uncontrollable factors (how busy your computer is, how slow the VSS writers are, etc).
There is no notification if it fails, and there is no easy workaround (without a fix from Microsoft).
At first I couldn't for the life of me figure out why Windows Update was doing auto SR just fine on Build 1607 when nothing else was. Then I discovered the final piece of the puzzle, a new undocumented registry value called SystemRestorePointCreationFrequencyWU (WU = Windows Update). Once I sussed that out, along with adding some pixy magic via CoInitializeSecurity to correctly cloak for DCOM and to explicitly request SPNEGO for domain authentication, it all clicked into place and scheduled SR started working in Task Scheduler like a champ.
Boy, that was hard. I really want to thank you guys for the incredible amount of research that you did on this problem. There is no way I could have figured this out without your help. THANK YOU!!