Slower CD/flash browse after entering specific archive

[ghisler(Author)]

I will check them, thanks! I guess that DiskDirExtended somehow determines that GAUP needs to be loaded for looking at a specific file in the lst file. Any idea what file that could be?

[MVV]

I have no any ideas why TC or DiskDirExtended loads GAUP only when I'm opening archive from USB stick and only on TC 7.55.

[ghisler(Author)]

As it looks, there is nothing I can do about it myself. I suggest that you:
1. Report this problem to the author of diskdir extended
2. Disable the GAUP plugin in the settings of diskdir extended. You can reach them in the pack dialog (Alt+F5): Choose the extension of diskdir extended, then click on "Configure".

I sill don't understand why Diskdir Extended is loaded at all when you just BROWSE the archive. As I understand it, Diskdir Extended needs the plugins only to CREATE packer plugins. Furthermore, I still cannot reproduce the problem you have that DiskDir Extended is called every time you change folders on the flash disk. Maybe your logs will help...

[ghisler(Author)]

I have analyzed your data now: I didn't have the following in the DiskDirExtended.ini:
UseCanHandleThisFileForWCXs=yes
UseCanHandleThisFileForWCXsExtensions=7z,exe

Once I had set them, I could reproduce the problem! In the debugger, I found out where they happen:

TC 7.55 now creates a separate thread to read the volume label for all disks which are not reported as drive_fixed (=harddisk), including network paths and flash disks.

This is done because I analyzed where TC was killed by users (via task manager) when it was hanging, and one of the more common reasons was a hanging GetVolumeInformation function (probably because a drive was no longer accessible).

At the exact moment when the thread should resume, I see DiskDirExtended activity in the Process Monitor log. As it seems, DiskDirExtended looks when TC creates new threads, and then starts some unknown activity - maybe reload the last archive? Only the author will know what it does then.

TC will wait exactly 5 seconds for the GetVolumeInformation thread to complete, and if it doesn't, it returns an empty volume label and lets the thread complete in the background. So what you see is this 5 seconds timeout when TC tries to read the header and fails.

Edit: I just had a long hang too, and a stopped TC via Task Manager. Windbg reveals that the error is in gaup_pro+1ecb, where it seems to call GetWindowTextA. Maybe it's trying to get the current path from TC itself? The hang occurs when one thread is starting (DiskDirExtended is busy) while another thread with busy DiskDirExtended is already running...

[MVV]

Well, it's great that you could reproduce this bug.

I think I can disable GAUP archives in DiskDirExtended.ini since I don't really need theese archives to be expanded. Actually I need to be expanded only standard formats (zip, rar, cab, 7z) and SFX archives. I'm using DDE to make catalogs of my CD/DVD and I'm using archives a lot so it is a great feature to have files inside of archives listed too.

I posted link to our discussion in DiskDirExtended topic.
Let's hope we will know exact bug reason!

[ghisler(Author)]

I have also sent an e-mail to the author of diskdir extended, in the hope that he will fix the problem.

[MVV]

BTW when I'm opening DIR archives CD/DVD browsing is slow too. And removing GAUP from ListAlways doesn't solve problem, only disabling UseCanHandleThisFileForWCXs helps (but w/o this option SFX archives are not expanded).

[ghisler(Author)]

Indeed the problem is with DiskDir Extended, not with GAUP. It's just more visible with GAUP because GAUP takes much longer to look at the file.

[TrePe]

Hello guys.
My plugin was reacting also to DLL_THREAD_ATTACH for some now unknown reason. That code was there from the beginning and did the same as for DLL_PROCESS_ATTACH. My plugin is calling every other plugin to determine CanYouHandleThisFile capability (if requested in ini file). And it did that also when DLL_THREAD_ATTACH appeared. So the solution was to delete one case statement with DLL_THREAD_ATTACH...
Thank you for investigation and letting me know.
I sent new version to Christian and if it solved the problem the new version will be made available.

[MVV]

TrePe, thanks for quick answer! It is great that you found bug reason. It is strange that in TC 7.50 bug wasn't visible.

BTW, I noticed that DllMain with reason=DLL_THREAD_ATTACH is called frequently but I think it is really unuseful in case of TC plugins since plugin is loaded only once.

[ghisler(Author)]

I noticed that DllMain with reason=DLL_THREAD_ATTACH is called frequently

Windows calls that whenever a new thread is created. TC 7.55 uses many threads to handle functions in background which could hang forever. I will try to keep such treads running to reduce the number of new threads needed.

[MVV]

Interesting, I thought that DLL_THREAD_ATTACH is called only when this DLL is loaded second, third etc time...

[ghisler(Author)]

No, see:
http://msdn.microsoft.com/en-us/library/ms682583%28VS.85%29.aspx

DLL_THREAD_ATTACH

The current process is creating a new thread. When this occurs, the system calls the entry-point function of all DLLs currently attached to the process. The call is made in the context of the new thread.
...

[MVV]

Oh, it was made for TLS... Currently compilers allow easier allocation of TLS sections. Anyway I haven't used this value before.

[TrePe]

Updated version of DiskDir Extended is on TC website.
Thank you again