Recently while researching for my recent blog post on ‘Methods to identify historical Time Zone configuration associated with a Windows PC’, I found myself hunting for Regback data within Windows 10 systems with limited success.
Specifically, across multiple system installed with Windows 10 1607, 1703 and 1803 I was finding hives within the C:\Windows\System32\config\RegBack which were 0 bytes in size, as below:
|RegBack folder with 0 Byte Hives|
Many of the systems I was using were fresh windows 10 VMs and as such it may not be a surprise that backups of the registry had yet to be created. Nevertheless, two of the Win 10 1803 systems I was looking at were a longstanding VM that I already had, and my main Windows PC. So, I decided to dig a bit deeper.
Spoiler alert: this post doesn’t have all the answers, it records what I have observed and asks others to confirm whether my observations are consistent with theirs or whether they have an explanation.
The Scheduled task associated with registry backup is ‘RegIdleBackup’ and is located at ‘C:\Windows\System32\Tasks\Microsoft\Windows\Registry\RegIdleBackup’. Examination of various Windows versions 1507, 1511, 1607, 1703, 1709 and 1803 confirmed the scheduled task to be identical in all instances, it is as below:
The task references regidle.dll' which is responsible for the backup process and the ‘UseUnifiedSchedulingEngine’ field is set to ‘TRUE’ which specifies that the generic task scheduling engine is used to manage the task. The ‘Period’ and ‘Deadline’ values of 'P10D' and 'P14D' within ‘MaintenanceSettings’ instruct Task Scheduler to execute the task every 10 Days during regular Automatic maintenance and if it fails for 14 Days, to start attempting the task during the emergency Automatic maintenance. Further information on ‘maintenancesettingstype’ is available here.
I've performed some testing and this confirmed that initiating System Maintenance in any version of Windows 10 prior to 1803 has caused the RegIdleBackup Scheduled Task to be Queued and then Run. This causes the backup copies of the registry hives to be created in the RegBack folder. The same result is seen if we manually run the task.
On my Win 10 1803 test systems, running System Maintenances or manually starting the task will both cause the scheduled task to be executed. The below screenshot shows tasks queued after running System Maintainance on a Win 10 1803 system:
|Queued RegIdleBackup task|
But despite the scheduled task being initiated, for some reason it completes immediately (without reporting errors), and the backup files are not updated. Recently when examining ‘Plug and Play Clean-up’ a similar depreciation was observed but in that case systems which were upgraded still retained the task, but fresh installs had dropped it. In this case a fresh install of Windows 10 1803 will still have the ‘RegIdleBackup’ scheduled task and it will still run during System Maintenance, but no backup copies of the registry hives appear to be created.
Earlier I noted that the task references a DLL located at ‘%systemroot%\system32\regidle.dll’. Reviewing this DLL within each version of Windows 10 confirms that each one has a different MD5, indicating differences in all versions.
I don’t have an overwhelming desire to try to reverse engineer the different versions of the DLL to attempt to determine the difference(s) and whether these are the reason that backup copies to be created, but if that particular challenge takes your fancy don’t let me stop you!
Additionally, if anyone on a Windows 10 1803 box has a spare 5 minutes I would appreciated feedback as to whether you have registry backups in your Regback folder and whether initiating system maintenance or starting the scheduled task causes them to be update.
On my work system, all files are 0 bytes, last modified on 15 May 2018. On my personal system, the same is true, but the files were last modified on 14 May 2018.ReplyDelete
I also have the image from the "Lone Wolf" scenario, which is a Win 10 image; the files are all 0 bytes, last modified on 27 Mar 2018.
on all of those systems can you please compare with the time of the most recent updateDelete
current theory is that they should match roughly (times might be off slightly)
I'll check the other systems shortly, but for my local system, the update to 1803 occurred on 14 May 2018, which I mention in my first comment as "my personal system".
The image from the Lone Wolf scenario seems to be 1709.
Regback files are all 0bytes, with last modified 17 May 2018 06:45 (Corresponds to last major OS update).
OS Name: Microsoft Windows 10 Pro for Workstations
OS Version: 10.0.17134 N/A Build 17134
Last Updated: 2018/05/17, 06:56:01 (Feature update to Windows 10, version 1803).
So it wasn't just me :/, not that I don't use 3rd party backup or manually backing it up as a precaution but that folder saved me the first time I encountered a registry problem.ReplyDelete
We've noticed the same issue at our shop. We use regback for a lot of things, such as getting past passwords created by a tech support scam.ReplyDelete
Windows 10 is Microsoft’s latest Operating System which is still in Technical Preview phase at the time of this writing. Windows 10 comes with a lot of new features and enhancements. It seems like Microsoft is listening to its users and making changes in Windows 10 that were not liked in Windows 8 plus a lot more. windows 10 isoReplyDelete
can i copy that 0 kb files into the config folder ?ReplyDelete
It's possible that due to MS's own new overzealous security (file locking) in V1803/1809, which seem to prevent even themselves to read the locked registry files in order to back it up, thus you end up with a bunch of zero byte files.ReplyDelete
Luckily it can still be done by booting up with something like Hiren's Boot CD and manually copying the entire "Config" folder containing a full copy of the registry.
It's pretty sad to see how unnecessarily high security takes precedence over system integrity.
Has anyone tried copying over the %systemroot%\system32\regidle.dll from a previously working version of the RegBack task and see if that would at least give us a workaround? I would have tried it, but I simply don't have access to a previously working version of regidle.dll Course there could be more to it then simply replacing that dll. Let us know ;)