WinSCP GUI crashes arbitararily if there's a new version available

If there's a new version available and a user refused to update, WinSCP will crash at some point after a startup. It could be any activity at this moment including being idle.
The Windows Event Log has the record:

Faulting application name: WinSCP.exe, version: 5.21.5.12858, time stamp: 0x00000000
Faulting module name: MSHTML.dll, version: 11.0.19041.2006, time stamp: 0x2f20bbb2
Exception code: 0xc0000005
Fault offset: 0x0035c510
Faulting process id: 0x185cc4
Faulting application start time: 0x01d90647331d0fa0
Faulting application path: C:\Users\username\AppData\Local\Programs\WinSCP\WinSCP.exe
Faulting module path: C:\WINDOWS\SYSTEM32\MSHTML.dll
Report Id: 1b58d653-8dd5-4388-906b-84a68dca61ee
Faulting package full name:
Faulting package-relative application ID:

Repro steps:
1. Run WinSCP GUI when there's a newer version exists
2. Refuse to update (it seems crucial for reproducing that the update request is appearing at startup)
3. Leave it for some random time (it could be minutes or dozens of minutes)
4. Eventually it will silently crash

Windows 10 21H2

I've noticed this behavior several versions ago but wasn't sure about the conditions. The issue always disappears when I update to the current version.

Thanks for your report.
I have sent you an email with a debug version of WinSCP to the address you have used to register on this forum.

Hi,

I have the exact same issue for years, but only realized recently it only happens when a new version is available. If the new version dialog shows up when WinSCP starts and I close the dialog, then the application will crash silently each time I lock my Windows session. It does not happen if I disable the new version check or if no new version is available. When the new version check is disabled and I manually check for a new version (and there is one), the crash still happens when session locks.

It only crashes when the update dialog has been closed, so it looks like some resources have not been released/unregistered properly when the dialog is closed. The crash happens in mshtml (access violation), most likely when the WM_SETTINGCHANGE/ImmersiveColorSet message is received, so it might only happen when dark mode is used. A traceback image for 5.21.3 is attached.
OnSettingsChangeAlldoc() seems to loop through all registered documents and call OnSettingsChange() on them, so my guess is the update dialog/component is still registered but released from memory, so there is an access violation eventually.

I don't know if the problem has been/is being solved, but I'm willing to help if needed. Providing an up-to-date debug version will probably not trigger the crash though, as the new version dialog will not show up.

@Teyut: Thanks a lot for your detailed analysis! I'll try to reproduce the problem using your hints. I'll contact you if I need more information.

I have added this bug to the tracker:
Issue 2148 – Failure when system theme changes after new version message box was displayed
I'm sending you an email.

I've had this problem for years!
Thanks for finding the cause!