In the past week or so the process 'icdd' has been starting from time to time and when it does it consumes massive amount of RAM (upwards of 7 GB). When this happens, my MacBook Pro essentially becomes non-functional until I can open the Activity Monitor and force-kill the process.

I've attached a screenshot of the activity monitor showing icdd using over 7GB of RAM and making the memory pressure skyrocket.

enter image description here

Does anyone know what this process is or how I can prevent this issue from occurring every 30 minutes or so?

  • 1
    You're not the first person to have this problem. See if this answer helps: superuser.com/questions/748933/… – NoahL Oct 22 '16 at 21:10
  • 1
    icdd is related to the Image Capture.app/service. Do you have any devices like a scanner, printer-scanner or camera attached? – klanomath Oct 22 '16 at 21:22
  • Also - if you log out and then back in - how does the 7.24 used (1.08 App, 1.75 Wired. 4.41 Compressed) change? It could be a simple memory leak that logging out and in clears. If it doesn't clear, I'd try disabling the virus scanner and rebooting and seeing if memory climbs as fast. – bmike Oct 22 '16 at 21:24
  • That solution was not applicable to my issue. @klanomath I have no external devices attached to my MacBook. – Zach Oct 22 '16 at 21:38
  • @Zach lcdd is controlled by a launch agent. It contains a key "Enable pressure exit" which is disabled by default. You may enable it temporarily (=kill lcdd if memory pressure gets to high) and check the result. Like bmike already mentioned the real reason probably is a memory leak though... – klanomath Oct 22 '16 at 22:05

I have been working with a senior technical advisor at Apple on this issue for over a year, and was working with another senior advisor for some time before that. We have done "data capture" to send to Apple Engineers on several occasions and done screen recordings on several occasions to demonstrate what is going on in Activity Monitor, Image Capture, and, ultimately, in a plist that icdd maintains at /Users/user_name/Library/Application Support/icdd/deviceInfoCache.plist (by displaying it in Xcode).

At this point, here is my best estimate of what is happening:

The icdd (Image Capture Device Database) process sees scanners come and go on a busy network. It attempts to keep a list of their icon files in a hash table, which it also writes to the deviceInfoCache.plist file mentioned above. Yes - this sounds crazy - it is keeping references to the scanners' icon files. But even crazier is that, for some reason, almost all of the entries in this file point to .icns files that do not exist. Of several systems I've looked at, there have been many thousands of entries in the file, yet only a few of the .icns files existed on one of the machines, and none existed on the others. I believe that when this file gets large, icdd is spending a lot of time trying to check for the existence of entries in the .plist file and modify the file. I believe this for two reasons. First, when I take my laptop home, the icdd process sometimes continues to run at about 100% of a CPU, but when I then kill it, it goes back to the "normal" approximately 0.0 to 0.1%, every time. Hence, I think it is sometimes still trying to process information about the entries when I open it up at home. But when I kill it while on the busy network, it often comes back at near 100% right away. When the number of scanners shown in Image Capture goes down (which it often does, but will periodically spike for some reason), icdd will eventually settle down. And second, deleting the deviceInfoCache.plist file causes icdd to behave reasonably for a short while - until the number of entries builds up again. Note that icdd maintains a copy of these entries in memory, so if you delete the file from the user account, icdd just rewrites it immediately. And, of course, you can't kill icdd long enough to delete the file, so you have to log out and delete the file from another administrator account via the terminal. icdd will recreate the file when you log back in, but it will have relatively few entries and behave well for a while.

To give some idea of scales, Apple Engineers were shocked to see that I had as many as 85 scanners displaying in Image Capture. Often, however, this number will settle down to about 6 on the same system and during the same timeframes. The deviceInfoCache.plist file has had between 8,000 and 12,600 entries on the systems that I've looked at that have had icdd problems - mine is the larger one, and I believe this got carried over from an older machine since I was having icdd issues from the time I set up my new MacBook Pro in 2016-Dec. When I deleted the plist file, the number of initial entries in the newly created file was 44, and for a few days icdd cpu usage hovered close to 0.0%. However, after about 5 days on campus, my plist file has 964 entires, and icdd cpu usage will routinely bounce between 30% and 90% on the busy network at the university. When I am at home, the plist file will only increase its number of entries by 0 to 2 over the course of a day. Of the 12,600 entries in my previous plist file, only 2 of them contain a "deviceName", the rest contain an "iconPathLocation", all of which point to nonexistent .icns files. With the current plist, there are still exactly 2 entries that contain a "deviceName", and the rest contain an "iconPathLocation" that does not exist.

So, the short-term solution is to delete the plist file from another administrator account via terminal while logged out from your user account. Hopefully, with this information now being provided to Apple Engineers from my Senior Advisor, Apple Engineers will have enough information to figure out why icdd is acting this way and fix the problem. Of course, it would probably help if you can verify my short-term solution and continue reporting what you find to Apple.

  • Good entry, that gives some under-the-hood understanding of how the icdd behaves. But what is it for? where do these icons (at least the existing ones) are displayed? What function this icdd is responsible of? and when you delete the .plist files, what functionality do you lose? Also, in my case, there are 5 users on the same Mac, and their icdd .plist files do NOT agree, but that causes icdd to crash occasionally and not to collect garbage and hog on CPU. – Motti Shneor Apr 4 '20 at 5:25
  • @Motti Shneor The deviceInfoCache.plist would occasionally have an actual device listed in it, and I think this is the intended purpose. I think it was a bug that was causing it to keep track of icon-image files - most of which didn't exist. This was my initial guess, but I say this with more confidence now because looking at my current version of this plist, it has exactly one entry, which is for an actual device. Hence, I think Apple fixed this at some OS version (I suspect in Catalina). – datatoolbox Apr 5 '20 at 20:02
  • @Motti Shneor In deleting the plist, I never noticed any change in functionality - the OS just rebuilt the file as needed, which doesn't appear to take much time. Every user has their own plist for this, and intentionally so - if one user uses a scanner and another does not, I would expect their plists to reflect this difference. So I doubt different users' plists would have an interaction effect. – datatoolbox Apr 5 '20 at 20:04

I have been dealing with this problem for a while and have been checking everywhere! It is frustrating ... Finally I found a link that I could stop this stupid madness. I am not sure if this is the source of the problem but it could stop it. Here are the steps:

1) disable SIP (link)

2) type the following commands:

cd /Applications

sudo mv Image\ Capture.app/ Disable\ Image\ Capture.app/

cd /System/Library/Image\ Capture/Support/

sudo mv icdd icdd-disable

3) reboot

4) enable SIP if you care

Original link: https://havecamerawilltravel.com/photographer/prevent-photos-app-mac-osx

Hopefully it helps.


I've been struggling with this problem as well. Not finding answers online and not wanting to mess with terminal, I called Apple Support. Initially, they thought my HD was corrupted (it was - that was fixed but did not fix the problem). The problem persisted after increasing my RAM. Prompted by an internet comment regarding network scanner searches, I noticed that ICDD would only get crazy when Wi-Fi was enabled. If I disconnected from wi-Fi and quit ICDD, it would not restart and climb in RAM or CPU usage (until Wi-Fi reenabled).

I called Apple Support again who seem to have fixed the problem by resetting SMC and NVRAM. Now ICDD runs at a low level (10-20 MB) rather than consuming 10+ GB of RAM. I've added links below for doing those, but I'd recommend calling Apple Support for your specific problem.

Their explanation for why this is happening had to do with my RAM being clogged or full with internet caches, etc. Why it has just now become apparent and whether it is associated with Sierra, I cannot say.

I hope this helps some people!

Reset SMC: https://support.apple.com/en-us/ht201295

Reset NVRAM: https://support.apple.com/en-us/ht204063

10-15mins fix.

My specs:

  • early 2011 13" MacBook Pro
  • 500 GB Samsung SSD (upgraded ~1.5 yr ago)
  • 8 GB RAM (upgraded ~1 month ago)
  • macOS Sierra 10.12.3 (up to
  • Parallels 10 with Windows 10 for SAS software

While the above answers provide better technical data, I'd like to add a general note.

What we're dealing with is probably a lousy piece of software, that carries old bugs for years, that was not tested properly, and will probably never get fixed. That's all. In the last decade Apple software engineering is deteriorating in a constant way, and we have to put up with such scenarios all the time.

Usually resetting such software pieces to their original state (say, by deleting caches and setting files, .plists or even resetting their user-defaults) would ease the problem for some time.

Another way is to reset the OS related subsystem. In this case for example, a right click in the printers system preferences panel will let you "reset the printing system", which will probably clear icdd's head for a while - but will force you to setup your printing environment again.

And of course, opening new RADR entries to Apple may eventually get their attention to the faulty subsystem.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .