Bug: ExitThread after dispay each directory entry

[milo1012]

So just point me to the 'API call' of 'FileSystemControl' or 'Display(DirEntry1)'!

Use RMB in process monitor -> (Call) Stack:
E.g.

Code: Select all

0    fltmgr.sys    FltAcquirePushLockShared + 0x907    0xfffff88001202067    C:\Windows\system32\drivers\fltmgr.sys
1    fltmgr.sys    FltIsCallbackDataDirty + 0xa39    0xfffff88001203329    C:\Windows\system32\drivers\fltmgr.sys
2    fltmgr.sys    FltDeletePushLock + 0x4f2    0xfffff88001222942    C:\Windows\system32\drivers\fltmgr.sys
3    ntoskrnl.exe    NtMapViewOfSection + 0x15a7    0xfffff80003defe67    C:\Windows\system32\ntoskrnl.exe
4    ntoskrnl.exe    NtFsControlFile + 0x56    0xfffff80003dac892    C:\Windows\system32\ntoskrnl.exe
5    ntoskrnl.exe    KeSynchronizeExecution + 0x3a23    0xfffff80003ad1e53    C:\Windows\system32\ntoskrnl.exe
6    wow64cpu.dll    TurboDispatchJumpAddressEnd + 0x6c0    0x74dd2e09    C:\Windows\SYSTEM32\wow64cpu.dll
7    wow64cpu.dll    TurboDispatchJumpAddressEnd + 0x1fb    0x74dd2944    C:\Windows\SYSTEM32\wow64cpu.dll
8    wow64.dll    Wow64SystemServiceEx + 0x1ce    0x74e4d286    C:\Windows\SYSTEM32\wow64.dll
9    wow64.dll    Wow64LdrpInitialize + 0x42a    0x74e4c69e    C:\Windows\SYSTEM32\wow64.dll
10    ntdll.dll    RtlIsDosDeviceName_U + 0x23a27    0x773ed447    C:\Windows\SYSTEM32\ntdll.dll
11    ntdll.dll    LdrInitializeThunk + 0xe    0x7739c34e    C:\Windows\SYSTEM32\ntdll.dll
12    ntdll.dll    NtFsControlFile + 0x15    0x7756fe0d    C:\Windows\SysWOW64\ntdll.dll
13    SHELL32.dll    SHCLSIDFromString + 0x1210    0x75c7ce89    C:\Windows\syswow64\SHELL32.dll
14    SHELL32.dll    SHCLSIDFromString + 0x1112    0x75c7cd8b    C:\Windows\syswow64\SHELL32.dll
15    SHELL32.dll    SHCreateShellItemArrayFromIDLists + 0x1392    0x75c55fa3    C:\Windows\syswow64\SHELL32.dll
16    SHELL32.dll    SHCreateShellItemArrayFromIDLists + 0x114e    0x75c55d5f    C:\Windows\syswow64\SHELL32.dll
17    SHELL32.dll    SHCreateShellItemArrayFromIDLists + 0x12b2    0x75c55ec3    C:\Windows\syswow64\SHELL32.dll
18    SHELL32.dll    SHCreateShellItemArrayFromIDLists + 0x11d3    0x75c55de4    C:\Windows\syswow64\SHELL32.dll
19    SHELL32.dll    SHRestricted + 0xd52    0x75c6fd7d    C:\Windows\syswow64\SHELL32.dll
20    TOTALCMD.EXE    TOTALCMD.EXE + 0x2e0736    0x6e0736    E:\TotalCmd\TOTALCMD.EXE
21    TOTALCMD.EXE    TOTALCMD.EXE + 0x18c9a    0x418c9a   E:\TotalCmd\TOTALCMD.EXE
22    TOTALCMD.EXE    TOTALCMD.EXE + 0x362e    0x40362e    E:\TotalCmd\TOTALCMD.EXE
23    kernel32.dll    BaseThreadInitThunk + 0x12    0x7686338a    C:\Windows\syswow64\kernel32.dll
24    ntdll.dll    RtlInitializeExceptionChain + 0x63    0x77589f72    C:\Windows\SysWOW64\ntdll.dll
25    ntdll.dll    RtlInitializeExceptionChain + 0x36    0x77589f45    C:\Windows\SysWOW64\ntdll.dll

In that case it always points to :

Code: Select all

INVALID DEVICE REQUEST	Control: FSCTL_LMR_QUERY_DEBUG_INFO

My experience with these monitors is that they display mostly low level garbage.

If you think so...
It helped me quite often to understand some program's behavior,
no need to start some debugger that might not work at all if you're out of luck.

[Lefteous]

2milo1012

It helped me quite often to understand some program's behavior

Yes it helps sometimes but I was looking for a program that displays just top-level Winapi calls not the native stuff. Depending on the program this can be quite complex.
In this case you just don't know what API called 'FileSystemControl' (which doesn't seem to be Winapi btw.).

[ghisler(Author)]

I have checked it in the debugger now: TC does not create a thread for each file when initially reading the directory. This is done when displaying each line to call ParseDisplayName in a separate thread. This function has been hanging TC in the past, so I have moved it to a separate thread.

This isn't slowing down the initial reading of the directory, because it happens when each line is displayed.

[Isica]

Can you confirm that no threads are created when you disable overlay icons?

When overlay icons is disabled, created about three times smaller streams. But they still are!

However, in version 7.55, the threads are not created ever, even with overlays icons! And the list of files is displayed and ready to work immediately, and icons are loaded in the background.
In general, in version 7.55, it is done correctly. Perhaps even perfect!

[milo1012]

When overlay icons is disabled, created about three times smaller streams. But they still are!

Of course you still have thread creations, but this isn't a problem.
And since you confirmed that most of them are gone w/o overlay icons you have your conclusion now,
and the reason why this is different than in previous versions gave you Christian above.

However, in version 7.55, the threads are not created ever, even with overlays icons! And the list of files is displayed and ready to work immediately, and icons are loaded in the background.

Again: do you actually see or can you measure any real speed impact on an average machine?
Anyway, I'd prefer a slightly slower version over a buggy one.

In this case you just don't know what API called 'FileSystemControl' (which doesn't seem to be Winapi btw.).

I didn't say that all main entries you see there are API calls, but you rather get the main API operations in a grouped/descriptive manner.
That's why you'd open the Call stack for such entries.
And because it's a call stack you know which function invoked the next function.
In my example above it may be SHCreateShellItemArrayFromIDLists when you activate Overlay Icons,
which is perhaps called due to IShellFolder.ParseDisplayName.

But sure, for "hanging" threads or processes I'd also prefer Process Explorer.

[ghisler(Author)]

Threads are still created when TC needs an item-idlist for a file, which can be needed for certain icons. However, this is not done within the function which reads the directory, as I said above.