DonationCoder.com Software > Find And Run Robot

Find and Run Robot - Freeze after Launch

<< < (2/4) > >>

skajfes:
I've sometimes got hangs in FARR when secondary disk drive got turned off by windows. Maybe that's the problem with you?

JoTo:
Hi mouser,

that is exactly the same behaviour and problem i talked about with you in the IRC channel. I am facing exactly this same problem on 2 Win7 machines with latest FARR. Also tried to clear history with no success, and i looked at my history and there were only lines starting with c:\blah blah, so no external drive, no network drive only system harddisk. But i cleaned the list, as the big FARR-Master told me. :) And i dont think i have a really big folder in my search path (but define BIG please :) ).

I'll try your second option to maybe see in which directory it starts to freeze. But, kfitting says, the problem is, it is not happening all the time. Kind of random freeze that is. I dont have recognized a rule to determine when it will freeze and when not.

That doesn't happen on my 2 XP machines, where i use the same FARR version though.

Greetings
JoTo

mouser:
Ok I will try to make a debug version and we can try to get to the bottom of this.

mouser:
This is for those experiencing farr HANGING while in the middle of search:

I need patient testers to run the debug version which I have uploaded here:
https://www.donationcoder.com/Software/Mouser/findrun/downloads/alpha/FindAndRunRobotD1.zip


Step 1:

Download the zip, rename the original FindAndRunRobot, then overwrite with the new one, and run it.

This debug version is going to create a *huge* debugout.txt file (under userdocs/DonationCoder/JrDebug or something like that) while running and searching (it's also going to run slower than normal version).

The size of this file could run several megabytes per search -- it contains lots of info about what farr is doing and the timestamps that the events are occurring.

Once you run the debug version go find that debugout.txt file to make sure you know where it is.


Step 2:

The hardest trick then is to try to get the freeze to occur.. once you get a freeze to occur, cancel or compete the search and then EXIT FARR (and don't restart it or the debug file will be overwritten!).


Step 3:

Then we'll want you to either zip and email me ([email protected]) the entrie debugout.txt file or if its really large, open it and grab everything from the last "search about to start with" down to the end.

Hopefully the timestamps there will give the clue about exactly where it's encountering the slowdown/hang.

mouser:
Based on my first report back, preliminary findings suggest that the hang may be occurring because the operating system is taking multiple seconds to resolve an OS api call to SHGetFileInfo to get system icon index for a display result.

Now there are a few options here for me to fix the problem.

The first may be to discover if the slowdown ONLY occurs when trying to resolve icons to LNK files -- if so, an easy solution might be for ME to resolve the lnk shortcut links and then request system icon indices for the real files.

To help determine if that  is a viable solution will require some more debug testers, or perhaps if there is something about the icons in the files that this triggers on -- it's still completely unclear what specifically triggers this slow icon request -- it may be just that windows is deciding to occasionally clear it's icon cache after N requests, etc., and that it's completely unpredictable.

The second option would be a more clever deferred-icon resolution approach, where i update icons in a separate thread, showing them with generic icons until while they are pending resolution.  This is feasible though not exactly fun.

Navigation

[0] Message Index

[#] Next page

[*] Previous page