Share via

AppXSVC forced to 'Automatic' on Server 2025

Thomas Jedelhauser 0 Reputation points
2025-12-13T16:24:37.93+00:00

A issue has been observed on Windows Server 2025 following the installation of the Cumulative Update KB5072033 (December Patch Tuesday).

1. Issue Description

• Affected System: Windows Server 2025 Standard/Datacenter.

• Trigger: The issue appeared immediately after installing KB5072033.

• Service Behavior: The AppX Deployment Service (AppXSVC) is permanently configured to the "Automatic" start mode.

• Impact: Since AppXSVC is typically set to "Manual" on Windows Server environments, this setting leads to continuous and resource-intensive STOP/START cycles which are being flagged by monitoring solutions (e.g., Zabbix).

• Differential Behavior: This behavior is not present on comparable Windows Server 2022 installations.

Is the forced "Automatic" setting for AppXSVC on Windows Server 2025 intended behavior as part of KB5072033 or a new Server Security Baseline, or a Bug?

Regards

Thomas

Windows for business | Windows Server | Devices and deployment | Other
0 comments
Answer accepted by question author
  1. VPHAN 10,795 Reputation points Independent Advisor
    2025-12-13T17:19:42.5566667+00:00

    Thomas Jedelhauser, the "Access is denied" response confirms that the security descriptor for the AppXSVC service has been hardened in this update, effectively restricting write access to the NT SERVICE\TrustedInstaller account. This is a common protective mechanism for core OS services to prevent tampering, but in this context, it effectively locks you into the buggy behavior introduced by KB5072033. Since standard administrative privileges are insufficient to invoke the Service Control Manager (SC) against this ACL, you must bypass the standard service APIs and modify the configuration directly within the Windows Registry by temporarily taking ownership of the specific key.

    To resolve this, open the Registry Editor (regedit.exe) as an Administrator and navigate to the path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AppXSVC. You will likely find that you can't edit the values immediately. Right-click the AppXSVC folder (key) on the left pane and select "Permissions," then click "Advanced." In the "Owner" field (which will currently list "TrustedInstaller"), click "Change," type Administrators (plural), and apply the change. Once you are the owner, return to the Permissions window and grant the Administrators group "Full Control" over the key.

    With write access established, locate the DWORD value named Start in the right-hand pane. It will currently be set to 2 (Automatic). Change this value to 3 (Manual). This is the hexadecimal equivalent of the standard "Manual" startup type and will stop the Service Control Manager from aggressively restarting the service after it idles out.

    Once the modification is complete, it is critical for system integrity that you restore the original permissions. Go back to the Permissions > Advanced > Owner settings for the AppXSVC key and change the owner back to NT SERVICE\TrustedInstaller. You may need to type the full name exactly as written here. Finally, remove the explicit "Full Control" entry you added for Administrators to return the ACLs to their default secure state. A reboot is not strictly required for the change to take effect, but you should see the AppXSVC service settle into a "Stopped" state immediately without restarting.

    1 person found this answer helpful.

2 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. VPHAN 10,795 Reputation points Independent Advisor
    2025-12-13T17:02:53.5133333+00:00

    Hello Thomas Jedelhauser,

    Based on the symptoms described and the behavior of the AppX Deployment Service (AppXSVC) in previous Windows Server iterations, the forced "Automatic" setting causing start/stop loops is almost certainly a regression introduced by the manifest in KB5072033, rather than an intended change in the Security Baseline. Windows services that are designed to run permanently (Automatic) do not typically shut themselves down immediately after starting; the behavior you are seeing, where the service starts, finds no active work, exits, and is then aggressively restarted by the Service Control Manager (SCM) because of the "Automatic" flag, confirms that the binary still expects to operate as a "Manual (Trigger Start)" service, but the update package has incorrectly overwritten the service start configuration.

    To resolve the immediate impact on your monitoring systems and stabilize the server's resource usage, you should manually revert the service configuration to its standard state. You can execute sc config AppXSVC start= demand in an elevated command prompt to set the startup type back to Manual. It is crucial that you do not "Disable" the service entirely, as AppXSVC is required for various OS components, including parts of Server Manager, the Settings app, and the modern servicing stack used by future Cumulative Updates. By setting it to Manual, you allow the existing service triggers (which you can verify using sc qtriggerinfo AppXSVC) to start the service only when specific OS tasks require it, allowing it to gracefully terminate when idle without the SCM interpreting that termination as a failure.

    Given that this behavior is isolated to the Windows Server 2025 SKU following the December patch, this aligns with a deployment manifest error where the default desktop configuration (where AppXSVC is often more active) may have been inadvertently applied to the Server image. I recommend applying the workaround above to silence your Zabbix alerts and filing a report via the Feedback Hub or your support channel to ensure the product team addresses the registry configuration in the next servicing stack update.

    I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

    VP

    0 comments
  2. Thomas Jedelhauser 0 Reputation points
    2025-12-13T17:12:26.6733333+00:00

    Hi @VPHAN

    Thank you for confirming the expected behavior.

    However, I must point out that the proposed solution, running sc config AppXSVC start= demand, fails on our system.

    As reported, the command, even when executed in an elevated (Administrator) prompt, returns:

    "Error 5: Access is denied"

    This confirms that the patch has not only set the value to 'Automatic' but is also actively blocking any administrative attempt to change the service configuration.

    TJ

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.