I'm trying to add CSCRIPT.exe as an exception to DEP (Data Execution Prevention) in Windows Server 2008 R2. CSCRIPT.exe lives in two locations: C:\Windows\System32 and C:\Windows\SysWOW64. The System32 location is the 64-bit version of the application and 64-bit applications cannot be added to DEP according to Microsoft (and the warning message I get when trying to add it to DEP.) Trying to add the SysWOW64 version gives an entirely different error/warning message. "This program must run with DEP enabled, you can't turn it off".

I've tried renaming and moving CSCRIPT.exe to a different location and/or renaming it with no difference. For this use case DEP must be enabled and for the purposes of this specific question - I need to disable DEP just for this application.

One thing I did try was to use the CSCRIPT.exe from Windows Server 2003. I'm able to add this file to DEP successfully. However, something really bothers me about using the old version. I feel like I could be introducing a security risk or a version issue.

Is there a different method I could use to get the SysWOW64 version of CSCRIPT.exe into the DEP list? Or is the Windows Server 2003 version workaround a suitable fix?

EDIT: I understand that something may need to "give" with this particular question. I might not be able to get to common ground. If that's the case, so be it. I don't want to spend the time and effort to reinvent the wheel if its unnecessary. Thanks!

  • 1
    I'd like to backtrack and ask what you're trying to fix? – Dan Sep 19 '13 at 14:28
  • CSCRIPT.exe is being used as a go-between to execute *.VBS files. I have an application that centrally manages different database accounts. For a few specific accounts such as in Oracle (using their EM CLI) I need a file to act as a translator for commands and variables that are sent between my application and Oracle's CLI. VBS & CSCRIPT is the way that's been used. Changing this method would be ^prohibitively^ expensive and time-consuming. – Ben Campbell Sep 19 '13 at 14:40
  • 1
    I'm surprised it is cscript itself and not something within the VBS that is causing DEP to whine. Just never seen a case where cscript or wscript caused DEP issues. – TheCleaner Sep 19 '13 at 15:05
  • Thanks for your comment. I'm really feeling stupid now - I need to go back and check into this from a different angle. I'll update the question if necessary. Thank you. – Ben Campbell Sep 19 '13 at 15:10
  • 1
    I'd be VERY surprised if CSCRIPT.EXE or WSCRIPT.EXE itself causes any DEP exceptions, especially considering it's bundled and supported in all Windows distributions, including Datacenter edition. However, if it's referencing 3rd party DLLs / objects that aren't DEP safe, that's a different matter. If the 3rd party can't provide a DEP safe version of code, it's pretty bad news. – Simon Catlin Sep 19 '13 at 20:21

Very interesting question. I've seen some DEP faults from cscript.exe before. It's annoying.

VBScript predates DEP in Windows, and as such it was not originally developed with DEP in mind. Furthermore when you start interacting with old, third-party COM and OLE interfaces in your scripts, they can cause NX faults and cscript.exe takes the blame for it. The latter is usually the case.

However, something really bothers me about using the old version. I feel like I could be introducing a security risk or a version issue.

It's a little funny to me that you would say that, because disabling DEP for a program like cscript.exe is going to be way more of a security risk than using the 2003 version.

You can't disable DEP for 64bit processes, period.

For the purposes of application compatibility when DEP is set to the OptOut policy level, it is possible to selectively disable DEP for individual 32-bit applications. However, DEP is always enabled for 64-bit applications.


So that leaves you with the 32bit, "SysWOW64" version of cscript.exe... however, modern executables can and usually are flagged with a "you can't turn DEP off on me," flag. Much like in the same way that an executable can be flagged as being large address space aware, etc.

Technically, it's the /NXCOMPAT flag that the executable was compiled with. It's a linker switch. The old 2003 version of the executable was not compiled with that switch, and that is why you are able to put it in the DEP exemptions list but not the 2008 version.

But wait there's more! If you still want to use the 2008 version of SysWoW64\cscript.exe, all you need to do is copy the executable, then run:

editbin /NXCOMPAT:NO C:\cscript.exe

Now you can add it to the DEP exemptions list. Editbin.exe comes with Visual Studio, the Windows SDK, etc.

Have fun injecting code on stack or heap memory and branching the instruction pointer to execute it!

  • This is exactly what I wanted. Thanks for the knowledge. – Ben Campbell Sep 23 '13 at 14:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.