Skip to main content
Participating Frequently
July 29, 2026
Question

Lightroom Classic crashing almost all the time, possibly because of corrupted adobe shared components

  • July 29, 2026
  • 28 replies
  • 281 views

Have been having a lot of crashes with LRc 15.4.1 for a week or so. Currently the situation is so bad, that moving from library to dev the app crashes every time. I’ve been sending a lot of crash reports. I’ve also tested multiple files from different cameras over past 20 years, the issue stays.

I’ve also tested downgrading LRc, issue doesn’t go away. I also tested the other Lightroom, Photoshop, Bridge and Bridge (beta) - all crashing equally the same, when changing to dev/edit or in case of bridge an ps, just opening any raw file. This suggests that the problem is somewhere in Adobe shared runtime stack that is used by all of the apps. 

I also repaired Creative Cloud installation, no help. Files can be opened just fine in any other capable app. 

I created new catalogs to see if it was catalog corruption, but it is not. 

I have gone through all the usual Windows error checkings, sfc, dism, chkdsk, even the memory check. no problems there. All my other apps and even games work fine. 

Windows 11, all up-to-date. Nvidia drivers, updated - yesterday (studio drivers) (didn’t help). 

Analyzing all the issues with the tools that are available in Windows it seems that the issue is as follows: a component is not handling memory properly, causing: RADAR_PRE_LEAK_64 - and getting terminated by Windows RADAR (memory leak protection). I can see this leak when LRc freezes, it just runs up to 20G of RAM usage or thereabouts and then usually after a moment the crash report dialog appears. And that’s not even close to my limits of RAM. 

The problem is triggered by looping  AgRedeye_load over and over, 20-40+ times (different per crash). It fails, because “ zip_source_win32handle_create” cannot access a zip file (either the file doesn’t exist or is corrupted, or the function has an error - can’t tell, don’t have access to source files). At least once it propagated to LUA and crashing it and killing LRc. 

Now, of course i was wondering, if this is caused by some change in Windows defender, but disabling runtime checks, folder access checks etc didn’t change and it’s logs don’t show any action anyway, so it was not blocking adobe libs or any adobe related files. 

Anyway. This has been going on for a week or so. During that time I believe there was a win11 update (hmm, maybe 2), camera raw update and maybe creative cloud update. so the issue comes from one of those, possibly. 

I uninstalled 2 of the latest Windows updates, but it didn’t solve the problem. I downgraded LRc, but no change. I can’t downgrade Camera Raw (creative cloud has no option for that), so I can’t test that. 
I also can’t downgrade Adobe shared libs. 

I can’t give you the system info, as i’m currently uninstalling everything and later doing an full reinstall of adobe apps/creative cloud (but that’ll have to wait. I will be away from the computer for most of the day). 

Anyway, it’s really frustrating. Really have photos from 4 shoots to edit and 2 coming later this week. Would be nice to be able to deliver.. 
Also a note for the devs: i probably used my backup-email for crash reports. Sorry about that. 

Windows 11 Home, Nvidia Geforce RTX 5060TI, Intel 13th gen i7-13700KF, 64G RAM, and all the drives that are used for catalogs/previews/cache are fine by chkdsk and have plenty of free space.  

 

 

    28 replies

    davidwarner11t
    Participating Frequently
    August 19, 2026

    You’ve done a very thorough job narrowing this down. Since multiple Adobe apps are crashing and the AgRedeye_load loop causes the RAM spike, it really sounds like a shared Adobe component rather than your catalog or hardware. Hopefully the crash reports give the developers enough to pinpoint the regression.

    sakarikAuthor
    Participating Frequently
    August 21, 2026

    it’s actually invalid file handle in ziplib, that agredeye calls. memory spikes were fixed in 15.5.  

    sakarikAuthor
    Participating Frequently
    August 15, 2026

    I found another interesting log, from AppData/Roaming/Adobe/Lightroom called lrc_console.log 

    I’ll pick these interesting few lines; what was running just before the crash in previous session: 
     

    2026-08-15 23:38:07.685: Last command(s) run in previous session: ag.develop.updateImageForAutoSettings
    ag.photobin.selectionChanged
    ag.photobin.selectionChanged
    ag.photobin.selectionChanged
    ag.photobin.selectionChanged
    ag.photobin.selectionChanged
    ag.photobin.selectionChanged

     

    This is my test catalog with just one raw image. The real culprit is still the duo of AgRedeye_load and zip_source_win32handle_create causing EXCEPTION_ACCESS_VIOLATION (0xc0000005), though. 

     

    Sameer K
    Community Manager
    Community Manager
    August 18, 2026

    Thank you for the incredibly detailed investigation - your analysis of the AgRedeye_load loop and the memory spike behavior has been very helpful.


    I can confirm that this crash pattern is a known issue that our team is actively working on. What you're seeing is a failure in Camera Raw's Red-Eye correction module (AgRedeye_load), where it fails to handle resource access failures gracefully under memory pressure.
    Because it is Camera Raw, other apps are rightfully impacted.
    In the meantime, try this:


    Increase your virtual memory/page file size on Windows - while you have 64 GB RAM, the memory spike pattern can benefit from a larger page file as a safety valve. I couldn't find Microsoft's documentation on it, so I'll ask you to run a safe search before you make any changes.


    Thanks!
    Sameer K

    sakarikAuthor
    Participating Frequently
    August 19, 2026

    Thanks for the heads-up ​@Sameer K - i’ll look into that page file size when i have a moment. 

    sakarikAuthor
    Participating Frequently
    August 13, 2026

    Had a free moment to look at this a bit. 15.5 version does not get that Mem Leak anymore, but it does still crash as follows: Multiple AgRedEye_load() -function calls - followed by zip_source_win32handle_create() → exception access violation. So it seems that libzip is trying to create a zip file and whatever happens in that function fails for some reason, that i cannot figure out from the crashlog. The crashing thread also contains ntdll and kernel32. not a surprise, of course. 

    Today i managed to open LRc 15.5, straight into DEV mode, move 3 sliders from basic and then added a point in curve and tried to move it, freeze and crash instantly. Crashlog is on it’s way. 

     

    sakarikAuthor
    Participating Frequently
    August 12, 2026

    Tested after installing mandatory update  KB5121003 from Microsoft, no change in behavior, still crashing. Log is being sent from LRc right now, but it’s huge so it takes time. 

    sakarikAuthor
    Participating Frequently
    August 7, 2026

    @Sameer K I hope there’s some progress regarding this.. 

    sakarikAuthor
    Participating Frequently
    August 4, 2026

    I’ve sent fresh reports from LRc, LR, and just updated PS. For your entertainment. Hopefully they are useful. All seem to crash differently on Canon RAW:s but somehow still tied to libzip or something just before it. 

    sakarikAuthor
    Participating Frequently
    August 4, 2026

    @Sameer K - sad to report that 15.5 update did not fix my issues. New crashlog is being sent currently. Culprits seem to still be  zip_source_win32handle_create and  AgRedeye_load. Tested both on previous test catalog and of course i created a new fresh catalog. This time crash happened quite immediately after import while building 1:1 preview (was set on import, as for testing i’m using just one photo). Looking forward for a fix. 

    PBMarc
    Known Participant
    August 1, 2026

    I can confirm: LRc 15.4.1 crashes / freezes … this is a new issue. The memory usage climbs to 99% and task manager reports LRc is suspended.  Sometimes I cannot terminate it.

    • Latest Nvidia studio driver 610.88.
    • Windows 10 Pro 10.0.19045
    • Processor    Intel(R) Core(TM) Ultra 9 285K   3.70 GHz
    • Installed RAM    32.0 GB (31.3 GB usable)
    • Storage    932 GB SSD Samsung SSD 9100 PRO 1TB, 14.55 TB HDD ST16000NM000J-2TW103, 1.82 TB SSD CT2000T705SSD3
    • Graphics Card    NVIDIA GeForce RTX 5090 (31 GB), Intel(R) Graphics (128 MB)
    • System Type    64-bit operating system, x64-based processor
    • Pen and touch    No pen or touch input is available for this display
    • NO OVERCLOCKING
    KR Seals
    Community Expert
    Community Expert
    August 13, 2026

    It might be unrelated to the crashing, but you should disable the Intel GPU in the computer BIOS. LrC and PS do not work well/properly with more than one GPU.

    Ken Seals - Nikon Z 9, Z 8, 14mm-800mm. Computer Win 11 Pro, I7-14700K, 64GB, RTX3070TI. Travel machine: 2021 MacBook Pro M1 MAX 64GB. All Adobe apps.
    sakarikAuthor
    Participating Frequently
    July 31, 2026

    One caveat to TIFF file editing is lens profiles; if i try to use lens profiles the crash happens; with libzip being the culprit, giving an idea that possibly lens profiles are ‘zipped’ or zip-like (processable by libzip, anyway) and libzip fails for whatever reason. lens profiles look “ok” to me in the directory, no empty files or so. didn’t bother to write a script to see what’s inside. also, didn’t try this on NEF or JPG, but i’m quite sure and confident that there will be crash with those also if i enable lens corrections. 

    sakarikAuthor
    Participating Frequently
    July 31, 2026

    @Sameer K - also one more VERY useful info: Nikon NEF (raw file) from around 2009 - No problems at all. Just ANY Canon RAW from the past 20 years do crash.