I've noticed in FF that when navigating a Save File dialog (initiated by a download) if I try to use the breadcrumb feature it takes a long time for the dropdown folder list to appear (click the arrows on the breadcrumbs to get the menu). Similarly, if I try to rename a file or folder in the same save dialog FF hangs for a good 30 seconds, but the rename operation eventually succeeds. It doesn't matter if the file/folder is in an OpenFilePath or not.

Win7 RTM Pro 32-bit
SB 3.39.23

I'm not seeing this behavior. Did you try to enable the Resource Access Monitor just before renaming, to see if it is trying to reach any resources outside the sandbox during those 30 seconds?

I invoked the Resource Access Monitor with the Save Dialog already open, then tried to rename a file. Immediately upon opening the RAM I get a ton of

SBIE1242 Monitor buffer overflow

errors. After ~30 seconds and the file is renamed, here is the RAM output:


The TSVNCache Pipe is a resource of Tortoise SVN. I opened it up to see if it would make a difference, it had no effect. If I open the RAM before I click the download, I start getting the SBIE1242 errors immediately after opening the Save dialog.

I get basically identical RAM output, including SBIE1242 errors, with the sluggish breadcrumb menu as well.

Here's a IpcTrace=ad / Dbgview output for the file rename, started capturing after the save dialog is open, but before I initiated the rename.

snipped. --tzuk

Please try version 3.39.25.

The hang is still there. Here's another RAM ouput, this time I started capturing before I pressed 'Save File' in the Firefox download dialog, then renamed a file, then saved the RAM output. I have an OpenPipePath=\Device\NamedPipe\TSVNCache* exclusion for TortoiseSVN. If I remove this exclusion, I get the 'SBIE1242 Monitor buffer overflow' errors again.

snipped. --tzuk

I see you're still getting X's on KnownDlls. I have no idea why you would still get that, unless your indicates to override system DLLs. Can you check if the registry in your sandbox contains this key:

HKLM\SYSTEM\CurrentControlSet\Control\SbieHideKnownDlls

?

From a sandboxed regedit, this key does not exist.

I tried adding that key and here's the RAM output, seems the same to me:

snipped. --tzuk

Also, after adding that key, I got an error message:

SBIE2205 Service not implemented: NtRenameKey

Results are the same with the hang still there.

Well, here's something. If I add these two resources:


Then renaming only takes ~7 seconds or so. This is the same amount of time to rename a file in an unsandboxed Firefox. Here's the RAM output:

snipped. --tzuk

If I add the other 2 CLSID strings, then RAM shows an X next to them, so I didn't include them. The rename time was the same with/without them anyway. Any idea if those resources pose a security risk?

Turns out the only resource I need to open is the 'Desktop Undo Manager'

Good to see you've been able to improve the situation. I guess there might still be some Windows 7-related quirks that would have to resolved over time.

Also, I hope you won't see any SBIE2327 messages now as a result of the OpenClsid.

I'm going to move this topic to the Open Issues forum, to revisit the issues you've raised at some later point.

I'll let you know if I get any related error messages, but so far I haven't.

For reference, what does it mean when the CLSID's are shown with neither an X nor an O? Well, I guess what does that mean for any resource? And why would an OpenClsid setting to a COM object that previously showed up in a RAM log result without an X nor an O, then result in an X?

For CLSIDs, no indication means the OpenClsid mechanism was not involved, and the log doesn't say if the creation of the object was successful or if it failed.

Any other indication means the class was specified in an OpenClsid setting, and COM object creation becomes a more complicated process that involves the Sandboxie service. O means object creation was successful. X means it failed. There is no security risk.

You can additionally turn on ClsidTrace=ad to trace (in DebugView) requests on any "open" COM objects.