Windows 8.1 Pro x64 - crash comctl32.dll

[ghisler(Author)]

I have added a lot of code in TC 9.20 RC3 to fix the Lister problem:
1. I try to catch the exceptions - when this happens, you won't get a scroll bar
2. When you first open Lister with F3, I open a second copy of Lister and immediately hide it. As long as this hidden copy stays open, the bug will not occur again.

Please test it!

I don't have a solution for the other bug because I'm not controlling the scroll bars there directly - they are normal Listbox windows. But you can open the compare tool as a standalone program:

wincmd.ini
[Configuration]
Comparetool=c:\totalcmd\totalcmd64.exe /S=C
or with spaces:
Comparetool="c:\Program Files\totalcmd\totalcmd64.exe" /S=C

[browny]

But you can open the compare tool as a standalone program

Usually, a fault in a thread, including thread termination, should not crash the main program.
Some threads that worked fine in XP used to cause exceptions on thread function exit for no obviuous reason in Vista; this had to be handled. There was no GUI involved.

[ghisler(Author)]

It's not a fault in a thread, not even a fault in Total Commander. It seems to happen when a window using scrollbars is closed, and then another window with scrollbars is loaded. Somehow the scrollbar theme gets corrupted and crashes, but only on Windows 8.1. Microsoft has more or less abandoned Windows 8.1 and older, so there is no hope for a fix from their side.

For Lister, I keep a hidden Lister window open in the background to prevent the crash. I haven't had the time yet to test whether this works with compare too somehow.

[browny]

Somehow the scrollbar theme gets corrupted and crashes, but only on Windows 8.1.

Windows Server 2016.
Syncronize Directories was open, and a number of times Compare by Content was called using Ctrl+F3; sometimes files were deleted on both sides.
RC3 crashed when exiting from Compare.

There was an example above, with non-GUI thread.
The thread's task was successfully completed, but the application was failing on thread termination for whatever reasons.
The idea was to let the thread die, but keep the main program running.
Simple exception catching did this.

[ghisler(Author)]

The fix in TC 9.20 is currently only for Windows 8.1. Windows Server 2016 should be based on Windows 10, and I cannot reproduce the bug on Windows 10 so far.

[browny]

For the record: final 9.20 64-bit in Windows 8.1 crashed when using Synchronize and Compare.

[petermad]

In TC 9.20 x64 final, when opening Lister for the first time in a TC session, a small Lister window (135x50 pixels) is opened before the full window is displayed and can be seen for approximately a second (this is a slow PC).

If that is the "hidden Lister window" it is pretty annoying.

It seems to open at the same x,y position as the "real" Lister window. Is it posible to open that pre-window behind TC's main window in stead, so the user doesn't have to see it until it has been hidden. Or altenatively let it have the same size as the "real" lister window - then it will just looks like a delay in loading the content of the final Lister window.

Or is that small Lister Window I see, just the real Lister window, but for some reason being collapsed at start?

BTW - I don't have any crashes with TC in my Windows 8.1

[ghisler(Author)]

In TC 9.20 x64 final, when opening Lister for the first time in a TC session, a small Lister window (135x50 pixels) is opened before the full window is displayed and can be seen for approximately a second (this is a slow PC).

If that is the "hidden Lister window" it is pretty annoying.

It is the "hidden window", and it is the ONLY way I found to prevent the crash on Windows 8.1. If I create the window directly hidden, or off screen, then the error still occurs.

It seems to open at the same x,y position as the "real" Lister window. Is it posible to open that pre-window behind TC's main window in stead, so the user doesn't have to see it until it has been hidden.

No, when I do this, the error still occurs.

I don't have any crashes with TC in my Windows 8.1

It's actually easy to reproduce with TC 9.12: Just open a releatively large text file with F3, close lister with ESC, repeat about 5-10 times.

[petermad]

It's actually easy to reproduce with TC 9.12: Just open a releatively large text file with F3, close lister with ESC, repeat about 5-10 times.

I have now tried that - with a 300 Mb file and a 165 Kb file.

I managed to get a crash 3 times from TC 9.12 and I have to open and close the file maybe 50 or more times before it happens. I reboot after each crash.

[ghisler(Author)]

The user who reported the bug sent me test files where the crash happened after only 5 tries.

[browny]

TC 9.20 64-bit, Windows Server 2016.
Pressed F3 to view Win32.readme.first.txt file, and got the dialog "close" or "debug".

> comctl32.dll!SBSetParms() Unknown Non-user code. Symbols loaded.
comctl32.dll!CCSetScrollInfo() Unknown Non-user code. Symbols loaded.
uxtheme.dll!ThemeSetScrollInfoProc(HWND__ * hwnd=0x00000000000a04ae, int nBar=0x00000001, const tagSCROLLINFO * psi=0x0000000001cc3ac0, int fRedraw=0xffffffff) Line 1193 C++ Non-user code. Symbols loaded.
user32.dll!SetScrollInfo() Unknown Non-user code. Symbols loaded.
user32.dll!SetScrollPos() Unknown Non-user code. Symbols loaded.
TOTALCMD64.EXE!00000000005e46f8() Unknown No symbols loaded.

[ghisler(Author)]

Yes, it's the same bug I fix for Windows 8.1. However, Windows Server 2016 is based on Windows 10, so my fix isn't applied there.

[browny]

Does a thread (Lister, Compare by content) must crash the main application? Especially, on thread exit.

[ghisler(Author)]

SetScrollPos isn't actually called from a separate thread. I my tests with Windows 8.1, I can catch the exception in SetScrollPos. However, afterwards, no scroll bars are shown any more, and all further calls to SetScrollPos/SetScrollInfo also crash. It's a bug deep in the Windows 8.1 theme services, and Microsoft doesn't seem to bother. The bug is fixed in Windows 10 (and doesn't appear in Windows 8 or older).

[Flint]

ghisler(Author)
I take it, the new key PreventScrollbarCrash was added in the course of fighting this problem. Is it correct?
The problem is, the description of this key in the help and history file is somewhat vague and does not help users to understand why it's needed, or in what case they need to configure it. I suggest to:
1) specify explicitly what the default value is (I suspect it's 1 in Windows 8.1 and 2016, and 0 in all other systems, but it's hard to be sure);
2) describe the side effects; now it just tells "prevent crash", so it sounds crazy that anybody might want to disable it; users need to know why there is this key at all, and especially that it's this key they can use to avoid the "strange Lister window" problem.