An interesting conflict with an unsandboxed application...
Windows 7 64-bit and 32-bit
Sandboxie 4.01.04
Chrome 26.0.1410.43 stable forced
EditPlus Text Editor 3.51 unsandboxed (http://www.editplus.com/):
Steps to reproduce:
1. Install EditPlus and set it as the default handler of .txt files (which requires running EditPlus with admin rights).
2. Start Chrome sandboxed.
3. Navigate to any text file and double-click to open.
I am seeing a 30-second hang on 7 64-bit (20 seconds on 7 32-bit) before EditPlus opens the .txt file on the screen. If I start Chrome unsandboxed, no hang.
During the hang, the EditPlus process is not listed in Process Explorer until the .txt file is on the screen. If I close the sandboxed Chrome during the hang, EditPlus opens the file immediately.
Other text editors (Notepad++, UltraEdit) are unaffected. No hang with Sandboxie 3.76. No hang with previous Chrome stable versions and Sandboxie 4.01.04. Other than Sandboxie, EMET (3.0) is the only other security app I use.
[.06] Sandboxie 4.01.04, Chrome 26.0.1410.43, and EditPlus
I should have been more clear with Step 3. Navigate to and open a .TXT file using an unsandboxed windows explorer. That's what is weird about the problem. It's an operation that's external to the sandboxed Chrome.tzuk wrote:How do I get Chrome try to open the .TXT file in an external viewer?
You need to tick off "Associate in Explorer" and then click Apply which requires admin rights...tzuk wrote:Also, I did not see how to ask EditPlus to handle .TXT files from within EditPlus, so I used the Default Programs feature in Windows, but I guess either approach should have the same result.
Nick
Who is online
Users browsing this forum: No registered users and 1 guest