I had the "cannot update" error in the Creative Cloud desktop app for over a year. I tried everything I could find: full uninstall and reinstall several times, the Creative Cloud Cleaner Tool, Adobe support, and a long list of fixes from other forum posts and Windows troubleshooting guides. None of it worked, so eventually I gave up and just lived with it.

I finally found the real cause by accident, while debugging a completely unrelated problem on my PC. It has nothing to do with Adobe's installer or your account — it is a Windows setting. The fix takes one minute.

Posting it in case someone else is stuck on the same thing.

Short version: if Windows is set to install new apps to a drive other than C:, the AdobeNotificationClient package cannot finish installing, and Creative Cloud fails to update. It also causes a memory leak in Windows that gets worse every day your PC stays on.

Note for moderators / Community Experts: I believe this is a bug in how the Adobe notification package handles a non-system install volume. The package requests all-users provisioning, which Windows does not allow on a non-system drive, and neither the install nor the cleanup after the failure is handled — so it retries forever. I would appreciate it if this could be passed on to the right team. Details and event log IDs are below.

Symptoms

• Creative Cloud desktop says it cannot update, with no useful reason given
• Uninstall and reinstall does not fix it
• Over several days of uptime, the PC gets slower, and other programs start failing with "out of memory" errors even though Task Manager shows plenty of free RAM
• Restarting Windows fixes the slowness for a few days, then it comes back

Cause

Windows has a setting for which drive new apps install to. Mine was set to E:. The Adobe notification package needs to be installed for all users, and Windows does not allow that on any drive except the system drive (usually C:). So the install fails, Windows tries to clean up, the cleanup also fails, and it retries forever.

Every retry leaves memory behind that is never released. On my PC this was about 38 GB per day of committed memory, held by the Windows service AppXSvc. After 4 days it had eaten 143 GB and my system was at 91% of its memory commit limit, which is when other programs start failing.

The two errors in the Windows event log are:

• 0x80070032 — Windows can't provision the package because it is not installed on a system volume
• 0x80070490 — the cleanup after that failure also fails

How to check if you have this

Open Settings > System > Storage > Advanced storage settings > Where new content is saved. Look at "New apps will save to". If it is not C:, you may have this problem.

To confirm, open PowerShell as Administrator and run:

Get-AppxPackage -AllUsers *AdobeNotification* | Select-Object Name,InstallLocation | Format-List

If InstallLocation is not on C:, that is the problem.

To see the memory leak, run this and check the number. Mine was 0.04 GB right after a restart and 143 GB after 4 days:

Get-Process -Id (Get-CimInstance Win32_Service -Filter "Name='AppXSvc'").ProcessId | Select-Object @{n='Priv_GB';e={[math]::Round($_.PrivateMemorySize64/1GB,2)}}

You can also look at the deployment log directly:

Get-WinEvent -LogName 'Microsoft-Windows-AppXDeploymentServer/Operational' -MaxEvents 40 | Where-Object {$_.LevelDisplayName -eq 'Error'} | Select-Object TimeCreated,Id,Message | Format-List

The fix

Step 1. Settings > System > Storage > Advanced storage settings > Where new content is saved. Set "New apps will save to" back to C:.

This only affects apps installed from now on. Nothing already installed on your other drive is moved or broken.

Step 2. Close Creative Cloud completely. Quit it from the system tray, then in PowerShell as Administrator:

Stop-Service AdobeUpdateService -Force -ErrorAction SilentlyContinue
Get-Process | Where-Object {$_.Name -like '*Creative*' -or $_.Name -like '*Adobe*'} | Stop-Process -Force

Step 3. Remove the broken package:

Get-AppxPackage -AllUsers *AdobeNotification* | Remove-AppxPackage -AllUsers

Step 4. Start Creative Cloud again.

In my case the update went through immediately, the first time in over a year. The package reinstalled itself to C:, with no errors in the event log, and AppXSvc stayed at 0.04 GB instead of climbing.

Note: AdobeNotificationClient is only the notification component. Lightroom Classic, Photoshop and the Creative Cloud desktop app are normal Windows programs, not Store packages, so removing it does not touch them.

Why the memory leak is worse now than it used to be

AppXSvc used to shut down when it had nothing to do, which released the leaked memory. A Windows 11 update (KB5072033, December 2025) changed it to run all the time. So the same failing retry loop that was harmless before now accumulates for as long as your PC stays on.

I am only describing what I found on my own PC. I did not test this on other machines, so I cannot say it applies to everyone with a non-C: app drive — but if your symptoms match, it is worth checking.

My system

• Windows 11 Pro, build 10.0.26200.9168
• Creative Cloud desktop app, AdobeNotificationClient 7.0.2.14
• 64 GB RAM
• "New apps will save to" was set to a secondary internal NTFS drive (E:)

Extra note for anyone running local AI models in WSL2

This one is niche, but it cost me a lot of time and the error message points in completely the wrong direction.

The above memory leak made llama-server (via Ollama, inside WSL2) fail with:

cudaMalloc failed: out of memory
alloc_tensor_range: failed to allocate CUDA0 buffer of size 12653917568

This looked like a VRAM problem. It was not. I had 22.7 GiB of VRAM free at the time, on a 24 GB card.

Under WDDM, every GPU allocation also needs Windows commit memory to back it. Windows was at 91% of its commit limit because of the leak, so it refused the 12 GiB allocation. CUDA inside WSL2 only sees the refusal and reports it as a generic out-of-memory error.

The real evidence is on the Linux side, in dmesg:

misc dxg: dxgk: dxgvmb_send_create_allocation: send_create_allocation failed ffffffb5
misc dxg: dxgk: dxgkio_create_allocation: Ioctl failed: -75

dxgvmb_send is the WSL guest asking the Windows host for the allocation. ffffffb5 is -75, EOVERFLOW — the host refused. At the exact same second, the Windows System event log recorded Resource-Exhaustion-Detector event 2004 (low virtual memory).

So: if you get a CUDA out-of-memory error inside WSL2 but nvidia-smi shows plenty of free VRAM, check Windows commit charge before you touch anything in your model setup. In PowerShell as Administrator:

Get-Counter '\Memory\Committed Bytes','\Memory\Commit Limit'

If committed is close to the limit, the problem is on the Windows side, not in your GPU, your model, or your context size.