I had set up a task to trigger on boot, then repeat every 5 minutes. To my disappointment, running the task did not start the "repeat" functionality. Rather than reboot, I added another trigger to start it "one time", then repeat every 5 minutes. My question is whether the repetition on the one-time task will cause it to restart after boot, giving me two repeating instances of the task after a reboot -- one from each trigger? Or will the "one time" trigger be ignored on reboot, giving me what I desire -- a single, repeating task every 5 minutes.
I need a small postscript file that causes a printer error to test an application I'm writing to help manage printer queues. Rather than experiment with various combinations of postscript code to create one, I thought I'd ask if anyone has such a sample available. I've googled to no avail and am turning to the ServerFault community as a last resort before I begin experimenting.
Also, it needs to error in such a way as to cause a printer error -- not be silently ignored.
We're trying to diagnose an issue where AfdP usage continues to climb until it hits a maximum and the system hangs due to lack of non-paged pool memory. We're working with a third-party application that runs under the Java VM and does a lot of network-related activity (print accounting). Any tips on how we can narrow down where the problem is coming from so that we can feed this back to the vendor? Even if we could just definitively pin it down to this application, that would be helpful. Right now, we're in the phase where the vendor is being very helpful, but doesn't think it could be their application. Nothing much else is running on the box and we did a recent upgrade of their software only after which did we see the problem, so it seems highly likely it's the culprit but we only have circumstantial evidence at this point.
Update
Some research by the vendor turned up a Windows 2003 bug which seemed to be triggered by a switch in the vendors code from blocking to non-blocking network I/O. The vendor was willing to change the code to let us switch back to blocking I/O, but we opted to move forward and transition the service to a Windows 2008 box. The bug seems to have been fixed in Server 2008.