Crashes while deleting and clicking the ''background''

Bug reports will be moved here when the described bug has been fixed

Moderators: white, sheep, Hacker, Stefan2

Post Reply
User avatar
makinero
Member
Member
Posts: 161
Joined: 2013-10-26, 10:05 UTC

Crashes while deleting and clicking the ''background''

Post by *makinero » 2018-05-26, 10:07 UTC

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

User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 36434
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Post by *ghisler(Author) » 2018-05-28, 14:32 UTC

I couldn't reproduce that so far, and the crash address isn't in my code. Do you delete to recycle bin, or directly?
Author of Total Commander
http://www.ghisler.com

User avatar
makinero
Member
Member
Posts: 161
Joined: 2013-10-26, 10:05 UTC

Post by *makinero » 2018-06-01, 17:28 UTC

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

User avatar
Usher
Member
Member
Posts: 122
Joined: 2011-03-11, 10:11 UTC

Post by *Usher » 2018-06-01, 20:33 UTC

makinero wrote: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.
Regards from Poland
Andrzej P. Wozniak

User avatar
makinero
Member
Member
Posts: 161
Joined: 2013-10-26, 10:05 UTC

Post by *makinero » 2018-06-02, 19:22 UTC

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.

User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 36434
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Post by *ghisler(Author) » 2018-06-03, 10:29 UTC

You can try switching to the Explorer delete method, via
Configuration - Options - Copy/Delete - Use Explorer delete method.
Author of Total Commander
http://www.ghisler.com

mhanor
Junior Member
Junior Member
Posts: 22
Joined: 2010-04-07, 11:04 UTC

Post by *mhanor » 2018-06-05, 20:01 UTC

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).

User avatar
MarcinW
Power Member
Power Member
Posts: 852
Joined: 2012-01-23, 15:58 UTC
Location: Poland

Post by *MarcinW » 2018-06-06, 02:06 UTC

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

User avatar
Usher
Member
Member
Posts: 122
Joined: 2011-03-11, 10:11 UTC

Post by *Usher » 2018-06-06, 09:34 UTC

So it may be the same reason for crashes in standalone search? Interesting.
Regards from Poland
Andrzej P. Wozniak

User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 36434
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Post by *ghisler(Author) » 2018-06-06, 16:36 UTC

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.
Author of Total Commander
http://www.ghisler.com

User avatar
Dalai
Power Member
Power Member
Posts: 6249
Joined: 2005-01-28, 22:17 UTC
Location: Meiningen (Südthüringen)

Post by *Dalai » 2018-06-06, 20:00 UTC

@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
#101164 Personal licence
Athlon X4 880K, 16 GiB RAM, Gigabyte F2A88X-D3HP, Win7 x64

Plugins: Services2, Startups

User avatar
MarcinW
Power Member
Power Member
Posts: 852
Joined: 2012-01-23, 15:58 UTC
Location: Poland

Post by *MarcinW » 2018-06-08, 17:10 UTC

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

User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 36434
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Post by *ghisler(Author) » 2018-06-11, 14:07 UTC

Thanks!
Author of Total Commander
http://www.ghisler.com

Post Reply