Sophos Central Endpoint and SEC: Computers fail/hang on boot after the Microsoft Windows April 9, 2019 update. Please follow knowledge base article 133945
Learn about the Benefits of Multi-Factor Authentication (MFA). Turn your MFA on now!
We'd love to hear about it! Click here to go to the product suggestion community
Sandboxie 5.30, Windows 10 Pro 1809.At Windows 10 Pro 1709 and earlier versions, when from inside any sandboxZ you run from a batch script " ...Sandboxie\Start.exe /box:sandboxY c: ", it will open in that sandboxZ a windows explorer at c:\ But now that I upgraded to 1809 it does nothing. I use this approach so some files always open sandboxed but if I try to open them while alreade inside a sandbox I cannot open them anymore.
I tested the behavior and it works fine for me on Windows 1809 + Sbie 5.30, this is my exact command:"C:\Program Files\Sandboxie\Start.exe" /box:Y c:
If you need to invoke a different sandbox, then either run the command outside Sandboxie, or run it directly from the desired sandbox. You cannot invoke a sandbox from within a different sandbox. (I also tested on 1803, and the behavior is the same, which is expected)
If you are still experiencing problems, please provide all of the required info so that I can further test:How to report problems with Sandboxie
In reply to Barb@Sophos:
Hi Barb@Sophos thanks for the reply. Actually you are right I apologise, before posting I did a fast check with that simple command from the shell and apparently I must missed the popup window. But the changed behavior with my implimentation exists.I use a .bat file to open some files sandboxed.I checked it more and the problem seems to be because of the registry entry and not relative to the start commandA very simple example. Saving the command from the previous post in c:\x.bat fileChange registry so all files at right click will have the option to run the x.bat:[HKEY_CLASSES_ROOT\*\shell\Test][HKEY_CLASSES_ROOT\*\shell\Test\command]@="C:\\x.bat \"%1\""If you right click any file and choose Test it works as expected and opens an explorer in the sandbox mentioned in x.bat. But if you try to do the same from inside a sandboxed explorer it does nothing. It makes no difference whatever is written in x.bat even non sandbox related commands
In reply to Argos A:
The steps you provided do not work for me, I get a permissions error when I right-click on a file and try to invoke the x.bat via the newly added shell command. So I switched the location of the bat file to my Desktop, and switched command key to absolute path to desktop (this allowed right-click shell command to work).
I tested both Sandboxie 5.28 and 5.30 and the shell command did not work inside either. However, running the bat directly does work from a Sandboxed explorer. How are you making it work on 5.28? Please provide specific steps.
I've made the devs aware. I'll update this thread if any new info becomes available.
Yes it works for me as well if I try to use the bat from inside a sandbox that's why I assume it has to do with registry entries maybe in regards with bat files?
It's the same with 5.28. Before upgrading to Windoes 10 Pro 1809 I was using 1709 so I'm not sure at which version of Windows this behavior changed.
Actually I used for a very short time 1709 so it is possible that I didn't notice a change there but for sure in Windows 10 1703 and earlier it was working
Thank you for your time
I noticed that in this version of windows 10 (1809) when using the windows start.exe command, if you add quotes to the filename, it is not working the file does not open. For the file to open you must skip the start commenad (at a shell or batch file), if the implementation to open a file with the default progam under sandbox makes use of the windows start command then this might be the reason it is not working.
If you can provide a couple examples to test (what works, what doesn't), I will be happy to do so and report it to the devs.
Let's say a file named 1.txt. It can be opened from cmd or batch file with start 1.txt but not with start "1.txt" which was the way files of any type were opening before (and this can be an issue if you have filenames with space or other special characters). Now you just write the file name and it triggers its opening with the default program for its type for example just "1.txt" at cmd will open the file with the default text editor.
That is what is happening when using cmd or run a batch file, powershell works the way it used to be for cmd before. With powershell the correct approach is start "filename". I don't know if cmd (or batch files) are used in sandbox implementation, if they do that might be the reason behind the issue I mentioned
I see the behavior, I am not sure this affects Sandboxie, other than the obvious (you'll have to use commands without quotes).
I've made the devs aware and I'll update this thread if they provide any additional information.
I had the time to check it a little more yesterday, the problem must be because of an implementation of start.exe in a cmd shell or something similar, when I removed quotes from the registry command value (the string to run for opening the files) it started working inside sandboxes as well. This is not an issue in sandboxes if the the command is the usual with exe file so I guess it has to do with how the registry opening commands are handled by sandboxie since out of sandbox both bat and exe files are working fine with the quotes.Running without quotes obviously cannot work if you try to open a file that includes special characters like space. There is a workaround, removing quotes from registry entry and modifying bat files so to include the quotes there (using "%*" instead of %1)The workaround won't work in case you try to open at once multiple files of the specific type having special characters. Can you pls update me if there will be a fix for this or I should apply the workaround by modifying bat files and registry valuesThanks
I'll pass the info to the devs and update this thread if they provide any updates.