Hi, i just wanted to report a commonly occuring problem I have been experiencing with all the beta versions after 3.42, it takes two or three times to click the run file explorer sandboxed for it to open. What usually happens is that start.exe appears to initiate then nothing opens after that... its just listed as running int eh sbie control

I have an idea what that might happen but I need you to experiment a bit. Make sure that no program at all is running in the sandbox, and then run Windows Explorer sandboxed. Does it work flawlessly in this case? And if you repeat the experiment several times, always making sure to start with a sandbox that has no running programs, does it always work well?

Let me explain my idea. It is that once you stop the last program, SandboxieRpcSs/DcomLaunch begin sandbox shutdown process that sometimes take a few seconds. Now if you happen start Windows Explorer within these few seconds, this might cause the problem. So your experiment will help clarify the situation.

beta 3.43.15

Defaultbox, with only LUA enabled, auto delete in place
Observations
With a box with no running processes and just initiating file explorer then closing it, then repeating for many times.. The problem does not appear to be present.

With the box running the browser for a while, then initiating file explorer it doesn't come up. All that is present, is the start.exe running and thats it. I'd also like to note that this seems to happen rather frequently but intermittently. After closing the browser down start.exe fails to terminate and hence stays running in the box. To get it to auto delete, I have to manually terminate processes.

the screencap of the sandboxie conrtrol after closing down the chrome browser afterwards

Oops - scratch that...; after more testing with defaultbox, nothing running and only starting windows explorer , I get the same problem so it does occur.

Alright, when this problem happens, how long do you wait for Explorer to appear? Have you tried waiting say, 30 seconds?

I waited much longer (many minutes in fact) than that but it never appears... its stuck at this point and thats it.

leaving the start.exe running in the background causes a constant CPU hike in activity at 100% constantly (with nothing else open but chrome), until this process is terminated. This would thn make it drop to 1-7%

I can confirm that the problem still occurs on beta 3.43.16. After downgrading back to 3.42 everythign is fine again. I hope my decription os helpful to you in regards of finding the problem.

Can I ask you to try to attach a debugger to Start.exe and produce some information about what it is doing? I've written the steps to follow here:

http://www.sandboxie.com/index.php?HowToUseWinDbg

You should do scenario 2. These instructions are fairly new, and I tried to make it easy to follow, but feel free to comment on it if you think things are hard to follow and I will revise the text.

Don't feel obligated to do this, you can skip it if you're not in the mood. But if you do this, then please make sure to use version 3.43.17.

the description is pretty good, but Im confused as to how to attach the debugger to start.exe specifically. Personally, I would prefer a way to do this from having the debugger installed inside the sandbox as I dont want it to leave junk on my sys. . So is there a way I can do this?

PS - The problem occurs much less frequently woth version 3.43.17, But it still occurs to an extent. Another small observation is that processes take longer to terminate in the latest beta version than 3.42

Yes, you can install the debugger into Sandboxie, and then use Run From Start Menu to run it. From the debugger, use F6 (Attach to Process command) then select the problematic instance of Start.exe. You can find the process ID number for that instance of Start.exe, by looking in Sandboxie Control.

Im sorry for not correctly following instructions the first time (had never done this b4), but I believe everything was done right this time. I installed 3.43.18 and still exhibits the same problem

windbg log:


snipped. --tzuk

Thanks RSecure, this log certainly illuminates the problem. I will release version 3.43.19 soon, and I hope you will see an improvement.

Lookin good I can confirm tht there are no more explorer problems with 3.43.19 . you are certainly a master of ur trade trade, well done Tzuk!!