Data Execution Prevention in Windows supposedly is a line of defense against malicious code by "by monitoring your programs to make sure that they use computer memory safely". However, I also know for a fact that not all programs are made for DEP, and crashes and other problems can result if a "safe" app is blocked and deemed as unsafe.

In the DEP settings panel (screenshot below), I have the ability to enable this service for all the programs installed on my computer.

enter image description here

Does DEP really work in protecting against exploits (let's assume that I already have a good AV and firewall), or it is just not worth the compatibility risk?

  • 1
    The linked SX post says nothing, that I see, about DEP ensuring that malicious code does not access system memory. This is an inaccurate understanding. Further, DEP does not protect against Viruses at all (that is an AV's job). DEP is intended to protect against exploits, in particular, by trying to protect your system from starting to execute malicious code in the first place.
    – antik
    Feb 23, 2014 at 1:10

1 Answer 1


To understand what DEP does, you first need to know a little bit about how memory is laid out in a process. The key concept is that code (instructions the CPU can execute) and data (stacks and objects) exist in separate areas of memory. User input, files, program data, etc. all live in the data areas of memory.

DEP allows this separation to be enforced by marking the code pages in memory as "executable". By similarly NOT marking data pages, the processor can now recognize when a region of memory is intended for CPU instructions and when it is not. As a protection, the CPU will fault, allowing the OS to terminate the process when DEP is enabled and the processor finds itself trying to run code from data memory.

In summary, this means that a user cannot simply input data containing executable code and, through a vulnerability, point the processor's instruction pointer to that data, and begin executing code, as was previously possible before widespread DEP adoption.

As a security mechanism, this is one strategy to mitigate an exploit running arbitrary/malicious code on a system. However, modern exploits are typical able to defeat DEP.

I've not encountered a program that cannot handle DEP, ever, and I've had it enabled since it was first offered in Windows XP SP2. That's not to say that there aren't programs that might be disrupted by it but modern programs, even immensely complex ones like web browsers, are able to operate when DEP is enabled.

Given hardware support for DEP as indicated in the screenshot above and widespread modern application support for DEP (as well as more advanced mitigations like ASLR) you shouldn't notice any performance differences with DEP enabled and there's some additional security provided over having it disabled. Given this, I see no point in running DEP for system services only: there's no harm in running it for everything. If you encounter something that is crashing due to DEP, you could add that individual program to the blacklist though I'd also consider finding a product that's more current and I'd absolutely not allow an Internet facing application to run without DEP (and all other available exploitation mitigations) enabled. I'm not aware of risks caused by enabling DEP globally: I'd assert that your accepting risk by not doing so.


You must log in to answer this question.