I'm running this on Windows XP, 3-bit; 4GB RAM. I have 9TB online (8TB are external USB3 drives); about 700K entries.
When I try to rename a folder in the file list, Everything crashes. This has been repeatable all morning, and a couple times yesterday as I recall. Editing individual filenames doesn't cause the problem.
Running Everything in -debug -verbose mode seems to fix it (!)... so I can't post any logs from that. I do attach what I got from the crashes at the time, below.
----------
The LWSDebugOut file created just has a massive number of these lines:
CDeviceInfoMap::GetDeviceFriendlyName() - !pDeviceInfo - failed m_DeviceInfoMap.Lookup(lDeviceID=: 0
.\DeviceInfoMap.cpp
Line: 313
CDeviceInfoMap::GetPnPId() - failed m_DeviceInfoMap.Lookup - device ID: : 0
.\DeviceInfoMap.cpp
Line: 406
----------
The 'appcompat' crashfile has this:
<?xml version="1.0" encoding="UTF-16"?>
<DATABASE>
<EXE NAME="Everything.exe" FILTER="GRABMI_FILTER_PRIVACY">
<MATCHING_FILE NAME="Everything.exe" SIZE="840704" CHECKSUM="0x73CCB145" BIN_FILE_VERSION="1.3.1.636" BIN_PRODUCT_VERSION="1.3.1.636" PRODUCT_VERSION="1, 3, 1, 636" FILE_DESCRIPTION="Everything" PRODUCT_NAME="Everything" FILE_VERSION="1, 3, 1, 636" ORIGINAL_FILENAME="Everything.exe" INTERNAL_NAME="Everything" LEGAL_COPYRIGHT="Copyright (C) 2005-2012 David Carpenter" VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x0" MODULE_TYPE="WIN32" PE_CHECKSUM="0xCDBAD" LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="1.3.1.636" UPTO_BIN_PRODUCT_VERSION="1.3.1.636" LINK_DATE="02/20/2013 10:56:07" UPTO_LINK_DATE="02/20/2013 10:56:07" VER_LANGUAGE="English (United States) [0x409]" />
</EXE>
<EXE NAME="kernel32.dll" FILTER="GRABMI_FILTER_THISFILEONLY">
<MATCHING_FILE NAME="kernel32.dll" SIZE="990208" CHECKSUM="0xCC2C4544" BIN_FILE_VERSION="5.1.2600.6293" BIN_PRODUCT_VERSION="5.1.2600.6293" PRODUCT_VERSION="5.1.2600.6293" FILE_DESCRIPTION="Windows NT BASE API Client DLL" COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Microsoft® Windows® Operating System" FILE_VERSION="5.1.2600.6293 (xpsp_sp3_gdr.121001-1622)" ORIGINAL_FILENAME="kernel32" INTERNAL_NAME="kernel32" LEGAL_COPYRIGHT="© Microsoft Corporation. All rights reserved." VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0xFBCBC" LINKER_VERSION="0x50001" UPTO_BIN_FILE_VERSION="5.1.2600.6293" UPTO_BIN_PRODUCT_VERSION="5.1.2600.6293" LINK_DATE="10/03/2012 04:58:13" UPTO_LINK_DATE="10/03/2012 04:58:13" VER_LANGUAGE="English (United States) [0x409]" />
</EXE>
</DATABASE>
-----------
There is nothing in the Everything errorlog.txt file for this event, but the following is what I usually see in there:
2/27/2013 2:07 PM: Everything 1.3.1.636b: .\src\os.c(5729): os_get_usn_journal(): DeviceIoControl(0000021c,FSCTL_QUERY_USN_JOURNAL,0,0,015af068,56,015aef0c,0): 1: Failed to query USN Journal.
2/28/2013 1:03 PM: Everything 1.3.1.636b: .\src\os.c(5729): os_get_usn_journal(): DeviceIoControl(00000224,FSCTL_QUERY_USN_JOURNAL,0,0,015af068,56,015aef0c,0): 1: Failed to query USN Journal.
2/28/2013 1:03 PM: Everything 1.3.1.636b: .\src\os.c(5729): os_get_usn_journal(): DeviceIoControl(00000208,FSCTL_QUERY_USN_JOURNAL,0,0,015af068,56,015aef0c,0): 1: Failed to query USN Journal.
3/2/2013 4:57 AM: Everything 1.3.1.636b: .\src\os.c(5729): os_get_usn_journal(): DeviceIoControl(0000021c,FSCTL_QUERY_USN_JOURNAL,0,0,015af068,56,015aef0c,0): 1: Failed to query USN Journal.
Everything 1.3.1.636b crashes when renaming folder
Re: Everything 1.3.1.636b crashes when renaming folder
Further info -
I had thought that running Everything in debug mode fixed the problem, and for a few hours that seemed true. But today I am back to very frequent crashes when renaming a folder within the Everything results list. I did have Everything in Debug - Verbose. The following is the last parts of the console printout right up to the crash:
Updating \\?\Volume{01c38af5-958e-11e1-900b-001fc6733469} (G:):
EVENT: 11
waiting for 3 handles, isdelay 0...
update filesystem G:
updated in 0.018190 seconds
waiting for 3 handles, isdelay 1...
EVENT: 3
_DB_WAIT: db_process_shell_notify_queue waiting...
_DB_WAIT: db_process_shell_notify_queue waited 0.000263 seconds
waiting for 4 handles, isdelay 0...
Updating \\?\Volume{01c38af5-958e-11e1-900b-001fc6733469} (G:):
EVENT: 11
waiting for 3 handles, isdelay 0...
update filesystem G:
updated in 0.018638 seconds
waiting for 3 handles, isdelay 1...
EVENT: 3
_DB_WAIT: db_process_shell_notify_queue waiting...
_DB_WAIT: db_process_shell_notify_queue waited 0.000334 seconds
waiting for 4 handles, isdelay 0...
Updating \\?\Volume{c59d64c7-7721-11e2-88d6-001fc6733469} (L:):
waiting for 3 handles, isdelay 0...
MSG: c0a9 00000011 0003018e
MSG: 0402 00000000 00000000
EVENT: 11
MSG: 0200 00000000 00580125
MSG: 0101 0000000d c01c0001
update filesystem L:
MSG: 000f 00000000 00000000
_DB_WAIT: db_get_result_count waiting...
rename westvalley - piano recital may09
renamed -8594951 subfolders and 5884966 files from westvalley - piano recital may09 in 0.012221 seconds
rename westvalley - piano recital may09
updated in 0.016268 seconds
waiting for 3 handles, isdelay 1...
_DB_WAIT: db_get_result_count waited 0.016506 seconds
Updating \\?\Volume{01c38af5-958e-11e1-900b-001fc6733469} (G:):
waiting for 2 handles, isdelay 1...
waiting for 3 handles, isdelay 0...
[NOTE - the file being renamed was on an external USB drive 'L', not on internal drive G:
Internal drive G: was one of the three drives being indexed (one internal and two external).
I had thought that running Everything in debug mode fixed the problem, and for a few hours that seemed true. But today I am back to very frequent crashes when renaming a folder within the Everything results list. I did have Everything in Debug - Verbose. The following is the last parts of the console printout right up to the crash:
Updating \\?\Volume{01c38af5-958e-11e1-900b-001fc6733469} (G:):
EVENT: 11
waiting for 3 handles, isdelay 0...
update filesystem G:
updated in 0.018190 seconds
waiting for 3 handles, isdelay 1...
EVENT: 3
_DB_WAIT: db_process_shell_notify_queue waiting...
_DB_WAIT: db_process_shell_notify_queue waited 0.000263 seconds
waiting for 4 handles, isdelay 0...
Updating \\?\Volume{01c38af5-958e-11e1-900b-001fc6733469} (G:):
EVENT: 11
waiting for 3 handles, isdelay 0...
update filesystem G:
updated in 0.018638 seconds
waiting for 3 handles, isdelay 1...
EVENT: 3
_DB_WAIT: db_process_shell_notify_queue waiting...
_DB_WAIT: db_process_shell_notify_queue waited 0.000334 seconds
waiting for 4 handles, isdelay 0...
Updating \\?\Volume{c59d64c7-7721-11e2-88d6-001fc6733469} (L:):
waiting for 3 handles, isdelay 0...
MSG: c0a9 00000011 0003018e
MSG: 0402 00000000 00000000
EVENT: 11
MSG: 0200 00000000 00580125
MSG: 0101 0000000d c01c0001
update filesystem L:
MSG: 000f 00000000 00000000
_DB_WAIT: db_get_result_count waiting...
rename westvalley - piano recital may09
renamed -8594951 subfolders and 5884966 files from westvalley - piano recital may09 in 0.012221 seconds
rename westvalley - piano recital may09
updated in 0.016268 seconds
waiting for 3 handles, isdelay 1...
_DB_WAIT: db_get_result_count waited 0.016506 seconds
Updating \\?\Volume{01c38af5-958e-11e1-900b-001fc6733469} (G:):
waiting for 2 handles, isdelay 1...
waiting for 3 handles, isdelay 0...
[NOTE - the file being renamed was on an external USB drive 'L', not on internal drive G:
Internal drive G: was one of the three drives being indexed (one internal and two external).
Re: Everything 1.3.1.636b crashes when renaming folder
I am aware of the issue, it has been fixed for the next release of Everything.
Re: Everything 1.3.1.636b crashes when renaming folder
I just found the latest update to the beta. Thanks so much for maintaining and improving this terrific tool. If I lost it, I'd have to simply give up on a major (and very important to me) cataloging project.