May 12 2026 Windows update taking very long time

I'm installing the May 12, 2026 Windows update, which is a large cumulative update. The update has now been running for about 10 hours. Is anyone else seeing unusually long install times for this update?

Setup:
• Windows 11 Pro ARM
• Parallels Desktop 26.3.1 (57396)
• macOS Tahoe 26.4.1 on Mac mini M2 Pro

The update started with visible Windows update messages, but during the current phase the Windows screen is completely blank. This phase is likely the "Windows Update: Servicing Phase 2 -- Offline Servicing," which uses a minimal boot graphics driver that Parallels does not display, so the screen stays black for this stage.

Activity Monitor shows the VM is still working and not frozen:
• ~102% CPU
• CPU time increasing at wallclock rate
• Context switches ~321/sec
• Mach syscalls ~127/sec
• Unix syscalls ~366/sec

One more observation: the Parallels "Windows 11" process shows very large Virtual Memory usage (currently ~7.5 TB). This is normal on macOS. Virtual Memory grows continuously during long-running operations because macOS keeps reserving new address space for Parallels' memory‑mapped regions and never releases it until the Parallels process exits. It does *not* indicate a memory leak, and Real/Private memory remain small and stable.

 

Follow‑up update
Below is a summary of what happened, what Parallels Support advised, and what I plan to do for future Windows updates. Hopefully this helps anyone else who encounters similar behavior.

What happened
Parallels Support reviewed the logs I sent and confirmed that the VM had entered an unstable virtual‑hardware state during the Windows 11 cumulative update. The logs showed a combination of:

• multiple macOS host sleep/wake cycles while the update was running
• snapshot deletion/creation activity
• virtual device pause/resume sequences
• storage controller resets
• and eventually a hypervisor‑level VM restart

According to Support, this sequence disrupted the VM's virtual hardware state during Windows servicing, which led to the guest‑visible symptoms I was seeing (RTC/timer drift, storage resets, TPM errors, and the servicing stall).

What fixed it
Support recommended using Actions → Restart on the VM. That immediately restored normal operation, and the Windows update completed successfully on the next boot.

Recommendations before updating
I run SmartGuard with Take a Snapshot Every: 24 hours and Snapshots to Keep: 17, which ensures I always have a chain of restore points in case something goes wrong during a Windows update.

Since snapshot operations were part of the sequence of events that contributed to the VM becoming unstable, I also recommend enabling SmartGuard → Notify me before snap creation. This provides a 60‑second countdown before a SmartGuard snapshot is created, giving you the option to click "Skip" -- and you should click it during a Windows update, because that is the point where an automatic snapshot could destabilize the servicing process.

What I plan to do for future Windows updates
To avoid timing‑related issues during large Windows updates, the following process can help maintain VM stability:

1. Shut down Windows completely (not suspend).
2. Update Parallels Desktop, if an update is available.
3. Launch Windows.
4. Immediately take a snapshot via Actions → Take Snapshot... to create a restore point as close as possible to the update moment. Having a snapshot is critically important, because resetting a stalled Windows update can result in corruption beyond what Windows' repair environment can recover.
5. Run Check for Updates inside Windows.
6. If updates are available, prevent macOS from sleeping during the update by running caffeinate -dimsu -t 86400 in the Mac's Terminal app. This keeps the Mac awake by preventing display sleep (-d), idle sleep (-i), disk sleep (-m), and system sleep on AC power (-s), while also asserting continuous user activity (-u) so macOS treats the system as actively in use. The optional -t 86400 argument limits caffeinate to 24 hours in case it is left running unintentionally. Just to be clear, caffeinate does not affect snapshot logic; it simply prevents macOS from sleeping, which avoids VM pause/resume cycles -- a factor that contributed to the instability described earlier.
7. Wait for Windows Update to complete. A black screen can be normal during parts of the servicing process. However, if the screen remains black for a long time (for example, six hours or more) with no sign of progress, it is reasonable to use Actions → Reset to reinitialize the virtual hardware and allow Windows to continue.
8. When the updates are finished, close the Terminal window to terminate caffeinate.

Feature request: "Pause Snapshots..."
One improvement that would be very helpful for long, unattended operations (like cumulative updates) would be a "Pause Snapshots... >" command in the Parallels UI. It could be added to the existing snapshot‑related group of items in the Actions menu. Selecting it would open a submenu of time periods (for example: 1 hour, 3 hours, 6 hours, until next VM shutdown). After choosing a duration, the main menu item would change to Resume Snapshots, consistent with Apple's Human Interface Guidelines for state‑dependent menu items.

This would allow users to temporarily suspend SmartGuard snapshot creation for the current VM, without disabling SmartGuard entirely or worrying about what happens to existing snapshots.

Thanks.