Windows 10 bug prevents Registry backup creation

I do but, as pointed out by Martin Brinkmann, the backup folder is empty. Let's hope MS will fix it soon.

 

Directory is also empty on my Win 10 x(64) 1803 build.

 

Believe I know what the problem is.

The task is not running with "highest privileges." As such, it cannot access this directory, C:\Windows\System32\config\, just like you can't.

 

No. I tried that. It makes no difference here.

I'm on 1803 atm.
I have the task, but the 'triggers' tab is empty. I also have regidle.dll in Windows\system32. The folder and all 5 files are there but the files are 0-size.
When I run the task manually, it runs and finishes fine but the files stay 0-size.

 

The task runs as 'SYSTEM' not 'Local". (service or user)

 

Last modification date of 0-byte files is 04-May-18.

[EDIT] Guesswork. I think this is a removed feature. Badly removed, with leftover junk.

I reimaged to 1809 -



The folder is there but it is empty.

 

(sorry for jumping on this like crazy, but I like this stuff)

More info -



So the dll is called by the task, but it does nothing.

 

As best as I can determine, anything associated with this processing except trustedinstaller only has read and execute privileges.

 

Ignore post #8. the dll is not called by the task. The date/time is that of image restore...
I was too quick.

 

This is what I know.
What Martin is seeing there with the task running for 30mins. is normal for Windows Task Scheduler. It is a bad facility. You actually have to close it and open it again to see if the task stopped.
Nirsoft makes TaskSchedulerView that shows more accurate/additional info.

 

And tinkering with permissions on Windows 10 units can make for some unsettling moments and of course loss of time.

Enter Tweaking.com's Windows Repair Pro which backs up permissions on a separate level. If Windows doesn't recover from that repair process then something else may be seriously in doubt.

One thing I ran into with Windows 10 most recently was some enhanced mechanism guarding permissions and it didn't care for my making adjustments manually with a Third Party worker. Tweaking.com was the sole exception.

 

I am just showing how an app/dll running with SYSTEM privileges can write to that folder.
It's the default, I haven't changed anything.

 

I'm unable to open the glhacks link at the moment, but the backups are being made on my system. However I am still stuck on build 1709 of Windows 10.

Also tweaking.com's Registry Backup (which is installed with their Windows Repair software) creates a registry backup, which can be restored from the Recovery Console, at every startup.

 

I don't mean anything by it or to even dissuade that good n accurate suggestion. In fact you guys easily IMO have a much better handle on 10 workings-troubleshooting than I could ever form an opinion against. But, am keenly aware that Windows 10 seems from this end to have better revamped permissions (as an effort to enhance & safeguard?). What was once easy enough access/modifying (even temporarily) by changing permissions to some degree with certain tools, I ran into difficulty not experienced before on earlier versions which I naturally assumed this time was intentional on Windows as part of a protection scheme.

FWIW, when switching from SYSTEM to another Owner/Objects/Inherit Permissions (since some of my Windows 10 desktop files complained of no access as we seen before), I must have cross connected a setting BUT resetting back to SYSTEM ACL corrected the error. However there was also experienced an overlap of some sort where not ALL default permissions were returned. Hence my mention that tweaking.com repaired that blunder, or as the 10 system seen it, an interruption of expected permissions balance/order intended.

This is a great discussion since SYSTEM as you point out appears to exhibit the highest order of the file permissions chain which in turn as you rightly point out, makes for the top Privilege that can allow the user to access that folder.

Thanks for your understanding and excusing my limitations on the matter.

 

You can clearly see from these 2 screenshots that the dll (finally) is called by the task -



However, I am still unable to reproduce that for the second time. Task runs fine, but the accessed time on the file does not change.

 

Here it is -




The files are still there, 0-sized, the date of modification is 04-May-18.
This is all on 1803.

 

Guys,

what is the exact size of your regidle.dll file?
Possibly hash.

[EDIT] Here's mine

 

I have managed to dig out one of my older backups of 1709 and restored it. Everything works fine, the task is calling the dll and the registry is fully backed up.
I compared folder permissions and tasks (by exporting them to xml file) of 1709 and 1803. These are both identical. Then I checked the hash of regidle.dll in 1709 and it was completely different -

So as I see it, there is nothing wrong with the task, the file has been changed in one of the cumulative updates. Around April-May. And it does not back up registry any more.

 

Amazing - sadly so.

This was know to Microsoft as far back as July: https://answers.microsoft.com/en-us...es-empty/50fcd6d0-73fa-48d6-b716-46912a013d37 .

Here's another detailed reference from Aug.: https://blog.1234n6.com/2018/08/has-regback-been-retired.html

It also appears that the missing reg. backup can cause major issues when trying to repair Win 10. At least now I have any explanation for why a Win 10 repair always failed and never appeared to run correctly on 1803.

 

Itman, good find.
Adam basically confirms what I have observed.

I have also found this official info from Microsoft. Apparently there were some changes as to how kernel memory space is allocated for registry -

Unfortunately, anything from this point on is a heavy guesswork. There is no way to see what is in the dll file. The hash of 1809 version of it (I mounted the image and extracted it) is a third figure (different).

 

And of course, there is only one thing left to try. Extracting the file from 1709, setting the right owner (TrustedInstaller), and placing it in system32 folder of 1803/9.
While I have strong indicatons that'll work (from what is here seen), I'm not doing that as there is no point.

 

Below is a Process Explorer screen shot of it.

Now here is something of concern I just noticed in regards to 1803 Core Insolation - Memory Integrity. The screen shot shows that "Secure System" is suspended? However when I view it in Win Task Manger, it is not. Hopefully this is just a bug in Process Explorer?

 

Are you using any type of virtualization that isolates memory addresses? If so, everything is fine. The "Secure System" you're seeing may not have to do anything with this here, as my Process Explorer does not show it. And I'm not using any security features/apps (ouch).

[EDIT] Again, the link with Microsoft info I gave is a guess. Maybe someone more knowledgable can weigh in.