Why do you all those OpenIpcPath lines in the new test sandbox? The idea is to use just the default setings. Admittedly these OpenIpc lines probably don't make much of a difference, but it shouldn't to try without them.

You can put asterisks anywhere in the line, not just at the end, so something like C:_Users_*_AppData_Local_Microsoft_Windows_* is fine.

Earlier I asked you to look in the sandbox folder and see if you find any file that looks like it has to do with printing. Now I want to ask you to do the same with the registry. After a printing attempt, make sure there is something still running in the sandbox, so you can access the registry of the sandbox. Then start RegEdit (from the Windows Run command for example) and expand the HKEY_USERS key to find a Sandbox_RonC_sandboxname key. Then look in this key to see if you find anything that looks related to printing or to HP.

These lines were added one by one, as successive runs of the Resource Access Monitor kept showing another line preceded by an "X".

I'm not very experienced with interpreting the Monitor's output, and so was guessing the objective was simply to get rid of the "X" marks. Again, just guessing, and likely incorrectly! So I just kept on going until all the 'X"s were gone.

When you say, "use just the default" you're referring to the "HP Universal" setting, I assume? And you're saying it really should be working with this option set, alone?

And ... if the original string already terminates with an "*" then, we should make it end with "**", or does the original single terminating asterisk serve also as the wild card?

Thanks for giving me the next step!

Sorry for the delay in responding, but I had to do some work that required printing from a browser, and that meant going back to Windows 2000 Pro, temporarily (where everything still works ). Later today or tomorrow I'll return to more troubleshooting. I'm looking forward to seeing everything eventually working together in Windows 7. Your help in doing this is greatly appreciated!

Regarding the monitor output, I wouldn't say the object is always to get rid of the all the X's. Some X's are to ok have. And sometimes you need to identify resources that don't show with either X or O and add them so they show up with O. It's difficult to formulate specific rules, it's more of a trial and error process.

As for default settings, I mean just "Create New Sandbox" and leave it at that, the new sandbox will have default settings and nothing more. It's true that some settings come in from the global Software Compatibility rules, but we can usually ignore those.

Regarding wild cards, the one in the middle doesn't negate the one at the end. If you want to say something like, "a sequence of characters that looks like this and has a bunch of unknown characters in the middle and a bunch of unknown characters at the end" then you need a wildcard in the middle and one at the end. Basically if you were to describe the setting in words, where you say "a bunch of unknown characters" is where you need to put a wildcard.

And thank you for putting up with this. I too hope we end up with a way to solve this problem.

Unfortunately, no.

I finally got to test the TestBox configuration for printing from WordPad, MS Internet Explorer and Firefox, with all three sandboxed.

Unfortunately, none of the programs will print correctly. Job still accumulate in the spooler, until dislodged the the manner previously noted. When one is dislodged, then the remainder follow, automatically.

I have all of the new rules in sandboxie.ini, the 'HP Universal' Printer Driver is also checked.

Any other ideas?

I see we are working at the same time.

After checking the Windows Registry location you described, I began randomly browsing adjacent entries and came across this:



Looking only at the very beginning and the very end of the data for each entry, I suspect they are very close, probably identical.

Have you ever heard of anything like this? There's no evidence from the Device Manager listing that the driver is installed twice. There's only one entry, "HP Deskjet F2100 series".


Regardless, I wonder ...

Unless you tell me it should be this way and changing it would cause a problem, I'd be inclined to delete the second, that says 'copy'. However, I would rather ask someone of greater experience, first, before tossing things out of the Registry!

______________________________
P.S.: I just noted, the same double-entry is in the key below this one,
HKEY_USERS\S-1-5-21-3231957836-1568948063-4179975120-1000\Printers\Settings
P.P.S.: This is apparently a very old Registry Key and I wonder why HP is using it once, let alone twice. The link says it's for 16-bit applications.

I don't think you should mess with anything outside the sandbox.

How about if you add a wildcard (i.e. a single star) in Resource Access > File Access > Full Access?

When you do this, I suggest you check with just your text editor, or an equally simple program, then revert the setting. Because this setting means no files will go into the sandbox, all files will be accessed directly outside the sandbox.

I used the 'TestBox' for this, and the job still sticks in the spooler.

When I saw that, I put a wildcard also into the Registry Access, but now I'll take both out. Didn't help. Hope that was OK??

After this, the first item or second, I'm not certain, I temporarily lost my ability to remove items from the spooler by printing from an unsandboxed program. However, after a System Restore, things are working as before.

[Edit]This sounds unexpected and strange. Perhaps I should see if I can duplicate this result.[/edit]

Any other ideas?

OK, it seems like resource access may not have something to do with this.

I installed the HP All-In-One driver for the F2180 printer series in a test computer where the printer isn't actually installed. This causes print jobs to hang in the queue and this same hang happens whether the printing program is in the sandbox or outside the sandbox.

However, I see two major differences between my Resource Access Monitor log and yours.

You have a bunch of HP printer DLLs loading into the sandbox:


I don't see this. On the other hand, my log shows a few resources related to printer access, which don't show in your logs:


So something seems to be different in the way printing works in your computer and the way it works in my test computer (and in my real computer for that matter). I don't know how to explain this difference.

* * *

But playing around I noticed an option to bypass print spooling and send the print data directly to the printer.
Perhaps it will make a difference for you. Please try this:

Start menu > Devices and Printers > Double click on your printer > Customize your printer > a dialog box opens
In the dialog box, select Advanced tab, then in the middle of the window, select - Print directly to the printer

This is what happened when I bypassed the spooler -- is that the effect you're trying to explore, with "Print directly to the printer"?



With your knowledge of how Sandboxie works, most likely this means something, so let me know what to try next!

I'm sorry, I missed the part where you said you already tried bypassing the spooler.

Do you see splwow64.exe processes start to run when you print?

Please use a utility like Process Explorer from Microsoft:
http://technet.microsoft.com/en-us/sysinternals/bb896653

Review the list of processes before printing from Firefox that is NOT running in the sandbox.
If there are any splwow64.exe processes, end them. (The "Kill Process" command in Process Explorer.)
Next try to print something.
You should see the process splwow64.exe start -- please double click it and note the "command line" field in the first tab of the properties window.
Then end the splswow64.exe process again.

Repeat the same thing with a sandboxed Firefox.
Do you see splwow64.exe process start? It should start outside the sandbox. What is its command line?

No problem at all -- you are keeping track of many threads, and I am looking after only one!

Yes, Mark Russinovich's Process Explorer is one of the first utilities I added, so no problem there.

I will get busy on this, but first let me ask: I note the '64' in the name of the executable. I neglected to specify that I am running Windows 7 32-bit version.

I thought it best to note this as soon as possible, in the event it's significant. If this changes anything, please let me know. Otherwise, I'll proceed as directed and report what I see.

Ah... Once again I apologize for missing important information.
You're right to point out the 64, there is no splwow64.exe in 32-bit Windows.
Let me try to install the 32-bit All In One package on a 32-bit test system and see if that shows my anything interesting.

I tried the same thing on a 32-bit Windows 7 and I basically see the same thing. Without an actual printer, jobs get stuck in the queue whether or not the printing program is inside the sandbox. I do however see a resource log that is simiar to what you've been posting.

I went to that printer properties dialog and changed the port from LPT to FILE. Printing this way does seem to sucessfully create an output file. Can you check if that also works in your computer?

Hi Tzuk, back again.

Yes, what you requested I try did work, with the printer turned on and a text-editor sandboxed. I saw the Print Preview window.


Then, I went a bit beyond what you requested, in the event it might be helpful. If not, please disregard the following.

Having achieved success with getting the Preview to appear, I tried printing normally (that is, not to a file).

I turned the printer's power off, to simulate your set-up, and the result was erratic: first the print jobs remained in the queue. Turned the printer on, as I know in Windows 2000 when I forget and try to print with the printer off, turning it on will make the spooler resume normal operation. But not this time.

Then I turned the printer's power on and tried it again. This time there was a long delay, and the text-editor crashed, and Windows asked if I wanted to terminate the program. I said yes, the editor terminated, and then after another delay, the Print Preview page appeared, for the job I was attempting to print, just before the text-editor crashed.

Additional bit of information: the problem may be intermittent. I had never noted this before, but as you know, there have been a few days delay since our prior session. Just to see what would happen, I tested to see if I could go as far as far as the Print Preview, in the browser as I was using it to find the forum. Again, this was at the very beginning of my test session.

With the printer power turned on, three times, I simulated printing (to paper, not to a file) the forum page by going as far as the Print Preview, and then hitting 'Cancel'. It worked three times, just as if it were unsandboxed or running sandboxed in Windows 2000, and then it resumed failing. Before the failures resumed, I suspect the job might have been sent to the printer, had I selected 'Print' instead of 'Cancel' on the print preview window.

Your thoughts and suggestions are appreciated!

I just now rebooted and returned to the text files and the browser to see if they would work, now. That may have been a false alarm. The Print Preview again fails to appear ... so I can't duplicate what I (thought I?) saw.