[SOLVED] Server 2019 fails Cumulative Update with 0x800705AA

Follow these instructions to install an update with DISM.
  • Open the Start menu of Windows and type CMD.
  • When you see Command Prompt on the list, select the option Run as administrator.
  • Copy and paste the following command into it, and press enter. (Leave the CMD window open!)
Code:
MD C:\WUTemp
  • Now, download the following update (KB5025229) to: C:\WUTemp - Or copy this file from the download directory to C:\WUTemp. (Important!)
    Downloadlink: KB5025229
  • Copy and paste the following commands one at a time into the command prompt and press enter after each.
Code:
CD C:\WUTemp
EXPAND.exe windows10.0-kb5025229-x64_51315f30dd290d51ba049760d7c107c4b90b27c7.msu -f:* C:\WUTemp
DISM.exe /Online /Add-Package /PackagePath:C:\WUtemp\Windows10.0-KB5025229-x64.cab
  • Let me know if it says it was successful or if there are any errors. Or take a screenshot of the command prompt window and paste it into your next reply.
 
EDIT: It completed and threw the same error:

Code:
C:\WUTemp>DISM.exe /Online /Add-Package /PackagePath:C:\WUtemp\Windows10.0-KB5025229-x64.cab

Deployment Image Servicing and Management tool
Version: 10.0.17763.3406

Image Version: 10.0.17763.4010

Processing 1 of 1 - Adding package Multiple_Packages~~~~0.0.0.0
[==                         4.0%                           ]
An error occurred -  Error: 0x800705aa

Error: 1450

Insufficient system resources exist to complete the requested service.

The DISM log file can be found at C:\Windows\Logs\DISM\dism.log
 
This is what I was expecting, could you please run the same steps for DISM again with Process Monitor running.

Step#1 - Capture Process Monitor Trace
1. Download and run Process Monitor. Leave this running while you perform the next steps.
2. Try to install the update using DISM.
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 attach a new copy of the CBS logs as well.
 
Thank you for sending into PM, I have just checked the Procmon Trace. So here is the next step.

Download the
577bf0efb8088-FRST.png
Farbar Recovery Scan Tool and save it to your Desktop:

Download the 64 bit version: - Farbar Recovery Scan Tool Link
  • Open the startmenu and type the command cmd.
  • After you find the Command Prompt, right click on it and select Run as Administrator.
  • Copy and paste the following into the Command Prompt and press enter.
Code:
reg load HKLM\COMPONENTS C:\WINDOWS\SYSTEM32\CONFIG\COMPONENTS
Right-click on the file FRST64.exe and choose Run as administrator.
  • Copy and paste the following (code) into the Search box and click the Search Registry button.
Code:
KB5025229
  • When the scan is complete, a message will display that SearchReg.txt is saved in the same folder FRST was started from.
  • Post the logfile SearchReg.txt as attachment in your next reply.
 
Update: I've used some other filters for the ProcMon trace:

Rich (BB code):
5:25:15.5273358 PM    TiWorker.exe    17124    RegSetValue    HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackageDetect\Microsoft-Windows-ServerDatacenterEdition~31bf3856ad364e35~amd64~~0.0.0.0\Package_16_for_KB5025229~31bf3856ad364e35~amd64~~10.0.1.13    INSUFFICIENT RESOURCES    Type: REG_DWORD, Length: 4, Data: 2

1. I don't see any corruptions so this must be an configuration issue for this VM server.
2. The highlighted part "INSUFFICIENT RESOURCES" seems to be a common issue on VMware servers.

VMware said:
This fault occurs when an attempted operation conflicts with a resource configuration policy.

This fault may occur, for example, if a power-on operation reserves more memory than is allocated to a resource pool.

Retry the operation after adjusting the resources to allow more memory.
Source: https://docs.vmware.com/en/VMware-v...UID-08543383-EA9E-4FC0-B41E-6E9BE488E611.html


Edit:
Take a look at the ESX host's/var/log/vmware/hostd.log as well - if it contains a "Insufficient" (swap) message...
 
Last edited:
There is no hostd.log file that I can tell...

Strange that I have already powered off other VMs so that there should be no issues reserving RAM on this problem VM. And also I tried decreasing RAM. Maybe I'll try rebooting it without reserving any RAM?

My take is that "insufficient resources" is verbiage used both by Vmware and Microsoft, so search results might not apply. If I were seeing it in Vmware logs or in the GUI I would say it's a Vmware issue, but I'm not at that point yet. I still think it's an issue within Windows.

What about path length? It's getting really close to the limit documented at 260 characters (though I've seen issues in the 240's). I know, it wouldn't make any sense...
Code:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackageDetect\Microsoft-Windows-ServerDatacenterEdition~31bf3856ad364e35~amd64~~0.0.0.0\Package_16_for_KB5025229~31bf3856ad364e35~amd64~~10.0.1.13

Thanks!
 
A couple questions:

1) Is it worth running multiple times to see if it always fails at the same RegSetValue?

I've even booted this server as barebones as I can and it still failed (awhile back) but not sure if it was at this same point. My gut tells me it would fail at the same time because it's not about how much available RAM or Swap the VM itself has, but rather how Windows is handling this particular operation.

2) Would RAMMap help here? Running it as close to the failure as possible?

Thanks!
 
I did confirm that it always fails on that same RegSetValue.

I also saw that %Usage Peak for pagefile was 100.988%
1685023656946.png

I then increased the pagefile to about 30GB and ran it again. Same issue (haven't rebooted yet, though, will tonight). The climbing pagefile use is from Procmon though, not from the patch install.
 
Hi,

1) I've seen in the CBS logs it's always a different RegSetValue when it fails. So that's why I'am thinking it is not an Windows Update issue itself. But rather an configuration issue?
2) I'm not sure, but what you could try is to set the Registry Size Limit to "unlimited" and see what happens?

Code:
reg add HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control /v RegistrySizeLimit /t REG_DWORD /d 4294967295 /f

Source: [SOLVED] - Windows Update error unable to run SURT
 
1) I've seen in the CBS logs it's always a different RegSetValue when it fails. So that's why I'am thinking it is not an Windows Update issue itself. But rather an configuration issue?
Strange, because I saw in Procmon the same RegSetValue two times in a row.

I just tried the RegistrySizeLimit and that also didn't help. Thanks for the suggestion though.
 
Hi,

Rich (BB code):
2023-04-10 00:05:34, Info                  CBS    Failed to set registry value: Package_2605_for_KB5023702~31bf3856ad364e35~amd64~~10.0.1.10 [HRESULT = 0x800705aa - ERROR_NO_SYSTEM_RESOURCES]
2023-04-10 00:05:34, Info                  CBS    Failed to set DWORD value for name: Package_2605_for_KB5023702~31bf3856ad364e35~amd64~~10.0.1.10 [HRESULT = 0x800705aa - ERROR_NO_SYSTEM_RESOURCES]

Code:
2023-05-08 00:05:57, Info                  CBS    Failed to set registry value: Package_10_for_KB5025229~31bf3856ad364e35~amd64~~10.0.1.13 [HRESULT = 0x800705aa - ERROR_NO_SYSTEM_RESOURCES]
2023-05-08 00:05:57, Info                  CBS    Failed to set DWORD value for name: Package_10_for_KB5025229~31bf3856ad364e35~amd64~~10.0.1.13 [HRESULT = 0x800705aa - ERROR_NO_SYSTEM_RESOURCES]

In the first CBS log this error occured while installing the Servicing Stack Update, and then for Package_10 and later for Package_16. So it must be something with the configuration of this VM? I am not familiar wwith the ESXi settings. But perhaps this guide could be useful: VMware VM Performance Problems and How to Resolve Them
 
Well I'm at a loss here. I agree that the Access Denied shows up at inconsistent times in the install process, but I don't necessarily conclude that the issue is with the Vmware config. The VM is setup like the other few VMs on that same host and they have no update issues. Also setup similarly to hundreds of other servers at other clients. I also noticed tonight that the latest .NET Cumulative fails with the same error. Does this help at all?
 
I think I'm down to two options:
1) In-place upgrade via ISO (it's a Terminal Server, any caveats or just take a snapshot?)
2) As it's a Terminal Server, there are a couple of old, long-past-supported apps that are installed and might be corrupting the update process somehow. I could uninstall one-by-one and try the update again.

I'll have to plan for either of these. Any other thoughts appreciated. Thanks!
 
Hi,

I would try a repair install (in-place upgrade) first to see if it will resolve this issue.
 
I've never done it before so I don't want to assume... is it best to use the latest ISO download available and just boot to the installer?
Example: Repair Windows Server 2019 with in-place upgrade?

And is there any reason you'd recommend 2022 over 2019 as far as OS issues are concerned? Maybe there's a play here to just upgrade to 2022 for a more solid OS?
 
These are the instructions I normally use to perform an in-place upgrade.
  • Mount the Windows Server ISO and run Setup.exe. You can use the Microsoft Evaluation Centre to download the ISO files.
  • Use the option Download updates, drivers, and optional features (recommended) and click Next.
  • Depending on your Windows Server version and license, you may see a screen prompting you to enter the licensing key.
  • In the next screen, select the image of the installed Windows Server edition and click Next.
  • Then accept the EULA. To perform a in-place upgrade, you need to check keep personal files and apps. Then click Next.
  • After clicking Next, an upgrade process will start checking for updates, when this is ready click install to start the in-place upgrade.
 
Hi,

In your first ProcMon trace I noticed the following lines, could you please explain the second line and wherefore that location is used for? It seems it has to due with accessing local resources during a RDP session?
Rich (BB code):
12:01:41.5681237 AM    TiWorker.exe    9916    RegSetValue    HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackageDetect\Microsoft-Windows-ServerDatacenterEdition~31bf3856ad364e35~amd64~~0.0.0.0\Package_8_for_KB5025229~31bf3856ad364e35~amd64~~10.0.1.13    INSUFFICIENT RESOURCES    Type: REG_DWORD, Length: 4, Data: 2
12:03:24.4244204 AM    svchost.exe    3396    DeviceIoControl    \\TSCLIENT\SCARD\6    INSUFFICIENT RESOURCES    Control: 0x900e0 (Device:0x9 Function:56 Method: 0)

Edit:
Could you please perform the following steps as well:

Download the commandline tool
64959476d6f28-Handle.png
Handle from Sysinternals and save it to your desktop.
  • Create a new directory called Tools on your systemdrive C:\Tools.
  • Open Handle.zip and copy Handle.exe and Handle64.exe to C:\tools.
  • Open an elevated command prompt and open the tools directory with the following commands cd\ and cd C:\Tools
  • Copy and paste the following command and press enter. Click on the Agree butten when the license agreement for this tool appears.
    Code:
    handle -a -v "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackageDetect\Microsoft-Windows-ServerDatacenterEdition~31bf3856ad364e35~amd64~~0.0.0.0" >> %userprofile%\Desktop\UserHandles.csv
  • Afterwards a file with the name UserHandles.csv is saved on your desktop. Please ZIP this file and attach it to your next post.
 
Last edited:

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

Back
Top