Post here please.

All my sandboxes use a (red) border.
A sandboxed program (in this case FastCheck) that is started with an enabled "Start minimized" option leaves a visible border on the desktop while the according program is already minimized to system tray.

I'll take a guess on the border problem. If the program "minimizes" to tray by setting the main window's transparency to 0 instead of hiding the window, or minimizing and hiding the toolbar button, then the border could be left at the window's original position.

This is the behavior I have observed since the border was added to SandBoxie. Which is okay with me, it lets me know the malware is trying to hide an IE window on me (usually).

I haven't had any real issues with the betas. I'm currently using v3.35.10

The 3.35.13 version (for me) is not opening the browsers as quickly as the previous version 3.35.12,
Internet Explorer took so long to open that I had to stop it.
3.35.12 was/is the best version that I have used for a while for my system.
I use Opera 9.25 and Internet explorer 6.0, Keyscrambler, Window 2000 on fat32
With 3.35.12 Opera opened better than in previous versions, Internet Explorer seemed to open randomly (timewise) but was within reason. I mostly use Opera.
I reverted back from 3.35.13 to 3.35.12 and saw an immediate improvement.

There really isn't anything in .13 compared to .12 that could explain this. Perhaps it was just a coincidence, please try again.

My experience: I just installed 3.35.13 and see no significant change in load times (from v3.35.12)
for IE6, opera 9.23 (portable) and k-meleon portable (my default browser) on my XP machine.
This beta is running quite well so far.

As with soccerfan, 3.35.13 is equally quick here also with IE. The delay (because it is IE) may be more Windows related ... maybe start a fresh prefetch folder?

Mitch, Soccerfan, tzuk, thanks for the feedback...Yes, could be something to do with my system
I'm running Windows 2000 so I'm not sure that the prefetch applies to me but some people recommend not emptying the prefetch folder as it is unnecessary.
I tried making new registry value just to try it

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ Memory Management \ PrefetchParameters

dword value = EnablePrefetcher
set at 3
but it didn't seem to make any difference

That's probably true, but in your case you have been successful in isolating the delay to a particular application (IE) and a particular upgrade (Sbie) - it's possible the old prefetch files concerning that combination of the two programs has become corrupted. I didn't know 2000 didn't use prefetch though. Anyway, it was just a gamble.

In Sbie 3.35.13 (on XP), immediate recovery does not appear to work if
a file with the same name is already present. One needs to invoke quick recovery
via the sandboxie tray icon right-click to recover the file immediately.
Not sure if present in previous sbie versions. Not sure if it is specific just to my system.

EDIT: Sorry if this has already been reported elsewhere.

This isn't related to 3.35.13. Since forever, Immediate Recovery only identifies new files. (And more recently, also changes to files that were initially zero-length.)

Thanks for the explanation. I have no issues with this beta (.13) so far.

A work around for reghive access denied in v3.35.13

Lately, I've been experiencing an access violation; denied due to the file being in use, and that file would be the infamous reghive. After terminating sandboxie, explorer.exe (windows GUI) etc, I still couldn't access the file. Today, I decided to see if I could launch another program in the affected sandbox. Sure enough, I could. No registry access issues. I then terminated the running sandbox contents and was able to do as I pleased with the reghive. file.

So, it all boils down to this:

If you get stuck; can't delete sandbox contents due to reghive, cant move reghive, etc..., Restart the same program you ran previously in that sandbox. Terminate the program via sandboxie, Now you should be able to do as you like with the sandbox contents.

Running Win 7, Firefox 3.0.6, Generic High Definition Audio Device using Microsoft Driver 6.1.7000.0 (winmain_win7beta.081212-1400)

Driver files:
%windir%\system32\drivers\drmk.sys
%windir%\system32\drivers\HdAudio.sys
%windir%\system32\drivers\portcls.sys
%windir%\system32\SysFxUI.dll
%windir%\system32\WMALFXGFXDSP.dll

After installing v3.35.13 I found that sound was missing only for Firefox 3.0.6 and only while running sandboxed. I ran the Resource Access Monitor and through process of elimination found that these two entries had to be added to Resource IPC Direct Access in order to return sound to the application:

\BaseNamedObjects\TermSrvReadyEvent
\RPC Control\LSMApi

Does this represent a security exposure?