WindowsAppRuntime 1.4 Failures in AVD Multi-Session – Event ID 404 Production Case
We recently experienced a production issue in an Azure Virtual Desktop multi-session environment that initially looked random — but turned out to be a shared framework instability amplified by scale. Environment: AVD multi-session host pools FSLogix profile containers MSIX App Attach Intune-managed Clean golden image Everything looked healthy. Yet packaged applications started failing across multiple host pools. Symptoms observed Users reported: Error 0x80070005 AppXDeploymentServer Event ID 404 WindowsAppRuntime 1.4 marked as NeedsRemediation Failures persisted after: Reboots Host redeployments Image rebuild This was not: A profile corruption issue An App Attach packaging issue An Intune deployment failure What actually broke Under session churn conditions (logoff / new session / runtime re-validation), WindowsAppRuntime 1.4 entered a NeedsRemediation state. Event Viewer showed: AppXDeploymentServer Event ID 404 HRESULT 0x80070005 Runtime file creation failure under WindowsApps Multi-session did not cause the issue. It amplified it. Shared framework registration timing under concurrent sessions made a rare condition systemic. Why multi-session exposed it In single-session environments, runtime inconsistencies remain isolated. In multi-session: Shared framework dependencies are reused Concurrent validation occurs Host pools recycle under load Registration timing becomes critical What would be a rare edge case became recurring instability. Remediation approach Instead of periodic polling, we moved to event-driven self-healing. Detection trigger: AppXDeploymentServer Event ID 404 Remediation logic: Restart AppXSVC Re-provision WindowsAppRuntime 1.4 Prevent concurrent duplicate execution Log execution We implemented a Scheduled Task: Monitoring Operational log Triggering immediately on Event ID 404 Running under SYSTEM Deployed via Intune Win32 package Detection logic validating task presence This converted reactive troubleshooting into automated correction across host pools. Architectural takeaway Multi-session environments amplify shared dependency weaknesses. WindowsAppRuntime is not “just another component” — it is a platform dependency. If the runtime layer drifts, everything layered above it collapses: MSIX App Attach Packaged apps Registration consistency Self-healing must be part of AVD design. For the structured technical case study (including deployment pattern and remediation logic), full write-up here: https://modernendpoint.tech/avd-multi-session-failure-analysis/ Has anyone else observed WindowsAppRuntime 1.4 entering a NeedsRemediation state under multi-session load? Curious if others saw correlation with specific Windows updates. — Menahem Suissa Modern Endpoint Architect
Error on .appv file expand for App Attach
Hi, I try to create an App Attach package from App-V package. On expand step I get an error in some cases: The gateway did not receive a response from 'Microsoft.DesktopVirtualization' within the specified time period. Status: 504 (Gateway Timeout) ErrorCode: GatewayTimeout I noticed that expanding file of small size works corectly, i.e. .appv files of Notepad++ and Greenshotapp is 11 and 13 Mb. However, expanding file of larger size fails with that error after some time, i.e. .appv file of VLCMediaPlayer++ is 200 Mb, JGraphDrawIO is 400 Mb, Image Glass is 111 Mb. Expanding VHDX files of large sizes from same file share and with same host pool works correctly. The problem is only with .appv.
MSIX app attach issues
We are experiencing several issues with WVD MSIX App Attach. Locally the MSIX packages work fine but when they are started via Remote App (App Attach) the problems starts. For some users the applications work well, for some users the explorer opens, some get an AiStub error and by some just nothing happens. So it is very variable. If we then offer these applications as APP-V, the applications work well. The solution for the AiStub error is to use PsfTooling, we did this but it is still strange that it works for some users. What is your experience with MSIX App attach? Do you also encounter these problems? What can we do about it? Or what is the best troubleshooting? Thank you very much for your comments. Bert
