The App That Needed Creative Cloud Was Creative Cloud

Sixty-seven minutes, by the clock

These are my notes as I took them, tidied for spelling. The machine is on a 2.5 Gb fiber connection, so none of the waiting below is bandwidth. Times are afternoon.

2:00 — Removed Acrobat. It wanted a reboot. I didn’t; too much running.
2:02 — Tried to remove Photoshop. Creative Cloud forced a login first, then forced an update of itself.
2:12 — Logged in. Started removing Lightroom Classic. Creative Cloud began another update.
2:16 — Lightroom is 40% through updating. I am trying to remove it.
2:17 — Noticed I am using 461.3 KB of 20 GB of cloud storage. Adobe asks whether I want to upgrade my storage.
2:19 — Lightroom Classic still updating. The Creative Cloud update is still at 0%.
2:22 — Camera Raw is now updating. 50%.
2:24 — Photoshop at 2%. “Lightroom waiting…”
2:25 — Camera Raw is off the list.
2:28 — Photoshop at 25%, updating.
2:32 — 50%, then a jump straight to done. Uninstalling Lightroom was very fast after that, and so was the Creative Cloud update.
2:35 — Tried to uninstall Creative Cloud itself (799 MB). Windows can’t find the uninstaller. The app now says Lightroom Classic 4.35 is still installed.
2:39 — Uninstalled Photoshop. Done in under a minute.
2:40 — Uninstalled Adobe Genuine Service.
2:42 — Signed out of Creative Cloud.
2:44 — Ran the uninstaller from its folder. It says I still have apps that require it, but not which ones. All I have left is the free Acrobat Reader and Adobe AIR, which the Pandora desktop app needs.
2:47 — Removed Reader.
2:50 — Still refuses. Rebooting.
2:56 — Still can’t uninstall.
2:59 — Copied the uninstaller into the folder Windows was looking in. Now it is found, and it still says other apps need it.
3:01 — Removed Adobe AIR. Still can’t uninstall Creative Cloud.
3:05 — Confirmed in the app that no Creative Cloud apps are installed. Tried the uninstaller’s Repair option. Nope. Still won’t uninstall.
3:07 — Let’s ask Fable 5.1.

Three things in that list deserve a second look before the technical part. Removing an app required signing in. Removing an app triggered updates of the app being removed and of the apps next to it, and the uninstall could not start until the updates finished. And the one error that mattered named no app, so every remaining Adobe product on the machine became a suspect, including a PDF reader and a runtime for a music player.

What the uninstaller was actually checking

From 3:07 I handed the investigation to Claude, Anthropic’s Fable 5.1, with one rule: read-only until we knew what we were looking at. The uninstaller keeps a log at %TEMP%\CreativeCloud\ACC\ACC.log, UTF-16, and the refusal is in it, one line, with nothing before or after it to say what tripped:

15:07:12:018 | ACC-Uninstaller | Uninstall workflow initiated
15:07:12:018 | ACC-Uninstaller | Loading AdobePIM.dylib from: ...\Adobe Desktop Common\Core\AdobePIM.dll
15:07:12:949 | ACC-Uninstaller | Could not uninstall Creative Cloud Desktop application
                                 as there are other Adobe apps installed on machine that require it!

Nine hundred milliseconds of silence, then a verdict. So the next question was where the verdict comes from. Adobe’s installer keeps its inventory in a SQLite database, hdpim.db, under Common Files\Adobe\caps. After every app was removed it held exactly five products, and all five are Creative Cloud’s own plumbing:

Code	Name	Visible	Auto-install	Self-referenced
KASU	HD_ASU	no	no	yes
LIBS	CC Library	no	yes	yes
CCXP	CCX Process	no	yes	yes
COSY	CoreSync	no	yes	yes
KANC	Adobe Native Client	no	yes	no

The uninstaller does not log its reasoning, but its binary carries the strings that describe it. The check walks the installed products and tolerates two kinds:

Inside CanUninstallThor | AutoInstall product is installed on machine. Sap Code %s ...
Inside CanUninstallThor | SelfReference product is installed on machine. Sap Code %s ...
Inside CanUninstallThor | UWP product is installed on machine. Sap Code %s ...
Inside CanUninstallThor | No FFC products installed.

It also reads Adobe’s full product catalog, a 15 MB XML cached under ProgramData\Adobe\OOBE, and asks a second library whether each catalog entry is present. For products that are not installed through Adobe’s own installer, Acrobat among them, “present” means the entry’s package code exists in the Windows uninstall registry. We checked all 855 package codes in the catalog against the registry. None was there. Acrobat had left plenty behind, a registry key flagged “reboot required,” an updater MSI with its own service and scheduled task, two Microsoft Store packages registered to my user, and startup entries pointing at files that no longer existed, but none of it was what the check reads.

That left the one row in the table that is not self-referenced.

The app that needed Creative Cloud

Adobe Native Client is a Store-style MSIX package, AdobeNotificationClient, plus an Explorer shell extension. It provides Windows notifications for the Adobe apps. Creative Cloud installs it automatically, marks it invisible, and gives you no button anywhere to remove it. It is bookkept the way a real application is: apps such as Photoshop register a reference to it, and the installer is supposed to remove it when the last reference goes. On this machine the reference table was empty and the component was still installed. The uninstaller, walking its list, found a product that is not self-referenced and reported an app that needs Creative Cloud.

Two details make it worse than a stale row. First, the installer log shows Creative Cloud upgrading Native Client from 7.0.2 to 7.0.7 at 2:33 that afternoon, during the forced update in my timeline, while I was trying to remove everything. Second, the uninstaller’s Repair option re-runs the component installs, so the one recovery path the dialog offers reinstalls the thing that blocks it.

Adobe’s own cleanup tool confirmed the classification without being asked. Its listing mode logs each product it finds with a family number. The four helpers are family 0, Creative Cloud’s own. Native Client is family 1, an application:

Following product added for HD cleanup: [HD_ASU] prodFamily: 0
Following product added for HD cleanup: [CC Library] prodFamily: 0
Following product added for HD cleanup: [CCX Process] prodFamily: 0
Following product added for HD cleanup: [CoreSync] prodFamily: 0
Following product added for HD cleanup: [Adobe Native Client] prodFamily: 1

So the answer to “which app?” was: a component the user cannot see, cannot uninstall, and did not install. Creative Cloud needed Creative Cloud.

Adobe’s way around Adobe’s check

Adobe’s documented remedy for this exact error is a separate download, the Creative Cloud Cleaner Tool. It does not run the dependency check at all. It removes whatever is on its list. The check that stopped the uninstaller is, in other words, a policy with a sanctioned bypass, not a safeguard.

The tool’s manifest demands administrator rights even to list what it would remove, so every step is a UAC prompt. The interactive mode wants a language letter, a license acceptance, and a numbered menu. The quieter path is the enterprise one: a listing run writes an XML with every entry commented out, you uncomment what you want gone, and a second run removes it.

AdobeCreativeCloudCleanerTool.exe --createCleanup=C:\path\to\folder
AdobeCreativeCloudCleanerTool.exe --cleanupXML=C:\path\to\folder\cleanup-run.xml

The listing it produced is the whole of what Adobe believed was installed. Note what is not in it: no Photoshop, no Lightroom, no Acrobat. Everything on the list is Creative Cloud or a piece of it.

<Products>
  <Properties>
    <Property name="eulaAccepted">1</Property>
  </Properties>
  <CreativeCloud>
    <Product productName="Adobe Creative Cloud" version="2.0"/>
    <Product productName="HD_ASU (32 Bit)" version="2.0"/>
    <Product productName="CC Library (32 Bit)" version="4.19.2"/>
    <Product productName="CCX Process (32 Bit)" version="7.14.0"/>
    <Product productName="CoreSync (32 Bit)" version="7.10.0"/>
    <Product productName="Adobe Native Client" version="7.0.7"/>
  </CreativeCloud>
  <AdobeIdCredentials>
    <Product productName="Adobe Id Credentials" version="1.0"/>
  </AdobeIdCredentials>
</Products>

The removal run took thirty-nine seconds. The tail of its log is the part that matters: it removes the Store package for all users, deletes the shell-extension folder, drops the inventory row, and exits 0. That is the whole fix for an hour of refusals.

Removing UWP package AdobeNotificationClient for all users
Recursively deleting folder: C:\Program Files\Common Files\Adobe\Adobe OS Extension
Successfully deleted: C:\Program Files\Common Files\Adobe\Adobe OS Extension
Removing HD productID : KANC
Removed HD productID : KANC
Finish : HD Product deleted : KANC
:: End :: [CreativeCloud] Removing Product: {'guid': 'KANC', 'version': '7.0.7', 'name': 'Adobe Native Client'}
::Start:: [AdobeIdCredentials] Removing Product: {'guid': None, 'version': '1.0', 'name': 'Adobe Id Credentials'}
Removed NGL Credentials Successfully.
Exit Code: 0

What “uninstalled” left behind

With Creative Cloud gone and Adobe’s own cleaner run, I enumerated the machine rather than trust any app’s view of it. The machine-level remains came to roughly 890 MB and a set of registrations pointing at nothing:

Two blank entries in Apps & Features whose uninstaller executable had been deleted.
A service, AdobeUpdateService, whose executable had been deleted.
A scheduled task to launch a process that no longer existed.
A startup entry for the 2016-era Adobe Application Manager updater, still on disk.
Acrobat’s updater MSI, Adobe Refresh Manager, with its service and scheduled task, from an Acrobat that was uninstalled an hour earlier.
Two Acrobat Store packages still registered to my user.
Two startup entries for Acrobat and Reader synchronizers, pointing at deleted files.
515 MB under the 32-bit Common Files, 318 MB under the 64-bit one, including Camera Raw 8 “coexistence” databases from 2013 and an Acrobat Pro 2019 uninstall stub.
54 MB of installer temp files in a folder at the root of C:.

Per-user, another 3.6 GB: 1.17 GB of plugin storage, 923 MB of in-app tutorial assets, 407 MB of welcome-screen content, 330 MB of “GrowthSDK,” and about 570 MB of Acrobat and embedded-browser caches, alongside the preferences that a reinstall would actually want. In total, about 4.5 GB after every Adobe product had been uninstalled through Adobe’s own uninstallers and then Adobe’s own cleaner.

The sweep was a PowerShell script that printed its plan, waited for a typed YES, exported every registry hive to a .reg file before deleting it, uninstalled the MSI through msiexec rather than deleting its files, and asked separately before touching anything in my profile. It never touched Documents\Adobe or the Lightroom folder that holds local originals. Its output, with the user path generalised:

== 1. Services
  stopped AdobeUpdateService
  stopped AdobeARMservice
  deleted service AdobeUpdateService (its EXE was already gone)

== 2. Adobe Refresh Manager (MSI)
  msiexec exit code 0   (0 = removed, 3010 = removed and reboot pending, 1605 = was not installed)

== 3. Scheduled tasks
  removed task 'Launch Adobe CCXProcess'
  (already gone) task 'Adobe Acrobat Update Task'

== 4. Startup entries
  removed 'AdobeAAMUpdater-1.0'
  removed 'Adobe Reader Synchronizer'
  removed 'Adobe Acrobat Synchronizer'

== 5. Dead uninstall entries
  removed HKLM:\SOFTWARE\WOW6432Node\...\Uninstall\KANC_7_0_7
  removed HKLM:\SOFTWARE\WOW6432Node\...\Uninstall\KASU_2_0_32

== 6. Orphaned Acrobat Store packages
  removing AdobeAcrobatDCCoreApp_26.1.0.0_x64__pc75e8sa7ep4e (current user)
  removing AdobeAcrobatDCCoreApp_26.1.0.0_x64__pc75e8sa7ep4e (all users)
  removing AdobeAcrobatReaderCoreApp_23.0.0.0_x64__pc75e8sa7ep4e (current user)

== 7. Machine-level Adobe registry hives (exported first)
  exported HKLM\SOFTWARE\Adobe -> HKLM-SOFTWARE-Adobe.reg
  deleted HKLM\SOFTWARE\Adobe
  exported HKLM\SOFTWARE\WOW6432Node\Adobe -> HKLM-SOFTWARE-WOW6432Node-Adobe.reg
  deleted HKLM\SOFTWARE\WOW6432Node\Adobe
  exported HKLM\SOFTWARE\Policies\Adobe -> HKLM-SOFTWARE-Policies-Adobe.reg
  deleted HKLM\SOFTWARE\Policies\Adobe
  (absent) HKLM:\SOFTWARE\WOW6432Node\Policies\Adobe
  exported HKCU\SOFTWARE\Policies\Adobe -> HKCU-SOFTWARE-Policies-Adobe.reg
  deleted HKCU\SOFTWARE\Policies\Adobe
  exported HKCU\SOFTWARE\Classes\CLSID\{e8c77137-...} -> HKCU-SOFTWARE-Classes-CLSID-{e8c77137-...}.reg
  deleted HKCU\SOFTWARE\Classes\CLSID\{e8c77137-...}

== 8. Machine-level Adobe folders
  deleted C:\Program Files (x86)\Common Files\Adobe
  deleted C:\Program Files\Common Files\Adobe
  deleted C:\ProgramData\Adobe
  deleted C:\Program Files\Adobe
  deleted C:\Program Files (x86)\Adobe
  deleted C:\adobeTemp

== 9. Per-user Adobe settings and caches (optional)
  Remove per-user Adobe settings and caches too? [y/N]: y
  exported HKCU\SOFTWARE\Adobe -> HKCU-SOFTWARE-Adobe.reg
  deleted HKCU\SOFTWARE\Adobe
  deleted C:\Users\you\AppData\Roaming\Adobe
  deleted C:\Users\you\AppData\LocalLow\Adobe
  deleted C:\Users\you\AppData\Local\Adobe\AAMUpdater
  deleted C:\Users\you\AppData\Local\Adobe\Acrobat
  deleted C:\Users\you\AppData\Local\Adobe\AcroCef
  deleted C:\Users\you\AppData\Local\Adobe\CameraRaw
  deleted C:\Users\you\AppData\Local\Adobe\CoreSync
  deleted C:\Users\you\AppData\Local\Adobe\InDesign
  deleted C:\Users\you\AppData\Local\Adobe\OOBE
  deleted C:\Users\you\AppData\Local\Adobe\PMP
  ... (12 more)

== VERIFICATION: anything Adobe still registered (empty = clean)
  (end of verification)

An independent check afterwards, from a separate shell, found no Adobe service, task, startup entry, uninstall entry, Store package, registry hive or process. The only Adobe folders left are the two I chose to keep.

Takeaways

An uninstaller that refuses must name the blocker. “Apps that need it are still installed” cost an hour because it turned every other Adobe product into a suspect. The uninstaller had the product list in hand; the message could have carried one name.
A hidden dependency needs an invariant, and a test for it. “Every auto-installed, invisible component has either a live referrer or is removed” is one query against the inventory database. The empty reference table next to a live component is exactly the state a test would have caught.
Repair must not reinstall the fault. The one recovery the dialog offers re-runs the component installs. On this failure it is a loop.
A check with a sanctioned bypass is a policy. If the vendor’s own tool skips the dependency check and simply removes everything, the check is not protecting the user from a broken system. Be honest about which kind of check you are shipping.
Sign-in and updates do not belong on the uninstall path. Removing an app should not require authenticating to it, and should not wait for the app to update first.
Verify by enumerating the machine, not by asking the app. The app said nothing was installed. The inventory said five things were. The disk said 4.5 GB were. Only the last two are evidence.

← Back to Blog