[SOLVED] Server 2019 fails Cumulative Update with 0x800705AA

D

danrdj

Active member
Joined
Jan 9, 2023
Posts
44
Hello,

I have a Server 2019 VM that was patching fine until the past month or two.
SFC /scannow finds no issues
DISM /online /cleanup-image /restorehealth gives the standard "restore operation completed successfully"

I've tried to run the MSU installer as well as via Windows Update, both result in the same error 0x800705AA

Hard drive and Memory aren't close to being at full capacity.

EDIT: Also, RegistrySizeLimit is set to 0
 

Attachments

Hi,

How many RAM is assigned to this VM and how many free space is available?

Upload your COMPONENTS hive.
  • Navigate to C:\Windows\System32\Config and locate the COMPONENTS file.
  • Please copy this file to your desktop.
  • Note: If you receive an error that this file is in-use, simply reboot your computer and try again.
  • Right-click on this file on your desktop and select Send To > Compressed (zipped) folder. This will create a file named COMPONENTS.ZIP on your desktop.
  • If the file is too large to upload here, upload the file to www.wetransfer.com and post the link in your next reply.


Export CBS (Component Based Servicing) hive
  • Click on the Start button and type regedit
  • When you see regedit on the list, right-click on it and select Run as administrator.
  • When regedit opens, using the left pane, navigate to the following registry key and select it by clicking on it once.
    Code: 
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing
  • Once selected, click File > Export....
  • Change the Save as type: to Registry Hive Files (*.*).

    622dbef75cd3a-Export-CBS-hive.png

  • Name this file ComponentBasedServicing (with no file extension) and save it to your Desktop.
  • Right-click on the saved file and choose Send > Compressed (zipped) Folder.
  • Attach the .ZIP file to your next post.
  • If the file is too large to upload here, upload the file to www.wetransfer.com and post the link in your next reply.
 
Okay, please attempt to update with Process Monitor running. When ready attach a new copy of the CBS logs as well.

Step#1 - Capture Process Monitor Trace
1. Download and run Process Monitor. Leave this running while you perform the next steps.
2. Try updating the system just like you have in the past.
3. Stop Process Monitor as soon as it fails. You can simply do this by clicking the square (CTRL +E) on the toolbar as shown below.



4. Select the File menu...Save... and save the file to your desktop. This is likely the default location. The name (unless changed) will be LogFile.PML. This is fine.
5. Zip up the LogFile.PML and upload it to WeTransfer - Send Large Files & Share Photos Online - Up to 2GB Free and provide the link.
 
As the PML could contain sensitive data, is there a filter I can apply that would give you just the info you're looking for?
 
You can also send me the link in a private message so it is not public?
 
Hi,

Thanks for sharing the Process Monitor trace, I've seen this server is running in a VMware environment.

danrdj said:
Memory is 4GB used of 24GB. Hard drive is 80GB used of 124GB.
Click to expand...

How is this server and the virtual machine configured:

1. Do you have access to the host of this VM that run out of memory?
2. Does the VM have dedicated RAM assigned?
3. If you are using a VM with dynamic memory allocation, please contact your host to resolve this issue.
 
1. Yes, I have access to the host.
2. The VM has its allocated RAM reserved.
All VMs on this host use 90GB of total 128GB.
 
Hi,

I assume the ESXi host is running version 7.0 update 1 or later? Due to the amount of allocated RAM this may be an issue with insufficient swap space when Windows Update is running with only 44 GB of free disk space. Since there is only 4GB of RAM usage you could try to decrease the ammount of RAM to 12GB and see what happens.
 
Hello,

Yes it's ESXi 7.0 U1

Since the allocated RAM for VMs is 38GB shy of total host RAM, there aren't any issues getting physical RAM to each guest.
All but one VM had reserved the allocated RAM, so only that one VM will be creating a vswp file if the need was there -- that one being up to 24GB. But as above, no need for it.
The datastore has >2TB free so if it did create a 24GB vswp file that wouldn't be an issue.

Into the VM itself, C: has 68GB free and is now using 7GB of its allocated 24GB of RAM. The paging file is set to Auto and is currently at 11GB, but perfmon shows paging file usage is 0%.

I'll run the update again and watch those metrics, but I don't see how RAM/swap space could end up being an issue.

Thanks,
Dan
 
Hi,

Let's see how it goes with 68GB of free space, but I don't think this is the main issue for this VM. When a VM is swapping to the datastore it uses the available RAM of the host as well. Error 0x800705AA usually indicates the host is running out of memory. I don't know how many VM's are running, but 38GB of free memory of 128GB could be an issue on high load / usage at the same time.

I always prefer to keep at least half of the available memory free on the host. Is this host running 4 (or more) VM's with 24GB assigned?
 
I just don't see how the VM would swap to the datastore with the "reserve all" checkbox checked. Am I misunderstanding something there?

VM1: 24GB
VM2: 32GB
VM3: 24GB
VM4: 8GB

Across all our servers I would say we leave at least 8GB RAM for the host itself and don't see this patching issue elsewhere.

I'm certainly open to trying this theory but just putting that out there. Thanks!
 
As I was expecting there are 4 VM's active and the host might be running out of memory in this cofiguration.

I would try the following settings on the host first:
  • VM1: 16GB
  • VM2: 16GB
  • VM3: 16GB
  • VM4: 8GB

danrdj said:
Across all our servers I would say we leave at least 8GB RAM for the host itself and don't see this patching issue elsewhere.
Click to expand...

Are these servers identical?
 
Hello,
I shutdown the other 3 VMs and still had the same issue. Also decreased the VM's memory from 24GB to 16GB as suggested and no change.
The other physical servers we managed are probably not completely identical to this one, but given the fact that 3 other Server 2019 VMs are patching fine on the same hardware, I don't think this to be an issue with the host.
There must be something messed up with Windows itself to report that it's running out of resources (memory) during patching.
Thanks,
Dan
 
Hi,

Let's try something else, please remove the RegistrySizeLimit value.
Code: 
reg delete HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control /v RegistrySizeLimit /f
 
Hi,

Open an elevated prompt, run the following commands and copy and paste the result in your next post.
Code: 
DISM /online /cleanup-image /AnalyzeComponentStore
DISM /online /cleanup-image /StartComponentCleanup
 
Code: 
C:\Windows\system32>dism /online /cleanup-image /analyzecomponentstore

Deployment Image Servicing and Management tool
Version: 10.0.17763.3406

Image Version: 10.0.17763.4010

[===========================99.7%========================= ]

Component Store (WinSxS) information:

Windows Explorer Reported Size of Component Store : 8.59 GB

Actual Size of Component Store : 8.29 GB

    Shared with Windows : 6.23 GB
    Backups and Disabled Features : 1.95 GB
    Cache and Temporary Data : 97.01 MB

Date of Last Cleanup : 2023-05-18 19:34:16

Number of Reclaimable Packages : 0
Component Store Cleanup Recommended : No

The operation completed successfully.

Code: 
C:\Windows\system32>dism /online /cleanup-image /startcomponentcleanup

Deployment Image Servicing and Management tool
Version: 10.0.17763.3406

Image Version: 10.0.17763.4010

[==========================100.0%==========================]
The operation completed successfully.
 
You must log in or register to reply here.

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top