Crashes while deleting and clicking the ''background''

[makinero]

The application occasionally crashes while deleting files and clicking the "background" button


Screenshot:
https://s7.postimg.cc/dbpu84nt7/Screen_Shot_05-26-18_at_11.58_AM.jpg

crash DUMP:
TOTALCMD64.EXE.5296.dmp


File Name:
TOTALCMD64.EXE.5296.dmp
10.35 MB
https://www.datafilehost.com/d/32531758


Mod:
Subject line adjusted, was just maned as "Bug report" by OP

[ghisler(Author)]

I couldn't reproduce that so far, and the crash address isn't in my code. Do you delete to recycle bin, or directly?

[makinero]

I deleted several thousand files and wanted to delete in the background. If you can not reproduce the problem, it will always fail?
And I will always lose results after many-hour scanning of photos according to their dimensions. I do not want to scan many hours again because it is meaningless to waste precious time.
It does not matter if I'm removing to the Recycle or directly.

Reproduce Debug:

In TOTALCMD64.EXE.5296.dmp the assembly instruction at ntdll!memcpy+1ec in C:\Windows\System32\ntdll.dll from Microsoft Corporation has caused an access violation exception (0xC0000005) when trying to write to memory location 0x5c7d3ba0 on thread 0

Screenshot Error:
https://s15.postimg.cc/aqywyrz0r/Screen_Shot_06-01-18_at_08.29_PM.jpg

[Usher]

And I will always lose results after many-hour scanning of photos according to their dimensions.

Do you use any TC plugins for that job? They may be buggy and have memory leaks…

Do you use Alt+Shift+F7 for search? I have seen 32-bit TC 9.0 crashes after making such search on all disks (millions of files and and Terabytes of data).

Do you work with portable disks (USB drives etc.) or network storage? There may be problems with overheating or power supply if it's really intensive use. In such cases TC may lose connection and crash when operating with such uncertain storage.

[makinero]

In Explorer, I've never had such a problem and what you write about is nothing related to this TC problem. This is a bug in the application. I'm using the 64-bit version and I only have one big SSD. Whenever I report a bug in the application, each person claims that it is a problem with other things.
If you are deleting files in the TC, an occasional crash may occur when you want to work in the background during deletion.
Each time you lose your search results and you have to repeat the steps many times and this involves a repeated multi-hour scanning. I have enough. I do not want to search again because it is a waste of time because of the loss of jpg file search results.
I do not use any plugins, I do not need anything.
I do not delete a million files (!!!) of only about a thousand to 20,000 files.

[ghisler(Author)]

You can try switching to the Explorer delete method, via
Configuration - Options - Copy/Delete - Use Explorer delete method.

[mhanor]

I've encountered a crash in ntdll, while trying to delete files. It's very rare and I think it happens when I screw up the keys, like I give the delete command and cancel it at the same time by pressing Escape, or something like that - I've never managed to understand what keys I'm pressing and in which order. I use Shift+Del to delete, TC is set to use the Explorer delete method. I use Windows 10 64 bit (1709).

[MarcinW]

I found the reason. When analyzing dump file, the call stack is as follows:

Code: Select all

ntdll!memcpy+0x1ec
user32!RealDefWindowProcWorker+0x23c
user32!RealDefWindowProcW+0x5a
user32!DefWindowProcW+0xfc
comctl32!Button_WndProc+0x4f8
user32!UserCallWinProcCheckWow+0x1ad
user32!CallWindowProcAorW+0xdc
user32!CallWindowProcW+0x18
TOTALCMD64+0x60fb32

By analyzing stack contents and comparing with TOTALCMD64.EXE 9.12 code, I realized that the flawed call is:

Code: Select all

CallWindowProcW(xxx, yyy, WM_GETTEXT, wParam = 11 = buffer size, lParam = 5c7d3b90 = buffer pointer)

So, TC tries to read some window's text to a buffer pointed to by lParam. But there is an exception when writing to this buffer, so there must be something wrong with it.



Before the CallWindowProcW call, we can see:

Code: Select all

.text:0000000000A0FB14    movsxd  rax, [rbp+lParam]
.text:0000000000A0FB18    mov     [rsp+160h+AddrOfDestBuffer], rax
.text:0000000000A0FB1D    movsxd  r9, dword ptr [rbp+wParam]
.text:0000000000A0FB21    mov     r8d, [rbp+Msg]
.text:0000000000A0FB25    mov     rdx, [rbp+hWnd]
.text:0000000000A0FB29    mov     rcx, [rbp+lpPrevWndFunc]
.text:0000000000A0FB2D    call    CallWindowProcW

As we can see, an 8-byte pointer is created here by sign-extending a 4-byte lParam variable (movsxd instruction). This doesn't look nice.



Everything becomes clear at the beginning of the analyzed procedure - this is some window procedure, implemented in TC:

Code: Select all

.text:0000000000A0F970                 push    rbp
.text:0000000000A0F971                 mov     rbp, rsp
.text:0000000000A0F974                 sub     rsp, 160h
.text:0000000000A0F97B                 mov     [rbp+hWnd], rcx
.text:0000000000A0F97F                 mov     [rbp+Msg], edx
.text:0000000000A0F982                 mov     [rbp+wParam], r8d
.text:0000000000A0F986                 mov     [rbp+lParam], r9d

Apparently, the lParam parameter - which should be declared as an 8-byte variable for 64-bit window procedure - is declared as a 4-byte variable (because r9d register is used instead of r9).

So this can work as long as the pointer, received in lParam, is in the first 4 GB of the address space. In other cases, we will either overwrite some memory in the lowest 4 GB (if mapped) or crash (if not mapped).




Solution:

All TC window procedures should be reviewed - they should be declared as:

Code: Select all

function WindowProc(Window : HWND; MessageCode : Cardinal; wParam : WPARAM; lParam : LPARAM) : LRESULT; stdcall;

where HWND, WPARAM, LPARAM and LRESULT are defined in Windows.pas (LPARAM and LRESULT are 64-bit for 64-bit code).


In particular, some of window procedures can be found in the source code by searching for "GWL_WNDPROC" string.

Regards

[Usher]

So it may be the same reason for crashes in standalone search? Interesting.

[ghisler(Author)]

2MarcinW
That's indeed one of the things I changed in TC 9.20 beta: Some parameters were still 32-bit, so TC crashed when started above the 4GB limit in the address space.

I assumed that makinero reported a bug in TC 9.20 because this is the TC 9.20 bug forum. However, the address reported only makes sense in TC 9.12! The bug has been fixed in TC 9.20, so it shouldn't occur with the betas.

[Dalai]

@mods/admin(s): Would it be possible to change the topic title to a more meaningful one? "Bug report" is just generic, and probably nobody will open this thread when it appears in the search results. Thank you.

Regards
Dalai

[MarcinW]

I was able to reproduce the problem with TC 9.12, but not with TC 9.20 Beta - although I forced WM_GETTEXT messages with lParam pointing above 4 GB (after injecting my test code into TC process).

So I can confirm that the problem is fixed now

Regards

[ghisler(Author)]

Thanks!