Consistent Crash hitting escape during network file moves in 1363a

[arof]

Running into a new consistent crash when trying to hit escape to cancel a file being moved by everything using the standard F7 move process on network drives mounted from my desktop PC while on my laptop, both running 1363a and with the laptop set to get the desktop's file list via network index. Didn't happen when on 1360a for over a month and rolling back my laptop install to 1360a stopped the crash from occurring, but it happened in 1361a, so it may be due to whatever changed in the final implementation of tabs. Edit: just managed to do it again on 1360a as soon as I posted this, so disregard that. Guess I just wasn't doing this kind of file move input before.

I get a brief popup of a box that I believe is the "do you want to cancel the search" then the laptop's Everything just crashes, even with just a single tab open. This occurred both with and without the Escape key bound to close tab.

The debug log of a sample of the crash is in the attachment (moving a 0 byte "testfile.txt" between drives E: and F:, then hitting escape), though it doesn't appear to show much (and I xxxx'd out user account names). My laptop doesn't appear to be generating actual crashdumps for the exe despite the stuff about WER, but let me know if you can't duplicate it and I'll dig up that setting.

[void]

Thank you for the crash report.
I haven't been able to reproduce the crash my end.



Is a crash dialog shown?

-If so, could you please send a mini crash dump:

• Please keep the crash dialog open.
• Download Process Explorer from Microsoft:
  https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer
• In Process Explorer, select Everything64.exe (If there is two, select the one using the most memory)
• Right click Everything64.exe and under Create Dump, select Create Mini Dump.
• Choose a filename and click Save.
• Please send this file to support@voidtools.com

Privacy

[arof]

It's a hard close, unfortunately, no time to get a dump and it's not making one. I realized I forgot to check the application event log, and it seems part of the issue is it's less of an Everything problem and more of a Win 10 issue, as the crash is being caused by a Win10 dll itself when I mess with the file move at a specific time:

Code: Select all

Faulting application name: Everything64.exe, version: 1.5.0.1361, time stamp: 0x656810c3
Faulting module name: DUI70.dll, version: 10.0.19041.746, time stamp: 0x55510662
Exception code: 0xc0000005
Fault offset: 0x0000000000035592
Faulting process id: 0x3480
Faulting application start time: 0x01da387596bf266e
Faulting application path: C:\Program Files\Everything 1.5a\Everything64.exe
Faulting module path: C:\WINDOWS\SYSTEM32\DUI70.dll
Report Id: 00de063a-1732-4c3f-8c0a-7829bdb73ea9
Faulting package full name: 
Faulting package-relative application ID: 

This laptop's Win 10 install is particularly haunted, as it has some bizarre issues I've never run into on any other system (after about a month uptime it runs out of some internal system resource and nothing will open at all unless I can cycle the networking services), so I'll just have to chalk it up to Windows silliness unless I can get a more detailed log. I don't doubt Everything is doing what it should be doing regarding triggering the file move operation, and I'm almost done this silly sorting project anyway. Thanks for the quick eyes on the issue, if I can narrow down any further details I'll let you know.

[tnovak]

Hi!

I don't know if it's related, but today I've also got 2 silent crashes without crash dialog, during moving files between folders on net drive (SMB, indexed as folders in Everything). It was about 1000 files. At first it moved cca 200 and crashed. Next try moved another 200. And third try moved the rest. So probably it was not a particular file.

Just a note, that another process was saving bunch of new files to another indexed folders in the same time of the crashes.

Code: Select all

Název chybující aplikace: Everything64.exe, verze: 1.5.0.1363, časové razítko: 0x657be1d2
Název chybujícího modulu: Everything64.exe, verze: 1.5.0.1363, časové razítko: 0x657be1d2
Kód výjimky: 0xc0000005
Posun chyby: 0x000000000002b945
ID chybujícího procesu: 0x2d48
Čas spuštění chybující aplikace: 0x01da38a6e14343fc
Cesta k chybující aplikaci: C:\Program Files\Everything 1.5a\Everything64.exe
Cesta k chybujícímu modulu: C:\Program Files\Everything 1.5a\Everything64.exe
ID zprávy: e0657b85-696a-45f0-94ca-742cf787fd58
Úplný název chybujícího balíčku: 
ID aplikace související s chybujícím balíčkem: 

Now I'm rebuilding indexes and will try it again with debug logging.

W10 19045.3803

Thank you.

UPDATE: Still crashing Debug log sent.
UPDATE2: Tried to downgrade to a1360 - for now no crashes...
UPDATE3: Tried a1361 - also no crashes...
!!! UPDATE4: Tried a1362 - crash after cca moved 200 files - so the crash cause was probably introduced in this update (maybe this???: "improved file change detection to folder indexes"). For now I'm sticking with a1361
UPDATE5: Using a1361, moved thousands of files and no crashes. So I'm nearly sure the bug is in a1362 and newer...

[arof]

Thanks to crash occurring a little slower this most recent time, allowing me to read the text of the popup, it was a new message I hadn't seen before, "Are you sure you want to cancel all transfers?" even though they had already finished but the operation hadn't been reflected in the local index yet because it was still being synced over the network. Additional tabs/windows seem to make the crash take longer, as this was repeatable to get the exact text (in 1363a).

Further testing proves out this timing, as long as you hit escape after the move window has finished but before the operation has been fully completed on the UI, it causes the crash.

Despite tnovak's post, I am able to get this to happen on 1631a, but the change in 1362 that allowed the UI to continue to be interactable when move operations are running may make it more likely to trigger this (potentially Win 10 exclusive) bug.

I'm still not getting a usable crash dump out of the process, unfortunately.

[therube]

a file being moved by everything using the standard F7 move process

What is "the standard F7 move process"?

network drives mounted from my desktop PC while on my laptop, both running 1363a and with the laptop set to get the desktop's file list via network index

Explain that more, if you would?

[arof]

What is "the standard F7 move process"?

The menu popup from Edit > Move to Folder. Causes a standard Windows move menu, etc. With none of the Advanced renaming tools, which seems to have less of an issue for some reason.

Explain that more, if you would?

So the files being opened/moved are on the desktop, and I'm on my laptop using Samba shares mounted with the same drive letters as they are on my desktop, triggering the file move with Everything between drives on my desktop using the laptop's Windows. I'm also using the network index feature in Everything so that my desktop Everything (indexing about 40million total items) has to update my laptop's copy of Everything that the files have actually finished moving, giving a short window during which I'm able to hit Escape after the move has completed on my screen but before the indexes have reflected the change, potentially spawning an option to cancel a move operation that has already completed, seemingly causing the crash. The more tabs/windows I have on the laptop, the longer the period of the update seems to take, and interestingly enough the longer it takes to actually crash.

It's a bizarre setup I know, but it's how I've been handling a sorting project in bed while I've been unable to be at my desk for longer periods over the past few weeks, and after an update from 1360 to 1363 on both desktop and laptop about a week ago, the laptop's Everything has crashed multiple times doing this, where I had no issues on 1360. While I've been able to duplicate the steps on 1360, I've had to basically do it intentionally.

[void]

This is a bug in Windows since Windows 8.

I don't have a solution at this stage.



As for your crash tnovak, disabling drag_drop_data_object_async_capability in Everything 1.5.0.1364a+ may help:

• In Everything 1.5, from the Tools menu, click Options.
• Click the Advanced tab on the left.
• To the right of Show settings containing, search for:
  async
• Select drag_drop_data_object_async_capability.
• Set the value to: false
• Click OK.

Please let me know if the crash persists after disabling this option.

[tnovak]

Hi!

I tried 1364a.
Sadly it's still crashing in the same manner regardless drag_drop_data_object_async_capability setting.
So I have to stick with 1361a. But thank you for try.

Could I help with this issue if I sent another debug log or do another action/test?

[void]

Thank you for testing 1364a tnovak,

Could you please try 1364a with monitor_file_operation disabled:

• In Everything 1.5.0.1364a, from the Tools menu, click Options.
• Click the Advanced tab on the left.
• To the right of Show settings containing, search for:
  monitor
• Select monitor_file_operation.
• Set the value to: false
• Click OK.

monitor_file_operation

[tnovak]

Hi!

I re-enabled the drag_drop_data_object_async_capability setting and disabled monitor_file_operation.

Now it works without crashing!

[void]

Thanks for confirming disabling monitor_file_operation helps.

I've found the issue and will have a fix soon.

[arof]

Thanks for the confirmation. I have coded an AutoHotkey script to handle piecemeal moves to avoid causing it as often, and will just be careful if doing any larger moves, or just do them from the desktop instead, where I have no issues and it goes faster anyway.

[void]

Everything 1.5.0.1365a fixes a crash when performing a file operation.

monitor_file_operation can be re-enabled.

To re-enable monitor_file_operation:

• In Everything 1.5.0.1364a, from the Tools menu, click Options.
• Click the Advanced tab on the left.
• To the right of Show settings containing, search for:
  monitor
• Select monitor_file_operation.
• Set the value to: true
• Click OK.

Please let me know if you see a crash with this version.

[tnovak]

Hi!

I re-enabled monitor_file_operation and tested 1365a. It's working without crash now!

The issue was fixed, thank you very much Now I can restore using the latest version of this amazing tool!