Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

After installing a disk encryption tool, Data Execution Prevention (DEP) starts killing the Spooler Subsystem. This is a known issue with this encryption program and the fix is to set DEP to run on all programs except those I specify. So I make this settings change and specify the Spooler Subsystem to be ignored by DEP. But DEP still kills the Spooler Subsystem even after reboot.

I've disabled and reenabled DEP. I've disabled it completely using the NoExecute=AlwaysOff option in the boot.ini file. On every other computer I've had this issue with the prescribed option fixes the problem.

But DEP won't die! Why, oh why, won't DEP die?


  • Windows XP sp3 - Fully patched
  • Hitachi Hibun disk encryption
share|improve this question
if this would normally work, but doesnt, what is the possibility that the one computer it doesnt work on has another problem, a virus or faux spooler hiding thing , some weird mabey even unknown evil that is being missed? In that situation things not working could be a blessing in desguise. – Psycogeek Nov 11 '11 at 2:08
What makes you sure that DEP is killing the spooler and not just a bad printer driver (etc.)? – Ƭᴇcʜιᴇ007 Nov 11 '11 at 2:40
The fact that there are no printers installed (besides the default WinXP and Office 2010 ones) and the message that shows up is the Data Execution Prevention message, not the "A program has encountered an error and has to close..." message. – music2myear Nov 14 '11 at 15:03

I would suggest turning off physical address extensions as DEP relies on this to work. Here is the KB article from microsoft. Basically you add:

/execute /NOPAE

to your Boot.ini file. I know this isn't exactly a "fix" but this work around should turn off DEP by turning off what it relies on to work.

share|improve this answer
I modified this per Windows XP to /noexecute=alwaysoff /NOPAE per the KB article. But no difference. DEP reports disabled in System Properties, but it is still killing the Spooler Subsystem. – music2myear Nov 10 '11 at 22:58
If PAE is off there is no possible way DEP is getting in your way... are you sure it's not something else? – Not Kyle stop stalking me Nov 11 '11 at 17:10
I'm pretty sure there's some sort of disconnect between what I'm telling the computer to do and what it is actually doing. For whatever reason, after disabling PAE and telling DEP to /alwaysoff, it's still running. I assume this means some sort of OS corruption or something like that. I'll just have to reimage. – music2myear Nov 14 '11 at 15:00
up vote 1 down vote accepted

We have the following specifics to our system deployments that appear to play a part in this issue:

  • With Office 2010 we determined that completely disabling DEP is necessary. This was determined by higher-ups in the IT organization and I have not had the time or resources to investigate why this is so. At this point it's a given.
  • We install a disk encryption package call Hibun, which is older, and which has known issues with the Print Spooler Service. The work around was set the DEP settings to scan everything except those programs I manually selected and then to add the Print Spooler Service to the list of exceptions. This process originates before the Office 2010 full-disable of DEP.

The problem occurs when we put this requirement and this workaround together in the presence of the disk encryption.

The problem is repeatable: a completely fresh install, fully patched, results in exactly the same behavior at exactly the same point.

The behavior appears to be that, despite being told to be disabled both on an OS and BIOS level, DEP continues to run when the Disk Encryption is installed, and it continues to cause grief when it encounters the Print Spooler Service.

The solution was to turn off the Print Spooler Service.

We are in a networked environment where jobs are spooled by the Print Server, and so a local Print Spooler Service is not necessary. I have tested printing with the local Print Spooler Service disabled and it appears to work OK. The only issues may occur if the person attempts to print to a printer besides those in the office, which is not a great concern as that is implicitly disallowed by company security policy.

It is not the best solution, it's not an elegant solution, it's not even a particularly good solution, I just don't have time to spend on a better one. And so long as the user does not try to print work files from home (which is a huge no-no anyways) they should not experience any bad behavior from the computer.

Murglefrump! I hate poor solutions like this. But hey, I'm moving on to a different company soon that will be a bit more open when it comes to IT policy, and I'll have good deal more responsibility and be able to spend time finding true fixes and have to settle for fewer paste and sticky tape type solutions.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .