wraithdu, you might remember that I said I revised the immediate recovery mechanism to scan the set of open files so it knows for sure when the program is done with the file. Well by "scan" I mean get the name of an open file, and that is something that is prone to lock ups if done the "proper" way with official APIs. (You can google "obquerynamestring hang" if you want to know more.) At first I thought I could work around it but the debug logs here show it didn't work as I expected. But even in the best case scenario (i.e. if it succeeds in preventing the lock up) it would still introduce intermittent delays. Luckily I have a driver available to me so I was able to do it some other way, which requires a driver, and seems to produce much better results.

I'd like to take this opportunity to thank everyone who had this problem for your patience and I'm glad to hear the latest revision resolves the problem.

I'm somewhat familiar with finding open file handles, and I've run into the same problems while messing around with it in AutoIt (user mode only). I was only querying file objects (using NtQueryObject), but it came down to skipping objects with particular 'GrantedAccess' values. But even then there were certain processes with open handles that would still hang (most notably the BtStackServer process associated with my bluetooth adapter on Vista).

In the end I abandoned it, but I know there's a way to do it reliably with a driver, since Sysinternal's Process Explorer does it all the time. However I've been unable to find a full description of how it accomplishes this through google

NtQueryObject -- right, that's actually what I meant and what I too was using. In a driver it's a straightforward thing. Given a handle to a file (which you might get from NtQuerySystemInformation) you can easily reference the file object, and it contains the name of the file.

There some more complicated aspects to this for Process Explorer, because that driver is probably executing in the context of ProcExp.exe, but needs to look at handles that belong to other processes. So that would probably involve either duplicating the handle into ProcExp.exe first, or perhaps instead the driver is doing KeStackAttachProcess on the target process.

Either way, that's complicated stuff. For me it's much easier because the sandboxed process is enumerating itself, so everything is in the same process context.

tzuk:

You can also count me among your long list of satisfied customers in regards to the Immediate Recovery issue.

Thank you.

Regards,
Mike

Just reporting in to add to the list of happy users.

XP Home Edition ver 5.1.2600 SP-3 Build 2600
Sandboxie ver 3.37.10 beta (Now)
FF ver 3.0.7
Comodo Firewall ver 3.8.65951.477
PC Tools Antivirus 2008 ver 5.0.1.1

With the latest Snadboxie version, (non-beta) I was also having the same FF hang problems many others were reporting. Hanging after --import, quick recovery, virus scan.

I just downloaded Sandboxie 3.37.10 beta and tried again.
Download, quick recovery, scan, works perfectly. Excellent fix Tzuk. Thanks!!!