Lightroom Classic .exe process needs 3 minutes to terminate after main window closes

  • 2
  • Problem
  • Updated 3 months ago
  • (Edited)
Hi,

Since this morning, LR has started to misbehave when exiting. No system change. No preference changed. No image added or removed from catalog. No image edited. Just opening LR and browsing in the Library module. An attempt to load another catalog failed and I immediately observed that the lightroom.exe process was still running and the catalog still locked.

Further investigations using Process Monitor showed that after the LR main window closed, the process was still alive for about 3 minutes. After that the process terminates normally or crashes.

Most of this time is spent trying to access .PDB files in C:\Program Files\Adobe\Adobe Lightroom Classic CC, C:\Program Files\Adobe\Adobe Lightroom Classic CC\DLL and C:\Program Files\Adobe\Adobe Lightroom Classic CC\Symbols. The DLL and Symbols subfolders do not exist.

Every Windows developer knows what this means. PDB files are used by debuggers in order to locate errors in the source files. They are never released with the final version. Am I running a debug release of LR ?

I also noted dubious accesses to Amazon servers at amazonaws.com although I'm not syncing.
Photo of Patrick Philippot

Patrick Philippot

  • 337 Posts
  • 58 Reply Likes

Posted 3 months ago

  • 2
Photo of karelu

karelu

  • 6 Posts
  • 1 Reply Like
"I also noted dubious accesses to Amazon servers at amazonaws.com although I'm not syncing." That's probably a license check... (I hope...)
Photo of Patrick Philippot

Patrick Philippot

  • 337 Posts
  • 58 Reply Likes
Problem gone after restarting the system.
Anyway, I'd like to know why it is looking for .PDB files upon exit.

That's the new trend. If your LR is crashing on you, doesn't terminate normally, doesn't start, etc. , you can choose between the following solutions :

- Restart your system- Uninstall / Re-install LR- Reset your Preferences- Rebuild your catalog.
This confirm the statement I made in another thread : LR is slowly shifting to the unreliable category.
Photo of John R. Ellis

John R. Ellis, Champion

  • 3603 Posts
  • 936 Reply Likes
Speculation: It may not be abnormal for the released version to look for PDB files when LR crashes. Perhaps at the beginning of the three minutes, LR had decided to crash and its crash reporter was looking for the PDB files as part of its normal routine.  Normally, they wouldn't exist in the released configuration and the crash reporter would quickly determine that and proceed without them. But something has obviously gone wrong -- the abnormality may not be that it's looking for PDB files but rather that something is taking three minutes.
Photo of Patrick Philippot

Patrick Philippot

  • 337 Posts
  • 58 Reply Likes
Agreed. However, the .exe is marked as a RELEASE_BUILD but the code in it appears to contain a lot of calls to debug oriented libraries / APIs and tool windows that are not accessible to the user in a documented way.
Also, sometimes LR didn't even crash. It just took a long time to terminate normally.

When writing code that must execute quickly, I prefer releasing a version that is free of any debugging calls and send a true debugging version to the user when something goes wrong. But the drawback of this approach is that sometimes the bug doesn't show up  in the debug version :-) .

Well, restarting the system solved this issue but I don't like when a problem is solved without any explanation.
Photo of John R. Ellis

John R. Ellis, Champion

  • 3603 Posts
  • 936 Reply Likes
"restarting the system solved this issue but I don't like when a problem is solved without any explanation"

Casting the magic spells of restarting, rebooting, and resetting preferences "fixes" far too many problems, in my opinion.
Photo of Patrick Philippot

Patrick Philippot

  • 337 Posts
  • 58 Reply Likes
Yes. Since about 5-10 years, I see a general problem with software quality. Not only at Adobe. It's general. Quality coding tends to be considered as too expensive, which is a mistake since maintenance and support for bad quality software cost even more.
Also, too many companies think that when using high level development tools, there's no need to understand what's going on under the hood. In France, we now have schools where "developers" are trained in 6 months. So it's not a surprise that people who are able to investigate and fix bugs at a low system level are now harder to find.