Windows 10 bug prevents Registry backup creation

In 1803, when you enable the Memory Integrity option in Core Isolation, the Win kernel is virtualized, i.e. ntoskrnl.exe. This is the process "Secure System" equates to.

This must just be a bug in Process Explorer since if ntoskrnl.exe was suspended, your system would cease to operate.

 

Yes, I took a quick look at info, you are right. This is all disabled (and always has been) here. So it's not related to this particular issue.

 

I've noticed on few occasions in the past that Proccess Explorer lags in implementing monitoring for new features.

 

I have a theory of what is going on and its pretty damn ugly.

First is what is stored in the backup directory is a copy of the following hives:

Default
SAM
Security
Software
System

It appears that when a new install of 1803 is done, it was supposed to place a copy of the hives in the backup folder which it never did.

Next is what the reg. back task does. I believe it just performs an update to the hives in the backup folder. I say this because many registry areas are inaccessible when Windows is online. I believe the backup processing only applies to areas that are accessible when Windows is online. Also from what I have found on the web, people are still having issues with the reg. backup processing when the hive files exist but show a zero file size.

So the reg. backup processing starts. It can't find any files to update or existing files show that they contain no date, so it just shuts itself down since it can't do any updating and indicates the processing was successful.

I also see no solution other than Microsoft fixing the Win 10 installer and requiring everyone to do a fresh install. Copying any existing hive data to the backup folder off-line would be perilous since who knows what data current exists in them.

 

The dll's owner is TrustedInstaller so it should be able to fully access the registry database even on a live system. It's a tiny 15KB file, most probably a simple copy facility with highest possible privileges. What worries me here is that the file was changed at least twice (seems like it) but this was not documented anywhere in the changelogs. The is the general problem with Windows Task Scheduler, it always lacked proper documentation.
And this is why I have deduced that it was removed:
when I booted into 1809, the task was scheduled with the date and time set in the past (I would like someone on 1809 to additionly confirm this). Such tasks will never run even if they're enabled, that's why stapp (in post #1) has no files in the folder. I have seen before that same behavior where leftover scheduled tasks (and files) for Windows Update produced waves of DCOM errors in Event Logs - new tasks were added by an update but the old ones pointing to old resources were not deleted.

I have also found a way to dissasemble the dll, but it's of no use (to me) since I have no clue what I'm lookin at

 

This is a simple operation - copy database from here to there (but obey privileges):
The task calls the dll to run as SYSTEM account. Since the dll's owner is TrustedInstaller it can read the entire registry, but it can write only to the RegBack folder (which allows SYSTEM apps/dlls to write there). So all is fine there.
The only bottleneck could be in the dll.

 

Just wanted to chime in with a minor correction @Seer. The owner nor permissions set to a particular file define what that file will 'run as'.

"Since the dll's owner is TrustedInstaller" does not mean the dll runs as "NT SERVICE\TrustedInstaller"
You seem to have, at least in this particular instance, confused ownership with privileges.

In this case it (the dll) would 'run as' that level which the task defined and that is indeed as you stated "NT AUTHORITY\SYSTEM" (before the extra incorrect bit was appended there). [yes they are different]

Sorry to nitpick and I truely applaud the effort and attention you've given this matter. My eyes were glazing over before I saw the last bit there which I felt a need to address and I know this doesn't help resolve it at all so yeah. /ignore me

 

I stand fully corrected.
The dll then running as SYSTEM would have read access to the registry. And write access to the folder.
Looks ok now.
I was hoping that by dissasembling I would be able to see the exact API calls and if something is broken there but unfortunately with my limited knowledge on the subject I had no luck.

[EDIT]

I was clearly wrong here. The dll does not need TrustedInstaller privilige to be able to read registry. Too much image restores last night perhaps...

Thanks

 

I can reproduce this problem: registry backup works on 1703 and not on 1803.

The registry backup is indeed triggered by a scheduled task that uses regidle.dll.

Per my analysis: the problem is not with the scheduled task or regidle.dll. Simply put, regidle.dll is a small program that calls NtInitializeRegistry.

It's the call to NtInitializeRegistry on 1703 that results in the creation of the registry backup, while on 1803 no backup is created.

The calls to NtInitializeRegistry in regidle.dll 1703 version and 1803 version are slightly different. For 1703, the argument is 1002 and for 1803 it is 5096.
But that does not explain the difference in behavior. I changed the argument in 1803 to 1002, that did not result in backups. Neither did replacing the 1803 dll with the 1703 dll.

Wild guess: it's a change in the NtInitializeRegistry API function, or one of it's dependencies.

 

@Didier Stevens

I am running the Pro version of Windows 10, Build 1703, and can confirm that I have the appropriate files.

 

Exactly what I was hoping for.
Thank you Didier.

 

I ran the RegIdleBackup task manually and noticed strange behavior.

The task showed it was running in Task Manager. However, I could find no evidence this was the case using Process Explorer. It sat like this for a few minutes or so. Then it finally showed it completed. Well, the start and stop times to the fraction of a sec. were identical and again were a few minutes after I launched in manually. Like it started and stopped almost instantaneously. All prior run history of the this task showed the same like run timings.

I believe something else is going on other than just a borked .dll.

 

NtInitializeRegistry has indeed changed a bit. Here is the code from ntoskrnl.exe:



Now, an argument equal to 5096 calls CmpSyncNextBackupHive:







Some conditions must be met for the backup to execute, like variable CmpDoIdleProcessing not being zero (false). It could be that due to some side-effects not taken into account by the developers, that this variable is false and therefor no backup is performed.

 

Well, part of this mystery solved.

Following up on a suspicion of mine, I booted into Win 10 recovery environment and followed the procedure here: https://pureinfotech.com/restore-registry-backup-windows-10/ to view what was in the RegBack directory. Well, its not empty after all. The hive backup files are there but they show a zero size value which is a different problem I will have to research more. Also the hive backup file dates show the date of OS installation.

Since TweakUI uses shadow volume copy service for its registry backup, I assume the Windows backup task does the same? Could the problem be related to shadow volume copy service in Win 10 1803?

 

As I see it, the NtInitializeRegistry API probably updates LastKnownGood with CurrentControlSet (in HKLM\SYSTEM hive), this is the API that is called on system boot as well (so you can revert to bootable config if something goes awry). The dll contains that API but with an argument that is calling another kernel API which syncs (flushes) LastKnownGood to the folder, but only if the idle condition is met (different from 0) and for some reason that condition is not met.

 

Everything appears to be pointing to the fact that this RegIdleBackup task should be running when the system is idle. Could the problem solution be as simple as enabling the two parameters I highlighted in the below screen shot? These settings are enabled for the DiskCleanup task for example.

 

The problem is not in scheduling, the backup does not work even if you start the task manually. When you do that, the task is running fine. As you can see I exported the tasks from 1709 (where backup works) and 1803 as xml and compared the hashes (I did not compare them manually), they're identical.

 

I think I am getting close …………..

I couldn't find default task scheduler settings for RegIdleBackup for Win 10. However, I found it for Win 7. Notice the settings I highlighted:

https://chentiangemalc.wordpress.com/2011/05/08/windows-7-default-scheduled-taskscomplete-overview/

 

You can't from the MMC. Export the task to XML and look at the file.

 

The Scheduled Task claims to have completed successfully. The folder is empty. Fortunately I run incrementals forever with Macrium, so it could be worse. As I write this I see that Microsoft is forcing me to lower my standards.

 

Microsoft explains the lack of Registry backups in Windows 10
June 29, 2019
https://www.ghacks.net/2019/06/29/microsoft-explains-the-lack-of-registry-backups-in-windows-10/

Microsoft: The system registry is no longer backed up to the RegBack folder starting in Windows 10 version 1803