[SOLVED] [Win10 1607] Manually Edited System Keys & Files - Later, After Updating, No Boot

[LiterallyAnythng]

I apologize in advance- I read the thread posting instructions but I'm currently at a point where I can't get a CBS log to write out due to the fact that "logging is not available in offline servicing operations". I'm sure there's a way to get past this, just please let me know. Until then here's a description of my issue-

Backstory (reasons why this occurred)

I was sick of Microsoft shoving updates down my throat and pushing out "features" that user's are unable to disable without jumping though hoops (which are not supported by MS anyway). I also really wanted Cortana gone, but that can't happen since Windows will just undo your changes and/or find other ways to make these services run regardless of what the user wants.

So what I did in order to disable various "features" like Windows Store, Cortana, Windows Store, and to add BACK in the missing ability to set an Ethernet connection as metered, and Windows Update- was remove the ACS permissions for TrustedInstaller and gave myself ownership of directories WinSxS and whichever directory has the files for Cortana. I also edited multiple registry keys. In the end it disabled some of the features but Windows was still able to simply recreate some of the files and run some of the services under a new name (same name but with a hex ID prepended to it). That's some sneaky stuff, but I stuck with it because at least I was able to get rid of the annoying Windows app store and didn't have to deal with Cortana or forced Windows Updates. In other words, after these change my system was still stable and never had any issues booting up. That was, at least, until I decided I should allow Windows to update after about 6 months of not.

I tried to simply manually run Windows Update but upon restart my system would state that it failed and would revert. I then attempted to remember what the exact changes I made 6 months prior were, but since so much time had already passed I essentially forgot everything except from what I mentioned above. So in a moment of pure stupidity I decided running SFC would be an appropriate solution to begin with.

When it booted up again I was met with a bluescreen and Win RE. I then made another stupid decision to allow Windows to try and repair it for me. This caused more issues. On the next boot I had NO Recovery Environment, just the boot options menu (debug, run in safe mode, disable driver signature check, etc.). I found via DiskPart that Windows had renamed my drive lettering and, to make things worse, BootRec /ScanOS could no longer find my Windows BCD (or thinks of it as corrupted since I can see that the file is indeed in there).

Attempted fixes: Windows Recovery Environment tools that only made things worse.

I did multiple SFC scan and repairs from the CLI to no avail.

I set my actual root volume as the active volume in DiskPart and all my drives are showing as they once were, but Windows still won't boot specifically because "winlogin.exe" checks the hashes of these files and when there's a mismatch it immediately kicks you to a bluescreen with error code "0x21a".

Extra tidbits-

Somewhere along the line I believe my BCD file got messed up. BootRec says it cannot repair my MBR because it's a GPT volume, but it isn't. It SHOULD have been, but when migrating my old root disk (HDD) to my SSD I decided to partition it as MBR so as not to run into any compatibility issues... which was never a problem until now.

I have an image of 1607 on a flash drive right now and I'm wondering if I can just replace these files or what (lol probably not). Performing a system reset OR restore is VERY undesirable for me for numerous reasons to the extent that I will manually edit whatever I have to character by character in order to avoid that.

When I attempt to view the CBS log from the SFC scan I don't see one that was created since this issue started occurring. SFC states that logging is disabled in offline servicing scenarios (which this would be since Windows PE is running off of a USB and not my root drive as I attempt to fix this issue). Is there a way to pipe the log out somewhere anyway? I couldn't find a recent answer to this on Google.

The CBS log for the scan that I did originally references a ton of "DIRSD OWNER WARNING"s which are obviously files/directories that I messed up the ownership of. It also references duplicate owner entries. In both cases there are quite a few.

The files that it found were corrupted are-accserv.mibfdeploy.dllfde.dllgpedit.dllgptext.dll

Note that it also mentions that they cannot be repaired because the files in the store DB are also corrupted.

DISM reports that it is unable to find any providers and also states that "C:\Windows" is not a valid Windows folder because it is "unable to set the DLL search path to the servicing stack folder" even though I believe I'm specifying the correct arguments and parameters -

"DISM /Image=C:\ /Cleanup-Image /AnalyzeComponentStore /WinDir:C:\Windows\ /SysDriveDir:C:\ /ScratchDir=D:\DISM\Scratch"

Here's my SFC command too-

"SFC /ScanNow /OffBootDir=C:\ /OffWinDir=C:\Windows"

/ScanOS is able to recognize that there is indeed a Windows image on that drive.

---------

If anyone can assist with how to pipe out the CBS log manually I can then upload it.

Thanks in advance.

 

[LiterallyAnythng]

Re: [Win10 1607] Manually Edited System Keys & Files - Later, After Updating, No Boot

Tried a previous command I found to route the cbs log, which was stated to not work, but it did for me and I was able to get my CBS log! I was too excited to give it much of a look, but all I saw was permissions issues for a handful of files. Hopefully it's just as simple as modifying ACS (or whatever it is now) on those files, but I'll wait to see what you guys say.

Also, since then, I set my System Reserved partition as "Active" in DiskPart, which seems to have done nothing but reset my drive lettering again (probably because, as I just noticed, my system reserved partition is empty).

FYI- When this issue first started (not being able to boot) I made a backup of my BCD as it was, if that makes any difference.

View attachment cbs.zip

 

[LiterallyAnythng]

Re: [Win10 1607] Manually Edited System Keys & Files - Later, After Updating, No Boot

Don't mean for this to be a "bump" at all, I just can't edit my previous posts.

I removed all "verify" and "primitive installer" entries and I'm left with around 2k lines of, essentially, permissions errors. What I don't understand are the "Servicing stack shim unable to mark handle #" entries, of which there are two each at the beginning and end of the scan.

I can batch fix the permissions errors no problem, I just hope this is the right course of action.

 

[BrianDrab]

Re: [Win10 1607] Manually Edited System Keys & Files - Later, After Updating, No Boot

Hi and welcome to Sysnative. Sorry for the delay. Are you still in need of assistance?

 

[LiterallyAnythng]

Re: [Win10 1607] Manually Edited System Keys & Files - Later, After Updating, No Boot

Hello and thank you for the response.

*Rant (non-pertinent at this point, feel free to ignore)*
After three weeks of dealing with the issue and researching I came to the conclusion that it simply was not worth the effort to try and recover my environment. I found out too late that Microsoft didn't account for UEFI & USB in the Win RE (even though the Windows Media Creation Tool knows full well that it was booted in UEFI), and so any commands that had been run previously which default to the current system drive in memory did nothing to my actual Windows environment, and by that point it was already an immense task trying to back-track and determine what all had been successful and what hadn't.

The root cause of the issue, which comes up commonly on these forums and many others as well it seems, was Windows RE "startup repair" clobbering my drive lettering in the first place because it fails to account for so many obvious situations, none the least being as pertinent as taking into account the possibility of systems having both MBR & GPT drives and drives with old MS installation partitions, and since the utility doesn't ask the user for any input whatsoever, the actions performed were entirely incorrect. By some stroke of genius programming which couldn't possibly at all be the result of laziness (and by extension extremely poor ITIL practices) the utility decides, with no user input whatsoever, that even though the RE was loaded from a different psychical disk entirely which contains thousands upon thousands of registry keys/system files/partition information/etc right on the very root, it's going to NOT take ANY of that into account and instead reconfigure the entire system to boot into whatever installation comes up first from the equivalent (or actual) result from a simple "bootrec /scanos".

After realizing these very pertinent lack of considerations on Microsoft's behalf, none of which are mentioned until you actually look them up because you have the problem, when the Windows 7 recovery console came up my heart sank, and it then became a game of figuring out "what did I all do up until this point? How do I know what actually worked and what didn't?", and I still stupidly gave it a try. The thing is, when you realize that you're so far deep after seeing your BCD file grow to 23 entries long, looking at contradictory CBS and DISM logs and not able to make out why the same errors continue to appear but aren't at all able to be traced back when checking deeper in WMIC (likely a result of the confusion caused by UEFI bootable USB drives), and in the end (although this was on me), corrupted partition entries on the drive sectors... you just kind of give up.

As a last-ditch effort I overwrote any mismatched files in all system directories, reset permissions by exporting an ACL list with all the system account configurations from a clean 1607 install and applying it to my image, and everything again. I was likely pretty close as I was able to get the image recognized but it would only go to the boot menu as I had already ruined the system reserved partition due to the sheer confusion of me (and apparently Windows itself as well) executing commands on one drive and not the other without ever knowing it (it doesn't help at all that SFC returns quite a lot of errors when it is run against the fresh Win Media Center Creation, and later the Win 1607, USB images).
*/end rant*

The only issue I have at this point is that I know I made, not one, but a total of three separate, offline (to other drives) backups of that drive before and AFTER stripping all ACL/ACS and file attributes from the drive, and yet for some reason I'm completely missing the root:\Users\ directory which is the only directory I actually cared about and is the most important and essential.

There's a file in the current "$WINDOWS.~BT" directory which is labeled "FolderMoveLog.txt" detailing moves from "Window.old" to "Windows" on the system root, but none of the entries reference any files from my previous installation. For example, here is how one of the entries looks-

"C:\Windows.old\Users\Christopher\AppData\Local\Microsoft\Media Player\CurrentDatabase_400.wmdb|C:\Users\Christopher\AppData\Local\Microsoft\Media Player\CurrentDatabase_400.wmdb|H|CURREN~1.WMD"

The user "Christopher" was not the name of any user on my previous installation, only my current. There are no references to my previous user account. Is that directory gone for good (especially considering the drive was freshly formatted prior to the new installation)? Could the Panther\Rollback directory be useful at all? Ex-

"C:\Windows\Panther\Rollback\MachineIndependent\Transformers\CBS\boot_volume\Users"

Thank you.