[SOLVED] Unable to install Cumulative Updates since 2023-12 - Windows 10 22H2 (19045.3570)

You should take into account that the previous installation became corrupted due to the lack of free space, so when you clone this drive you will copy the corruptions over to the new drive. Even when you have a lot of free space now, it doesn't mean that all the issues suddenly fixed now!

1. What is the result of the reset option when you try to perform a repair install?
2. Which message do you get when try to boot from this cloned drive?

I wonder if you get a real BSOD screen or just a "blue screen" because Windows can't boot from this drive. Can you please take a picture of this screen to attach it here?
 
Yeah I figured that, outside of a miracle :ROFLMAO:
I just checked, in the Windows folder I have a MEMORY.DMP.
Is this it? Around 550MB in size?
If so I’ll get it uploaded and sent.

The BSOD says CRITICAL PROCESS DIED.
I haven’t tried repair yet, just wanted to exhaust all possibilities before I try that
 
Thank you, it seems this is an 0xEF issue as documented here: The Special BSOD Reason: 0xEF and 0xF4

As already stated I'm not a BSOD expert so we'll need to wait for @x BlueRobot or @axe0 if they want to look at this issue.

Rich (BB code): 
FAILURE_BUCKET_ID:  0xEF_wininit.exe_BUGCHECK_CRITICAL_PROCESS_e995140_ntdll!NtTerminateProcess

Rich (BB code): 
 # Child-SP          RetAddr           Call Site
00 ffffa38b`8aa27878 fffff807`6c10e5a2 nt!KeBugCheckEx
01 ffffa38b`8aa27880 fffff807`6c01613f nt!PspCatchCriticalBreak+0x10e
02 ffffa38b`8aa27920 fffff807`6be81fdf nt!PspTerminateAllThreads+0x15dfaf
03 ffffa38b`8aa27990 fffff807`6bc10ef5 nt!NtTerminateProcess+0x16f
04 ffffa38b`8aa27a00 00007ffe`900cd564 nt!KiSystemServiceCopyEnd+0x25
05 0000009d`de4cf828 00007ffe`9008da34 ntdll!NtTerminateProcess+0x14
06 0000009d`de4cf830 00007ffe`8e41e3bb ntdll!RtlExitUserProcess+0x54
07 0000009d`de4cf860 00007ffe`8dc905bc KERNEL32!ExitProcessImplementation+0xb
08 0000009d`de4cf890 00007ffe`8dc9045f ucrtbase!exit_or_terminate_process+0x44
09 0000009d`de4cf8c0 00007ffe`8dc93774 ucrtbase!common_exit+0x6f
0a 0000009d`de4cf910 00007ff6`f7a848f8 ucrtbase!__crt_state_management::wrapped_invoke<void (__cdecl*)(int),int,void>+0x20
0b 0000009d`de4cf940 00007ffe`8e417344 wininit!__scrt_common_main_seh+0x168
0c 0000009d`de4cf980 00007ffe`900826b1 KERNEL32!BaseThreadInitThunk+0x14
0d 0000009d`de4cf9b0 00000000`00000000 ntdll!RtlUserThreadStart+0x21
 
Thanks.
Looking at that post, I see RAM is mentioned. Whilst we wait, are there any memory tests you can recommend? Just to rule out hardware being a possibility.

(Although would my boot USB run properly, if at all, if there was a memory issue?)
 
Just an update regarding hardware, I ran the HP UEFI RAM test and it passed. (No clue how extensive that test is though).
Seeing as there's a lot more space now to fix file system corruption, I ran CHKDSK again but it still found no errors.
 
DM-TGG said:
Is there a setting in the registry I’m not aware of that triggers minidumps to be created?
Click to expand...
There's a few "rules" like having sufficient free disk space; page file being on the Windows disk and the page file being managed by the operating system. The registry key which controls the dump file settings is:

Code: 
HKLM\SYSTEM\CurrentControlSet\Control\CrashControl
 
DM-TGG said:
Whilst we wait, are there any memory tests you can recommend?
Click to expand...
MemTest86 is the de facto testing tool for RAM, you'll need to run it for at least 8 passes though.

Test RAM with PassMark MemTest86 (version 10.6 was used)



This doesn't look like a hardware error though, it seems that the process couldn't even start because of some system corruption, which @Maxstar did mention would be risk of cloning the original installation across.

Rich (BB code): 
1: kd> dt _EPROCESS -y Exit ffffe7820e98d280
ntdll!_EPROCESS
   +0x460 ExitProcessReported : 0y0
   +0x7d4 ExitStatus : 0n14001
   +0x840 ExitTime : _LARGE_INTEGER 0x0

Rich (BB code): 
1: kd> ? 0n14001
Evaluate expression: 14001 = 00000000`000036b1

Rich (BB code): 
1: kd> !error 36b1
Error code: (Win32) 0x36b1 (14001) - The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.
 
Thanks. I had a quick look in the Application log (attached) and did find reference to a SxS error:

Rich (BB code): 
Activation context generation failed for "C:\WINDOWS\system32\conhost.exe". Dependent Assembly Microsoft.Windows.SystemCompatible,processorArchitecture="amd64",publicKeyToken="6595b64144ccf1df",type="win32",version="6.0.0.0" could not be found. Please use sxstrace.exe for detailed diagnosis.

Don't know if this is irrelevant though.

As I can't use sxstrace due to the boot failure, would a full dump (which I don't think that was?) provide more information as to what SxS is causing the issue? I did try DISM and SFC again but both insist that no corruption was found.
 

Attachments

Please provide a copy of your SOFTWARE hive to look at, please send it to us both, using this link: https://www.sysnative.com/forums/conversations/add?to=x-bluerobot,maxstar

Retrieve SOFTWARE Hive
Note: The SOFTWARE hive has confidential and sensitive information in it so please send us a PM with a link to that particular hive so it's not in the public form.

ZIP the file: C:\Windows\System32\config\SOFTWARE and share it in a private message.
 
The last dump you provided was a kernel memory dump but unfortunately it isn't going to reveal which file(s) or registry keys are corrupt or missing. It's unfortunate that you can't run the SxSTrace tool since that would have been a great help, however, you could check the following:

1. Do you have a .manifest file in the %systemroot%\WinSxS\Manifests folder of the cloned drive with a name similar to: amd64_microsoft.windows.systemcompatible_6595b64144ccf1df_?

2. With the cloned drive, are you able to obtain a copy of the SOFTWARE hive and then load it on a different machine?

Edit: For step 2, please follow the instructions as requested by @Maxstar.
 
1. I just checked and can't find that manifest.
Edit: There isn't one that's even close to being similar to that either
2. Done, zipped and PMd to both yourself and @Maxstar
 
Please provide a copy of the following folder - including a new copy of the COMPONENTS hive.

C:\Windows\WinSxS\amd64_microsoft-onecore-console-host-core_31bf3856ad364e35_10.0.19041.3570_none_e23d33f7d97d356f
 
x BlueRobot said:
Do you have a .manifest file in the %systemroot%\WinSxS\Manifests folder of the cloned drive with a name similar to: amd64_microsoft.windows.systemcompatible_6595b64144ccf1df_?
Click to expand...
Just to note: the associated components key is missing the "Identity" and "SHA256" value. I've checked some other keys as well, and they are missing the same values and/or the f! marks. The SBS key in the SOFTWARE hive looks good, so that is not the issue. So I think it is a combination of payload corruptions inside the WinSxS/Manifests folder and a corrupted COMPONENTS hive. However, the core issue seems to be inside the WinSxS folder.

You have used the Hiren's Boot CD to run DISM, I would suggest to run DISM again but then from the Recovery Environment (command Prompt) with the ISO of Windows 10 as source. Replace X: with the correct drive letter and change the number after wim to select the correct Windows Version.
  • Windows 10 Home = 1
  • Windows 10 Education = 4
  • Windows 10 Pro = 6
  • Windows 10 Pro Education = 8
Code: 
DISM /Online /Cleanup-Image /RestoreHealth /source:WIM:X:\Sources\Install.wim:1 /LimitAccess
 
I've tried running from both the Recovery Environment and Hiren's again (which is based off Windows 11); it completes successfully wherever I run it, and /CheckHealth doesn't detect any corruption, but still no luck. I've attached a new DISM log; note that despite it clearing with no errors, there appear to be a significant number of broken manifests detected early on in the process.

Recall earlier that I still have my working registry backup. Are manifest files hashed against a particular install, or are they generic? If so (and this may be a very stupid question), could I not just replace the COMPONENTS file with the backup, make a copy of the manifests folder from another 22H2 laptop and just replace every file, either manually or by somehow running SFCFix?
 

Attachments

DM-TGG said:
Recall earlier that I still have my working registry backup.
Click to expand...
The latest COMPONENTS hive provided is badly damaged, so which 'working registry backup' are you refereing to? I've asked in post #25 for backups and you didn't have them?

DM-TGG said:
Are manifest files hashed against a particular install, or are they generic?
Click to expand...
See post #40, as pointed out by @x BlueRobot many files in the Component Store (WinSxS folder) are compressed. Looking at your latest DISM.log it shows a number (almost 8000) corrupt *.manifest files. Please note that those corruptions are related to the COMPONENTS hive and missing values.

DM-TGG said:
(...) could I not just replace the COMPONENTS file with the backup, make a copy of the manifests folder from another 22H2 laptop and just replace every file.
Click to expand...
Which backup of the COMPONENTS hive? If this is the same file as in post #75 - I do not recommend to perform such a 'MacGyver' fix...
 
The first time I ran FRST (the day before the boot corruption started), it made a registry backup (including the COMPONENTS hive); that's what I've been referring to. Apologies, I assumed you meant a full system backup/image.

It should be the same as the very first one I sent you in post #4.
Maxstar said:
Which backup of the COMPONENTS hive? If this is the same file as in post #75 - I do not recommend to perform such a 'MacGyver' fix...
Click to expand...

Guessing this is due to the various system file permissions surrounding the registry/manifests? Is there a safer, more formal way to do this, seeing as whichever way I run it, DISM is acknowledging the manifest issues but ignoring them also?
 
When we used FRST, this system was already running out of space, so the backups of the registry made by FRST are not reliable either.

DM-TGG said:
Guessing this is due to the various system file permissions surrounding the registry/manifests? Is there a safer, more formal way to do this, seeing as whichever way I run it, DISM is acknowledging the manifest issues but ignoring them also?
Click to expand...

I'm very sorry to say but this has nothing to do with permissions or rights. The problem was that this installation of Windows became corrupt due to the lack of free space.

You have already cloned the old drive, so I would suggest to perform a repair install on the new drive. Then you have always the old drive as spare / backup.

Let us know if the repair install on the new (cloned) SSD was successful or not.
 
You must log in or register to reply here.
Back
Top