PhotoLab 8.1 crash dumps on exit -- solved

DxO PhotoLab Windows topics
1

PL8.1/Win11.
Recently I noticed several PhotoLab core dumps (170-180 MB *.dmp files) in %localappdata%\CrashDumps. Does it happen to anyone else?

It looks harmless but annoying. All crash dumps files were created few seconds after shutting down PL, with no message in PL logs that something was wrong. The last three lines in DxO.PhotoLab.txt were as usual:
DxONET.Extensibility.ServiceLocator - Info | Closing service ‘CrashHandlingService’ (init order = 1).
DxONET.Extensibility.ServiceLocator - Info | Closing service ‘SentryExceptionProcessor’ (init order = 1).
DxONET.Extensibility.ServiceLocator - Info | Closing service ‘ServiceLocator’ (init order = 0).
Crashes do not happen on each shutdown, so maybe some RAW file causes this, but I would guess it’s some race condition in PL code.

Some details:
In Windows Application EventLog all messages looked similar:
Application: DxO.PhotoLab.exe
Framework Version: v4.0.30319 (base version, the true version is 4.8.9282.0, as seen in PL log DxO.PhotoLab.txt, MS mess)
Description: The process was terminated due to an unhandled exception.
Exception Info: System.NullReferenceException
at DxONET.CorrectionEngine.Base.NativeObjectDxO::Image.get_Data(DxONET.CorrectionEngine.Base.NativePtrDxO::Image*)
at DxONET.CorrectionEngine.Image.Image.get_Width()
at DxO.PhotoLab.Viewer.TileGrid.ImageTileProvider+<>c__DisplayClass21_1.b__1()
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
at System.Windows.Threading.DispatcherOperation.InvokeImpl()
at MS.Internal.CulturePreservingExecutionContext.CallbackWrapper(System.Object)
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
at MS.Internal.CulturePreservingExecutionContext.Run(MS.Internal.CulturePreservingExecutionContext, System.Threading.ContextCallback, System.Object)
at System.Windows.Threading.DispatcherOperation.Invoke()
at System.Windows.Threading.Dispatcher.ProcessQueue()
at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
at MS.Win32.HwndWrapper.WndProc(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(System.Object)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(System.Windows.Threading.DispatcherPriority, System.TimeSpan, System.Delegate, System.Object, Int32)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr, Int32, IntPtr, IntPtr)
at MS.Win32.UnsafeNativeMethods.DispatchMessage(System.Windows.Interop.MSG ByRef)
at System.Windows.Threading.Dispatcher.PushFrameImpl(System.Windows.Threading.DispatcherFrame)
at System.Windows.Application.RunDispatcher(System.Object)
at System.Windows.Application.RunInternal(System.Windows.Window)
at DxO.PhotoLab.App.Main()

Visual Studio shows the crash here:
[DebuggerBrowsable(DebuggerBrowsableState.Never)]
internal unsafe NativePtr_003CDxO_003A_003AImage_003E Data
{
get
{
//IL_0016: Expected I, but got I8
uint num = 0u;
long num2 = ((long)P_0 = (long)m_nativePtr); // <<=== CRASHES HERE ==
if (num2 != 0L)
{
global::_003CModule_003E.DxO_002EObject_002ERetain((DxO.Object*)num2);
}

Stack dump by VS:
[Managed to Native Transition]
> DxONET.CorrectionEngine.dll!DxONET.CorrectionEngine.Base.NativeObjectDxO::Image.get_Data(DxONET.CorrectionEngine.Base.NativePtrDxO::Image* value) Line 250 C#
DxONET.CorrectionEngine.dll!DxONET.CorrectionEngine.Image.Image.Width.get() Line 336 C#
DxO.PhotoLab.Viewer.dll!DxO.PhotoLab.Viewer.TileGrid.ImageTileProvider.UpdateTiles.AnonymousMethod__1() Line 110 C#
… (and so on, like in EventLog)

2

Not me. I looked all over and didn’t find any folders with crash dumps for PL8. Only for an older release. I have had PL8 freeze and crash sometimes, and once crash just after I closed it (referencing memory at 0x000…), and have even used DxO’s nlog debugging add-on. Nothing was ever left behind by any of that. Curious.

3

Thanks for info. It seems that PL8 does more at exit than PL7 did. Looks like the main thread does some post-processing even after all other threads are already finished. Maybe it’s final preview generation (?).

Currently I suspect that some ancient Nikon NEF raw files edited with CaptureNX2 may be the culprit. CaptureNX saved edits and some previews directly in the NEF files and I’ve seen them crash even NX Studio. I’ll try to reproduce the problem when I find time.

UPDATE: It has nothing to do with raw files modified by CaptureNX2, it seems.
I got another dump after working in two directories, with only Nikon Z8 unmodified raws, all taken with supported lenses and their modules previously loaded. Both directories contained files processed earlier. The stack looks like in OP. I couldn’t reproduce the crash. All PL crashed sessions contained somewhere in the log a series of 32 lines like
DxOCorrectionEngine - Warn | Task 1-PreProcess cancelled
but not all such sessions ended in a crash. Can’t recall what may have caused these log entries – maybe changing the directory (?).

Looks like some race condition. The only harm it does is taking disk space (160-170MB per dump, using Windows default of 10 for the max number of dumps in this directory).

4

I also got a bunch of dump-files using Windows 10 and DXO Photolab 8.1.0 Build 434. I had at least 10 dump-files around 130MB each. But I think it might only be after crash.

Photolab 8.1 crashes a lot for me, more or less at least once every time I use it. Never during export, only during normal operations.

I never had any issues with earlier versions. I even upgraded to another computer with more GFX RAM and a clean windows 10 install, but 8.1 crash just as often on the new computer as on the old computer. I usually send reports when I get the opportunity (not always an option) so I hope they will fix it.

5

I correct myself. I verified the behavior.

PL8.1 creates a crash dump file every time I close the program. I just started PL 8.1 and without doing anything at all, closed it again. A dump file were created. So not only when crashing.

I can also add that I never used CaptureNX2, but I get the dump-files anyway.

A can also add that I downgraded to 8.0, and it also creates dump-files when closed.

7

PL8 creates crash files when it crashes too.
My 40Mo of crash files have been a nightmare.
Let’s hope this will be solved at next update.

8

All my crashes (0xC0000005 - Access Violation due to unhandled NULL pointer dereferencing) happen in “managed code” (.NET CLR) when exiting PL. All internal services are already closed and only 4 threads are still alive, the crash is in the main thread. No PL specific crash log is created, just universal Windows application minidump. PhotoLab log does not contain anything interesting, because the crash happens after the log is closed. There are two associated entries in Win EventLog – one is Application Error Event 1000 with fault type general description, the other is .NET Runtime Event 1026, containing stack dump of the offending thread.

It turned out that these crashes have nothing in common with CaptureNX. For example, one of the crashes happened after visiting a directory without any suspected files and exiting without doing any edits. They do not happen on every run, maybe 30% end up in a crash. No clear correlation with edits and looks like some race condition.

I’ve just updated to Win11 24H2, so I’ll wait for next crash before calling DxO support. Maybe it was due to .NET bug. As said before, they are harmless and probably most people don’t even notice them, so I didn’t have enough motivation to escalate.

Stack dump from EventLog .NET Runtime:

Application: DxO.PhotoLab.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.NullReferenceException
   at DxONET.CorrectionEngine.Base.NativeObject<DxO::Image>.get_Data(DxONET.CorrectionEngine.Base.NativePtr<DxO::Image>*)
   at DxONET.CorrectionEngine.Image.Image.get_Width()
   at DxO.PhotoLab.Viewer.TileGrid.ImageTileProvider+<>c__DisplayClass21_1.<UpdateTiles>b__1()
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
   at System.Windows.Threading.DispatcherOperation.InvokeImpl()
   at MS.Internal.CulturePreservingExecutionContext.CallbackWrapper(System.Object)
   at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
   at MS.Internal.CulturePreservingExecutionContext.Run(MS.Internal.CulturePreservingExecutionContext, System.Threading.ContextCallback, System.Object)
   at System.Windows.Threading.DispatcherOperation.Invoke()
   at System.Windows.Threading.Dispatcher.ProcessQueue()
   at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
   at MS.Win32.HwndWrapper.WndProc(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
   at MS.Win32.HwndSubclass.DispatcherCallbackOperation(System.Object)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
   at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(System.Windows.Threading.DispatcherPriority, System.TimeSpan, System.Delegate, System.Object, Int32)
   at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr, Int32, IntPtr, IntPtr)
   at MS.Win32.UnsafeNativeMethods.DispatchMessage(System.Windows.Interop.MSG ByRef)
   at System.Windows.Threading.Dispatcher.PushFrameImpl(System.Windows.Threading.DispatcherFrame)
   at System.Windows.Application.RunDispatcher(System.Object)
   at System.Windows.Application.RunInternal(System.Windows.Window)
   at DxO.PhotoLab.App.Main()
9

So your crashes are different, perhaps due to a bug triggered by local adjustments edits (which I rarely use). At least that’s what I understood from your posts in several topics. I don’t see any crash report created by PL code, only EventLog entries and minidumps created automatically by Windows. Do you have some details to share, which I asked for in one of those threads?

10

I’ve sent any possible autogenerated bug report to DxO (so I would say about 1/2 or 2/3 because sometime this window did not appeared before PL crashed and disappeared).
And I have an open ticket with them too, and they asked for my crash report file so they have it.
Now I wait for their next response.

I did not (because I don’t like to modify a working and stable workstation neither to use it for internet, but now this choice is not a really viable option, since OS can even change a driver when it works fine - our workstations are no longer ours).
But can you tell us if this has improved things? Maybe there’s anyway a link between what you’re seeing and my experience.

11

I’v had a number of crashes since V8 installed not one created a PL crash log only W11 Critical event reports. Its not even been constant events doing it so I wouldn’t like to hazard a guess what the problems have been. Little point reporting to DXO as no log and just there clearly is some instability in V8 and just hope others have had logs to pin it down. Though as it happens on my less used laptop as well I cant help but feel they must have had this before release and since at DXO.

12

So I hope they’ve got what happened to me in the log files I sent them and not only what @Wlodek describe …
But they’ve got a bunch of autogenerated bug reports too (sometime 4 or 5 in 15mn …).

13

I just found some crash dumps lots of them in \AppData\Local\CrashDumps. Are these DXO or Windows ones as PL crash dumps used to be in a DXO folder so never looked anywhere else?

14

In my case DxO asked me those files :

  • %HOMEPATH%\Documents\DxO PhotoLab 8 crashes
  • %HOMEPATH%\Documents\DxO PhotoLab 8 logs.

But no other files.

And yes, when looking in the folder you talk about I see several files. All are Dxo.Photolab.exe.xxxx.dump files. But there are lot less than the number of crashes I’ve got (there are only 10 in 3 days - those 3 complicated days).

15

I just got another minidump after hitting Exit with exactly the same stack, so 24H2 does not help.

16

Thanx.
So I will wait for now and not upgrade window too fast.
Anything else works fine on my station.

17

That’s default limit for Win11 (DumpCount=10) in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps. See Collecting User-Mode Dumps - Win32 apps | Microsoft Learn. Check Application EventLog for ‘.NET Runtime’ errors – you should see all of them with stack info.

18

OK. thanks to the tip.
So I will backup them, just in case they would be needed.

19

These are generated by Windows. Happens when PL does not handle it’s own exceptions.

1 Like
20

Thanks no point my keeping them they start late October so appear to be PL v8 crashes

21

%HOMEPATH%\Documents\DxO PhotoLab 8 crashes No reports there at all on either laptop or PC