30 sec delay on startup

[_b0ne]

It seems for some reason when FileAlyzer when launched with a command-line argument to a file, it takes 30+ seconds to display the GUI.

I've attempted to run it from the context menu, sendto, and command line. I've set the program compatibility to run with Win XP2 compatibility and administrator rights required, but these have no effect.

Here's a video example:

[url]http://www.cloverbasin.com/files/delay.7z[/url] 

(376 KB compressed file; contains 212mb uncompressed .avi; wow LZMA rocks)

The one thing that does have an effect is running the program without command-line arguments and selecting the File menu, then Open. This works instantaneously. Is there some weird 30 second timeout on Vista that I'm unaware of?

[Malwarebytes]

I can confirm this issue. Even trying to open a 0kb file using the context menu results in a 30 second delay at which point the entire GUI freezes and is unresponsive.

[PepiMK]

I've been recently working on something that takes 0 seconds to open... kind of a FileAlyzer Lite...

Good place to post an example screenshot I guess



Integration into the Explorer property pages means the contents is loaded only when the corresponding tab is opened (FileAlyzer loads more at startup to be able to create log files when scripted etc.). Pages for hash values, PE file properties (headers, sections, imports, exports, resources), text preview and audio tags already exist. And, if you open the properties for multiple files at the same time, it allows direct comparison on many of these pages.

Once FA Lite is more complete, FA itself will receive the updates from this as well

[PepiMK]

I wrote a new topic and made it a sticky in this forum; take a look at FileAlyzer Lite there if you want

[Malwarebytes]

Cool. Good work

Marcin

[stevebow]

I've noticed this delay too under Vista. When I use FileAlyzer (V1.5.5.0) via the context menu (the only way I use it) there is always this very long delay, no matter what the file type or size is. I didn't have such problems under XP/SP2.

Why the delay under Vista, and is a fix in the pipeline please? A very useful utility otherwise.

Thanks.

[Malwarebytes]

I can confirm it is only on Vista. I use this tool so often and I really like it much more over the portable version. Fix it if you can?

[stevebow]

Something I have noticed during this FileAlyzer delay is that the LED on my en NIC flashes and it appears some sort of data is being sent out. As soon as FileAlyzer appears the ethernet goes quiet again.

Very odd! This is not some sort of debug by any chance is it?

[stevebow]

Funny thing is, I just noticed today, FA works fine ie. appears in around a half second, if it is used on files on external drives such as USB HDs or flash drives. It's only on the various partitions of my internal drive (SATA) that I see this very long delay.

[PepiMK]

@Malwarebytes: portable version? Which portable version? :D

I should probably go and rewrite FileAlyzer 2 (hasn't been worked on for more than a year and is already outdated The new concept (load-when-needed) I started with FALite is probably better suited for FileAlyzer 2.

I read up what exactly is checked before the window is shown; "network LED" sounds like ExpandUNCFileName (to get the fully qualified name of the file on the network) could be at fault, but why that on local drives?
It gets loaded to the new style hex editor; not quite sure there, it loads the full file, so I might even remove it again.
I've moved the whole loading thing farther back in the application loading now for the next release; which might still take some time though since it'll contain features for another thing we're preparing.
And I've updated the block size used in the checksum generation algorithm (Checksum generation very slow); that one was previously using a size depending on the bytes per cluster of the drive the file was on, and while this had some error handling for the case the cluster size cold not be retrieved, the default value was not really well fitting. That's about the only thing that could really be drive-dependent.