Microsoft 365 Apps executable files disappear after reboot on Windows 11 (Click‑to‑Run)

Question

Problem summary

I am experiencing a persistent issue with Microsoft 365 Apps for enterprise (Click‑to‑Run) on a local Windows 11 laptop.

Microsoft 365 installs successfully and works immediately after installation. However, after restarting the system, the Office application executable files disappear. Without any user action, the executables later reappear on their own, and Office starts working again.

This cycle repeats on every reboot.

---

Environment

• Windows 11 (local laptop, not VDI or RDS)
• Microsoft 365 Apps for enterprise
• Installation type: Click‑to‑Run
• Device is enterprise‑managed
• Local administrator credentials available

---

Observed behavior

• After reboot, Office applications cannot be launched
• File associations for .docx, .xlsx, .pptx break
• The Office installation directory is temporarily missing executables

Example directory: C:\Program Files\Microsoft Office\root\Office16

Files such as WINWORD.EXE, EXCEL.EXE, and POWERPNT.EXE are not present immediately after reboot.

After an unknown amount of time (minutes to longer), the executables reappear automatically without any user interaction, and Office functions normally again until the next restart.

This does not appear to be a true uninstall.

---

What has already been tried

1. Full uninstall of Microsoft 365 Apps
2. Manual cleanup of all remaining Office and Click‑to‑Run folders, including:
   • Program Files Microsoft Office
     • Program Files (x86) Microsoft Office
       • Microsoft Shared ClickToRun
         • ProgramData Microsoft Office
         1. Reboot
         2. Reinstall from the Microsoft 365 Apps portal (m365.cloud.microsoft/apps)
         3. Verified Office works immediately after installation
         4. Reboot reproduces the issue consistently

Additional notes:

• Microsoft Support and Recovery Assistant (SaRA) command‑line tool reports as expired
• The Windows Get Help app fails with a 504 Azure Front Door timeout when attempting Office cleanup

---

Assessment

This behavior suggests a background Click‑to‑Run update, repair, or policy‑driven redeploy that temporarily removes Office binaries and later re‑hydrates them.

The timing is non‑deterministic, and the issue only manifests after system restart.

---

Questions

1. What Click‑to‑Run mechanisms could cause Office executables to be removed and later restored after reboot?
2. Are there known issues where background repair, update channel enforcement, or redeploy policies trigger this behavior?
3. What diagnostics (logs, registry keys, services, or scheduled tasks) can confirm why the Office16 executables are being removed?
4. Is there a Microsoft‑supported way to prevent Click‑to‑Run from deregistering or redeploying Office after restart?

Any guidance on where to focus troubleshooting would be appreciated

Answer 1

I came across this while searching for the exact same behavior across a couple different client sites. Searching Windows logs shows that the behavior was coming from Office Store Hub scheduled task crashing out overnight. It came installed on these PCs and the behavior stopped for us after running these Powershell scripts:

Checking if it's installed:

Get-AppxPackage -Name "Microsoft.MicrosoftOfficeHub" -AllUsers

If found remove with:

Remove for current user

Get-AppxPackage "Microsoft.MicrosoftOfficeHub" | Remove-AppxPackage

Remove for ALL users (run as admin)

Get-AppxPackage -AllUsers "Microsoft.MicrosoftOfficeHub" | Remove-AppxPackage -AllUsers

Also remove the provisioned package so it doesn't reinstall on new profiles

Get-AppxProvisionedPackage -Online |

Where-Object DisplayName -eq "Microsoft.MicrosoftOfficeHub" |

Remove-AppxProvisionedPackage -Online

Not sure if it's the same for you, but thought I would post it just in case someone else runs across this strange behavior with the EXE's getting deleted

Answer 2

Dear Kumar Dwarakanath,

Thank you for sharing this detailed situation with the community. 

From your description, it appears that you are experiencing a persistent cycle where Microsoft 365 Apps for enterprise installs correctly but the executables (WINWORD.EXE, etc.) disappear immediately following a system restart. After a short period, the files automatically reappear without user intervention, and this cycle repeats consistently on every reboot.

I have reviewed the technical patterns associated with the Click-to-Run (C2R) service and enterprise management, and I have outlined the answers to your specific questions below:

This behavior is often tied to the Virtual File System (VFS) and Streaming nature of Click-to-Run. If the OfficeClickToRun.exe service identifies an "Incorrect State" during boot (such as a version mismatch), it may temporarily de-register the root binaries. The subsequent "restoration" is a self-healing mechanism where the service copies the files back from the local staging area (C:\Program Files\Common Files\microsoft shared\ClickToRun\Staging) once the service stabilizes.

You can learn more at: Overview of the update process for Microsoft 365 Apps - Microsoft 365 Apps | Microsoft Learn 

In enterprise-managed environments, "Desired State" enforcement is a common trigger. If a policy (via Intune or GPO) is enforcing a specific TargetVersion or UpdateChannel that differs from your manual portal installation, the C2R engine will attempt to "realign" the installation on every reboot, resulting in this removal/restoration loop.

Visit this article for more information: Configuration options for the Office Deployment Tool - Microsoft 365 Apps | Microsoft Learn

To verify, you may want to focus on these diagnostic areas:

Registry Key

• Press Windows Key + R, type regedit, and press Enter, then click Yes.
• In the address bar at the top, paste the following path and press Enter: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration
• Look for the following specific String Values (REG_SZ) in the right-hand pane: TargetVersion: If this has a value (e.g., 16.0.12345.67890), the service will delete any other version to match this one. UpdateChannel: This shows which "stream" your Office is on (e.g., MonthlyEnterprise, Current). UpdatePath: If this points to a local network folder, your IT department is controlling the source of the files.
• If they exist, it is a strong indicator that an enterprise policy is managing your installation.

For example, the screenshot below is from my test environment, which is not enterprise-managed.

Analyzing Click-to-Run (C2R) Logs

• Open File Explorer and navigate to C:\Windows\Temp. Click Continue to give it permission.
• Look for files that follow this naming convention: [YourComputerName]-[Date]-[Time].log. Note: Focus on logs generated at the exact time you rebooted the computer.
• Right-click the log file and select Open with > Notepad.
• Press Ctrl + F to open the search box and search for these specific terms: "DeleteVersion": This confirms the service intentionally removed a version of Office. "Egress": This shows the service is "streaming" or moving files from the staging area back to the main folder. "IntegrityCheck": This will show if the service found "corruption" or "non-compliance" that triggered a repair.
• If you find these terms, look at the lines immediately above them to see the reason (e.g., "Version mismatch detected").

Reviewing Scheduled Tasks

• Click the Start menu, look for Task Scheduler, and open it.

• In the left sidebar, navigate through the folders: Task Scheduler Library > Microsoft > Office.
• In the middle pane, locate the task named Office Automatic Updates 2.0. Look at the Triggers tab: Check if it is set to run "At log on of any user" or "At startup." Look at the Last Run Result column: A result of 0x0 means it ran successfully.
• If the "Last Run Time" matches the moment your files disappeared, this task is likely the trigger for the removal.

Summary of Findings

• If Registry Keys show a specific TargetVersion, your IT policy is likely forcing a change.
• If C2R Logs contain DeleteVersion, the service is intentionally clearing the folder.
• If Scheduled Tasks ran at the exact time of the reboot, the update engine is the active trigger.

For a more accurate investigation and more direct help, I recommend contacting the IT team within your current organization. They can assist in raising a support request ticket with Microsoft. This will enable the Microsoft support team to conduct a more in-depth investigation and provide guidance tailored to your specific environment.

The Global Admin can create a support ticket by sign in to the Microsoft 365 Admin Center > Support > Help & Support.  

For detailed instructions on how to get support, please refer to Get support - Microsoft 365 admin.     

Note: If you’re an end-user, please coordinate with your Office 365 Global Administrator to handle these steps.

Please note that this is a user-to-user support forum. My role is limited to providing general guidance, and I do not have access to internal systems or the ability to review account-level configurations. For this reason, engaging your organization’s IT team to escalate the issue is the most appropriate next step.

I hope this information is helpful. If you need any further assistance, please feel free to reach out.
Thank you very much for your understanding and cooperation.

---

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment". 

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread. 

Answer 3

Click-to-Run uses a virtualized and streamed application model, and the Office binaries under C:\Program Files\Microsoft Office\root\Office16 are managed by the Click-to-Run service rather than behaving like a traditional MSI install. Programs delivered via Click-to-Run execute in a virtual application environment and support streaming, so components can be added, updated, or repaired in the background while the apps are in use or after restart.

From the available information, the following points apply:

1. Mechanisms that can remove and later restore executables
   • Click-to-Run maintains a virtualized application environment and streams Office components as needed. While running, the rest of the programs are downloaded in the background, and the service can update or repair files in that virtualized/streamed layout.
   • Because Click-to-Run owns the application files, background update or repair operations can temporarily remove or replace binaries while it rehydrates the Office installation.
2. Known interaction issues with virtualization
   • On devices that also use App-V, Office Click-to-Run and App-V both use virtualization technologies. If they are not coordinated, issues can occur where Office components or integrations do not behave correctly. Microsoft provides a registry override (AllowJitvInAppvVirtualizedProcess) so the Click-to-Run virtualization system can recognize App-V virtualization and work correctly together.
   • If this device is using App-V or similar virtualization in addition to Click-to-Run, that interaction should be checked. The documented fix is to create the following registry value and restart the device:
     • Subkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClickToRun\OverRide
     • Name: AllowJitvInAppvVirtualizedProcess
     • Type: REG_DWORD
     • Value: 1
3. Diagnostics to focus on
   • Because Click-to-Run manages the Office binaries via its own virtualization and streaming engine, diagnostics should focus on:
     • The Click-to-Run service and its update/repair behavior.
     • Any additional virtualization layer such as App-V that might be applied to Office or to the user environment.
   • For broader app-start and policy-related issues on managed devices, Process Monitor and Group Policy analysis are recommended:
     • Use Process Monitor to trace what happens to the Office folder and executables during and after restart, and when they reappear.
     • Compare behavior with a test machine in an OU without policies, then add policies one by one until the behavior reproduces, to identify a policy that might be triggering a repair, masking, or removal.
     • If Group Policy is suspected and many GPOs are applied, local Group Policy can be reset (as a test) to default values using the documented RD and gpupdate /force commands, then rebooting, to see if the behavior changes.
4. Ways to prevent repeated deregistration/redeployment
   • The supported approach is to ensure that the virtualization and policy environment allows Click-to-Run to manage Office normally:
     • If App-V is in use, configure the AllowJitvInAppvVirtualizedProcess registry value so Click-to-Run and App-V cooperate.
     • If policies or masking tools (such as application masking or rules that hide executables) are in use, remove or adjust any rules that hide or interfere with Office executables, then reinstall Office.
     • If Group Policy is causing incorrect permissions or repeated resets, identify and correct the specific GPO rather than relying on manual file cleanup, because policy reapplication can undo manual fixes.

These mechanisms and mitigations are the documented, Microsoft-supported ways to control how Click-to-Run manages Office binaries and how it interacts with other virtualization and policy layers on managed Windows 11 devices.

---

References:

• Office 2010 Click-to-Run: Introduction
• Resolve issues when using Microsoft 365 Apps on App-V enabled devices
• Modern, Inbox, and Microsoft Store Apps troubleshooting guidance