DepTest can serve as a second opinion on the state of Windows® data execution prevention (DEP) feature to see if the intrusion prevention feature is really enabled and protecting all running processes and services, if you have a look at threads like this one for example. Installing Microsoft's EMET may also be very helpful to investigate the system's configuration. You can find more information about why we recommend to enable AlwaysOn and how DepTest works internally in this thread on wilder security.
The tool was developed around 2002, around the same time as Sys-Manage BufferShield, to demonstrate that Microsoft's software based data execution prevention explicitly protected from one specific exploit that occurred one time only and was based on overwriting the pointer to the SEH Exception Handler. So giving this software based feature a similar name as the hardware NX protection was confusing the customers globally and stimulated a false sense of security. It also showed, that Comodo Memory Guard (shortly afterwards discontinued) was not effective at stopping buffer overflows, because it used a user-mode based approach (hooking up Windows APIs) instead of a lower level kernel-based approach through a driver. Initially they claimed on their forums, that our test is only executing a NOP, until we used some real shell code creating a file, bypassing the Windows API and using the call gate mechanism to directly invoke the kernels NtCreateFile API (There is many other ways of not using the Windows API and bypassing such a protection in shell code). [We still like Comodo's certificates!]
We don't support and develop BufferShield for any newer Windows versions than Windows XP and Server 2003 any more, because these operating systems ship with NX and ASLR protection right out of the box. You just have to take care of enabling them properly. The same applies to modern CPUs, which all have hardware based NX (or XD in case of AMD), so there is no more need to port it to newer operating systems that would not run efficiently on such old CPUs anyways.
If your computer should fail, please run the following command to enable NX (Intel) or XD (AMD) using the following command line in an administrative command prompt on Windows Vista and newer operating systems and repeat the test after rebooting:
bcdedit /set nx AlwaysOn
This will enable buffer overflow protection for all applications and services running and not just only the operating system. It also prevents smart shell code from using a so-called return-to-libc method to disable NX/XD in case ASLR fails or is broken. If you should encounter compatibility problems with certain 3rd party applications, please try to update them or contact the manufacturer / vendor. After more than 15 years, they should know that it is not a good practice to execute code from memory pages that have not been flagged for code execution.
You can get back to the default setting by running the following command in an administrative command prompt:
bcdedit /set nx OptIn