Just to be clear : this thread is not about the problem I'm trying to fix for this user. The actual problem is that the LR6 delivered code is still emitting these "assertion failed" messages and that it should not. I can't see any good reason for this. Debug assertions are a development tool and should not survive in the delivered code.
Thank you for posting in the user to user forum. I have passed your comments to the development team.
The asserts are LUA runtime exceptions (LUA is the runtime programming language used by Lightroom) that typically indicate some abnormal condition has occurred in the code. In the normal case, the developers would employ defensive programming techniques to watch out for these abnormal conditions and handle them appropriately as they arise. But unexpected cases still happen, they are rare and typically involve cases that the code does not anticipate. Most often, they expose bugs that needs to be fixed. So they are conditions that developers wants to know when they occur.
When Lr encounters such runtime exceptions, it can generate the tracebacks log if it is enabled (see https://forums.adobe.com/thread/925598) so that developers can use the traceback logs to know exactly where (the callstack) and why the assert happened. In such cases, Adobe can be aware of the issue and fix the real underlying bugs, rather than keep it unnoticed.
So, if I understand you well, you are telling me that LUA doesn't have Structured Exception Handling (actually, I already know that). Therefore a routine for catching unhandled exceptions cannot be inserted in the code and assertions are used instead.
I will not discuss the choice of LUA for developing LR (especially for a program that needs performance). There's no chance to change anything about that anyway. However, since LUA has limited capabilities regarding error handling, LR should have its own built-in mechanisms instead of relying on DbgView (or at least use DbgView in a transparent way).
Unless I'm missing something obvious, I have never seen any directive about the use of DbgView when a user reported an "assertion failed" message. When LR crashes with such a message, it should display instructions as described in the thread you mentioned. This would be the bare minimum. Also, a built-in log mechanism would be easier for the user. Instead of asking the user to add an argument on the command line, a key combo (like the one used to reset the preferences) should be available in order to launch LR in debug/tracing mode. DbgView could be a part of the distribution and could be launched as soon as that key combo has been detected, when the process begins to execute.
In other words : don't think developer, think user.
If you want information about the cause of the assertion failure, you need to make the reporting easy for the user. That's not something that is difficult to implement.
By the way, now that someone from the development staff is talking to us, I have a question about those bugs that are lasting since years and that are still waiting for a fix. A good example is this one which is lasting since version 1 :
This bug has been reported multiple times, is identified and probably easy to fix. But we continue to be bothered by these endless warnings about the metadata status allegedly not up-to-date. This is just an example, we have a lot of such bugs waiting to be fixed since years (like the bugs related to a failed assertion as discussed above) and not only in Lightroom. I'm questioning the way bugs are managed at Adobe. Once a bug has been declared as "minor", we can rest assured at 90% that it will never be fixed.
I have already suggested to handle the priority list another way : the "todo" list should be worked on from both ends. The majority of available development/maintenance resources should be dedicated to the most urgent bugs but some developers should work on the low priority bugs which are most of the time very easy to fix. Or the maintenance developers should spend a part of their time looking at these low priority bugs what they obviously never do. If you think "customer satisfaction", you know that these allegedly minor but unfixed bugs are those who are giving a bad feeling about code quality. So they should be handled seriously.
[MODERATOR Hi Samoreen. You have cross posted to the feedback forum. It is more appropriate to continue the discussion of the issues raised in that space rather than in this community]