Data Execution Prevention with Windows Vista

[Guest]

So it appears that many of us are having issues with the Data Execution
Prevention (DEP) feature with Windows Vista. I have found that programs that
were closed due to the feature still closed even when I turned the feature
off through the run command. Does anyone have any updates regarding this
problem which will work for all or even most programs? It is very time
consuming to deal with this issue on a program by program basis as Microsoft
has suggested...especially when all my programs are Vista compatible and even
Internet Explorer sometimes closes due to the feature. Any information other
than turning the feature off, adding it to the dep-exception file, and
physical violence against my pc would be greatly appreciated.
www.mikeyllo.com

 

[Andrew McLaren]

Hi Mickey,

I haven't heard of DEP causing really widespread problems, although
obviously you are seeing problems on your machine. The exact behaviour could
vary depending on whether your CPU supports hardware DEP (the NX bit) or
software DEP - which is actually a different form of operation. AMD and
Intel EM64T Processors support hardware DEP; many (most?) 32-bit Pentium IV
processors do not.

Well-behaved programs, which keep a strict separation of data and executable
code, should not be affected by DEP. Programs which are affected by DEP may
contain security vulnerabilities, because malicious code could be injected
into the data portions, and then executed.

But I'm curious when you say "programs that were closed due to the feature
still closed even when I turned the feature off through the run command". If
you have applications which are shutting down even with DEP disabled, then
DEP is probably not the culprit. How do you use the "run" command to disable
DEP? Did you do a:

"bcdedit.exe/set {current} nx AlwaysOff"

and then reboot? That would disable DEP globally, for all applications. If
your apps still close after this, the problem is not DEP. Are you still
getting the "DEP - Windows has closed this program" dialogue box?

You can verify whether Hardware DEP is actually available on your system by
running this command:

wmic OS Get DataExecutionPrevention_Available

If it returns TRUE, the CPU supports DEP. To find the current DEP policy
which is active, run the command:

wmic OS Get DataExecutionPrevention_SupportPolicy

The result will be one of:

0 AlwaysOff - DEP is not enabled for any processes
1 AlwaysOn - DEP is enabled for all processes
2 OptIn - Only Windows system components and services have DEP applied
3 OptOut - DEP is enabled for all processes. Administrators can manually
create a list of specific applications which do not have DEP applied.

"2" is the normal default setting. Apps which aren't part of Windows itself,
should not be affected.

You might want to run this to test if DEP is , indeed, active on your
system.

Overall, I don't think it's a problem which can be easily solved by an
update from Microsoft - apps which execute data are a security risk and need
to be re-written, or at least recompiled with a /GS flag. But Microsoft
might add compatibility shims for certain well-known applications - these
are updated via Windows Update as they are released.

 

[Ian Betts]

Hi Mickey,

I haven't heard of DEP causing really widespread problems, although
obviously you are seeing problems on your machine. The exact behaviour
could vary depending on whether your CPU supports hardware DEP (the NX
bit) or software DEP - which is actually a different form of operation.
AMD and Intel EM64T Processors support hardware DEP; many (most?) 32-bit
Pentium IV processors do not.

Well-behaved programs, which keep a strict separation of data and
executable code, should not be affected by DEP. Programs which are
affected by DEP may contain security vulnerabilities, because malicious
code could be injected into the data portions, and then executed.

But I'm curious when you say "programs that were closed due to the feature
still closed even when I turned the feature off through the run command".
If you have applications which are shutting down even with DEP disabled,
then DEP is probably not the culprit. How do you use the "run" command to
disable DEP? Did you do a:

"bcdedit.exe/set {current} nx AlwaysOff"

and then reboot? That would disable DEP globally, for all applications. If
your apps still close after this, the problem is not DEP. Are you still
getting the "DEP - Windows has closed this program" dialogue box?

You can verify whether Hardware DEP is actually available on your system
by running this command:

wmic OS Get DataExecutionPrevention_Available

If it returns TRUE, the CPU supports DEP. To find the current DEP policy
which is active, run the command:

wmic OS Get DataExecutionPrevention_SupportPolicy

The result will be one of:

0 AlwaysOff - DEP is not enabled for any processes
1 AlwaysOn - DEP is enabled for all processes
2 OptIn - Only Windows system components and services have DEP applied
3 OptOut - DEP is enabled for all processes. Administrators can manually
create a list of specific applications which do not have DEP applied.

"2" is the normal default setting. Apps which aren't part of Windows
itself, should not be affected.

You might want to run this to test if DEP is , indeed, active on your
system.

Overall, I don't think it's a problem which can be easily solved by an
update from Microsoft - apps which execute data are a security risk and
need to be re-written, or at least recompiled with a /GS flag. But
Microsoft might add compatibility shims for certain well-known
applications - these are updated via Windows Update as they are released.

I am always surprised when people use the command line to change settings,
when Vista has an easy system built in. In Advance System Settings. Here you
can turn DEP off on all programs or just those you choose to run without
protection.

I find it worth looking at only when I find a consistent problem with a
program.

 

[Andrew McLaren]

I am always surprised when people use the command line to change settings,
when Vista has an easy system built in. In Advance System Settings. Here
you can turn DEP off on all programs or just those you choose to run
without protection.

Hi Ian,

With respect, I have to disagree with you. The Advanced Systen Settings GUI
provides 2 options:

a) Turn on DEP for essential Windows Programs and services only
or
b) Turn on DEP for all programs and services, except those I select:

In other words, this allows you to select DEP Policies 2 & 3 from the list
of 4 possible policies (0-3). If you want to turn DEP off altogether, you
*must* use the command line - there is no GUI option for that.

I was suggestiing the OP could disable DEP completely, and verify that his
applications run reliably in that environment. If they still encounter
problems then DEP is not a factor.

Regards,

 

[Ian Betts]

Hi Ian,

With respect, I have to disagree with you. The Advanced Systen Settings
GUI provides 2 options:

a) Turn on DEP for essential Windows Programs and services only
or
b) Turn on DEP for all programs and services, except those I select:

In other words, this allows you to select DEP Policies 2 & 3 from the list
of 4 possible policies (0-3). If you want to turn DEP off altogether, you
*must* use the command line - there is no GUI option for that.

I was suggestiing the OP could disable DEP completely, and verify that his
applications run reliably in that environment. If they still encounter
problems then DEP is not a factor.

Regards,

Sorry Andrew I was not disagreeing with you only suggesting a different non
CL way.
Is it not correct if I select All the programs not to be protected, I
emphasis All, does that not tell DEP not to protect anything?

--
Ian

With patience there is aways a way.

Please Reply to Newsgroup so all can read.
Requests for assistance by email can not and will be deleted.

 

[Synapse Syndrome]

Sorry Andrew I was not disagreeing with you only suggesting a different
non CL way.
Is it not correct if I select All the programs not to be protected, I
emphasis All, does that not tell DEP not to protect anything?

In Vista even more than XP, using the command prompt is the only way to do
certain things.

There are only options to protect all programs except ones specified, or
just essential Windows programs and services only, in the GUI interface you
describe.

AM was talking about turning it off completely, which is the only way to run
certain programs with this problem.

I have found that Get Right crashed on Vista because of DEP, but they most
probably have sorted this problem out by now. I think it is best to just
wait for program updates, as any program still in development will be
updated to run on Vista.

ss.

 

[Guest]

Ian and Andrew...thanks for your responses. I actually have feedback for
both of you.

Ian: Yes, the options you stated in the Advance System Settings appear to
be easier. However, I added the exe files for the two programs and still had
the same problems. In fact, messing with those options also caused my
Internet Explorer to start closing down due to the DEP problem. So, yes, I
did try those steps prior to going straight to the command prompt.

Andrew: You are correct about the command line I used to turn DEP off
altogether. I agree with you that it would seem that turning the DEP feature
off would eleviate the problem or would mean that the closure of the program
would be unrelated...however, I don't feel that it is just irony that both
progams still close at the same exact step in the process even thought I
don't get the error stating its DEP related. And if it is a new issue or
another security feature...what is it? With DEP on, it has stated closing
the programs at start-up. With DEP off, the program closes when I open the
folder containing my video files...I don't even have the chance to select a
file or convert anything...I just simply open the folder where the files are
located. I'm at my wits end here because both programs worked fine with XP
and I don't see any derrogatory reports out there about Cucusoft or Replay
A/V. I'm not sure what to do at this point.

 

[CZ]

AMD and Intel EM64T Processors support hardware DEP; many (most?) 32-bitprocessors do not.


Andrew:
http://techreport.com/reviews/2005q1/pentium4-600/index.x?pg=1
"Execute Disable Bit support - Like the 500J series processors, the new
Intel core [6xx series] includes support for the Execute Disable Bit, also
called the No Execute (NX) bit by AMD"

My P4 630 CPU supports DEP

 

[Synapse Syndrome]

processors do not.


Andrew:
http://techreport.com/reviews/2005q1/pentium4-600/index.x?pg=1
"Execute Disable Bit support - Like the 500J series processors, the new
Intel core [6xx series] includes support for the Execute Disable Bit, also
called the No Execute (NX) bit by AMD"

My P4 630 CPU supports DEP

Yes, as he said. Only the later versions of the Prescott core, which was
the last Pentium 4 core, had the NX bit.

ss.

 

[Andrew McLaren]

Andrew:

http://techreport.com/reviews/2005q1/pentium4-600/index.x?pg=1
"Execute Disable Bit support - Like the 500J series processors, the new
Intel core [6xx series] includes support for the Execute Disable Bit, also
called the No Execute (NX) bit by AMD"

Yep. Like I said, "many (most?) 32-bit Pentium IV processors do not [support
the NX bit]".

I did not say "NO 32 bit Pentium IV processors" ... that would be incorrect!


As Synapse kindly pointed out, the NX bit (or technically, on Intel the XD
bit, NX is an AMD term) was introduced in the Prescott series, approx middle
of 2004. Williamette, Northwood, Gallatin, and Mobile Pentium 4s do not have
a XD/NX bit. Collectively, these pre-Prescott chips constititue the
numerical bulk of the running 32-bit Pentium IV population.

 

[Andrew McLaren]

Andrew: You are correct about the command line I used to turn DEP off

altogether. I agree with you that it would seem that turning the DEP
feature
off would eleviate the problem or would mean that the closure of the
program
would be unrelated...however, I don't feel that it is just irony that both
progams still close at the same exact step in the process even thought I
don't get the error stating its DEP related. And if it is a new issue or
another security feature...what is it? With DEP on, it has stated closing
the programs at start-up. With DEP off, the program closes when I open
the
folder containing my video files...I don't even have the chance to select
a
file or convert anything...I just simply open the folder where the files
are
located. I'm at my wits end here because both programs worked fine with
XP
and I don't see any derrogatory reports out there about Cucusoft or Replay
A/V. I'm not sure what to do at this point.

Hi Mikey

Thanks for the detailed response. I suspect your apps are encountering some
other problem, which is causing them to crash. This may still be a Vista
compatibility issue; just not DEP-related.

The sure-fire way to isolate the problem is to run the apps under a
debugger, such as WinDBG, and examine the system at the point at which they
crash. However, I'll admit this is a slightly complex procedure for
end-users who don't happen to be full-time computer engineers .
Conversely, I'm not sure the best way for end-users to obtain the equivalent
info through Vista's built-in facilities. But a few ideas:

- look in Control Panel, System and Maintenance, Problem Reports and
Solutions, View Problem History.
This will list all the app crashes which the operating system has been
able to detect. Under the details of the crash, you may see an Exception
Code, such as "0xC0000005". This will indicate the nature of the crash. You
can also confirm that the problem report has been sent to Microsoft - if
they get enough reports of the same problem, they will fix it.

- look in Control Panel, System and Maintenance, Administrative Tools, Event
Viewer, Windows Logs.
When an application crashes, it may log events of its own (if the app
understands the NT Event Log) to indicate what went wrong.
Also, Windows will log an event if it detects that an application has
terminated abnormally. Look in the Application log for Error events (red
dot) with a source of "Application Error", Application Hang" or "Application
Popup".

- if you get desperate (or just curious) you can download and install
Microsoft's DebugDiag tool from here:
http://www.microsoft.com/downloads/...41-C458-46F1-B24D-F60151D875A3&displaylang=en
DebugDiag is considerably easier to use than WinDBG - you can just create
a rule for your application of interest, and then leave DebugDiag running in
the background. When the app crashes, DebugDiag will create a memory dump
and perform an automated analysis, with a nice HTML-formatted report.
Version 1.1 is Visa compatible.

Of course the more deeply technical the analysis, the harder it can often be
to identify the corrective action, short of re-writing the application's
source code. But if you're having a general compatibility problem with these
apps, you could try setting the App Compatibility, under Application
Properties, to Windows XP or similar.

Other folks may have better ideas, hope this helps a bit. Let us know how
you get on.

 

[cquirke (MVP Windows shell/user)]

On Sun, 5 Aug 2007 22:01:28 +0100, "Synapse Syndrome"

Yes, as he said. Only the later versions of the Prescott core, which was
the last Pentium 4 core, had the NX bit.

There was at least one further fabrication shrink after Prescott.

--------------- ---- --- -- - - - -

"We have captured lightning and used
it to teach sand how to think."

 

[cquirke (MVP Windows shell/user)]

On Mon, 6 Aug 2007 08:43:08 +1000, "Andrew McLaren"

As Synapse kindly pointed out, the NX bit (or technically, on Intel the XD
bit, NX is an AMD term) was introduced in the Prescott series, approx middle
of 2004. Williamette, Northwood, Gallatin, and Mobile Pentium 4s do not have
a XD/NX bit. Collectively, these pre-Prescott chips constititue the
numerical bulk of the running 32-bit Pentium IV population.

XP, and presumably Vista, do a sort of ersatz DEP where CPU lacks DEP
support - a bit like Win95 doing Plug-n-Play for devices on ISA bus,
which lacks the intelligence that PnP can leverage via PCI or PCMCIA.

How well this works (or breaks) is not knopwn to me, but it does imply
DEP settings can be a factor even where the system (including imaged
installations and reference PCs) has never seen a DEP processor.

---------- ----- ---- --- -- - - - -

Proverbs Unscrolled #37
"Build it and they will come and break it"

 

[Andrew McLaren]

On Sun, 5 Aug 2007 22:01:28 +0100, "Synapse Syndrome"


There was at least one further fabrication shrink after Prescott.

That's a total fabrication (sorry, I couldn't resist .

Actually, you're both right ... the "Cedar Mill" revision came after
Prescott. But all Cedar Mill Pentium 4s used the EM64T architecture, so they
are excluded from the class of "purely 32-bit Pentium 4s". All 64-bit
Pentium 4 CPUs supported Hardware DEP via the XD bit (aka, NX bit). Prescott
is indeed the last, of the 32-bit only Pentium 4s.

I haven't seen any figures, but I suspect the numerical impact of Cedar Mill
CPUs shipped would be close to negligible.

 

[Andrew McLaren]

XP, and presumably Vista, do a sort of ersatz DEP where CPU lacks DEP
support - a bit like Win95 doing Plug-n-Play for devices on ISA bus,
How well this works (or breaks) is not knopwn to me, but it does imply
DEP settings can be a factor even where the system (including imaged
installations and reference PCs) has never seen a DEP processor.

Correct, that was the so-called "Software DEP" feature, briefly described
here:
http://support.microsoft.com/kb/875352/EN-US/

If an exception is issued in the running process, this feature checks to
make sure that the address of the exception handler is in an executable
page. This prevents the exploit of making an exception jump to injected code
in a data page (eg, a "return to libc" attack). From Visual Studio 2003
onwards, applications can enforce this themselves, by being compiled with
the "/SafeSEH" flag. The Software DEP option in Windows enforces this
execution policy for programs built without "SafeSEH"; and by default "only
limited system binaries" - ie, Windows' own executable code; not user
applications.

So Software DEP isn't really an emulation of Hardware DEP in software - it's
a fundamentally different protection mechanism, albeit in an allied field of
memory protection. Calling them both "DEP" lumps together disparate
features. But since the differences are subtle for most users, it might be a
reasonable simplification.

I don't know what the current Windows build parameters are, but I suspect
Windows in the Vista timeframe would be built with the SafeSEH flag by
default; I'm pretty sure it is built with the /GS flag. But XP pre-dated the
arrival of VS2003, so it needed some architectural assistance. In any case,
Vista also provides Address Space Layout Randomisation (ASLR), which
provides a further layer of protection against "return to libc" attacks.

Software conflicts with DEP by user applications nearly always involve
Hardware DEP.

Warm regards,

 

[Guest]

when the machine is rebooted the settings are lost and deleted devices
reapear, So sad and a waste of time this VISTA

 

[cquirke (MVP Windows shell/user)]

That's a total fabrication (sorry, I couldn't resist .
HAHA!!

Actually, you're both right ... the "Cedar Mill" revision came after
Prescott. But all Cedar Mill Pentium 4s used the EM64T architecture, so they
are excluded from the class of "purely 32-bit Pentium 4s".

AFAIK, some Prescott also include EM64T (and NX), which I see as an
evolotional rather than generational change.

All 64-bit Pentium 4 CPUs supported Hardware DEP via the XD bit (aka,
NX bit). Prescott is indeed the last, of the 32-bit only Pentium 4s.

I'm not sure if it is (as above). I think that fabrication spans what
you refer to as "pure 32-bit" and "64-bit" P4s.

Let's not get too carried away with this 64-bit thing. It's not a
deep processor redesign, like going from 286 to 386 or from P4 to the
Core 2 core(s). It's just an add-on, something to do with the extra
transistors that Moore's Law delivers with every fab shrink. File it
in the same bin as MMX, SIMD, VT and the rest of the alphabet soup.

I'm stressing this because right now (and not for the first time),
Intel is playing silly-buggers with their processor names. We have...
- Celeron D
- Celeron L
- Pentium dual core
- Pentium 4
- Pentium D
- Core 2 Duo
....can you tell at a glance,. which are old "P4" architecture and
which are new "Core 2"? The difference is important, given that the
new core runs at 180% of the speed of the old core at same GHz.

The answer: Celeron-L, Pentium dual core and Core 2 are the new core,
whereas the others are old core. Here's what they really are...
- P4 generation, single-core: Celeron D, Pentium 4
- P4 generation, dual-core: Pentium D
- Core 2 generation, single-core: Celeron L
- Core 2 generation, dual-core: Pentium dual core, Core 2 Duo

As usual, with Intel, you have to watch your back. Brand marketer
speak with forked tongue ;-)

I haven't seen any figures, but I suspect the numerical impact of Cedar Mill
CPUs shipped would be close to negligible.

I dunno about that, either. I've built a lot of PCs with Celerons
(yep, you read right) that were P4-core but included both NX and
EM64T, so either these were Prescotts that weren't "pure 32-bit" as
you claim, or there have been a lot of Cedar Mill CPUs around for a
while now. I wasn't aware of a fabrication shrink at the time, and
they still came with full-height copper-core heat sinks.

-------------------- ----- ---- --- -- - - - -

Tip Of The Day:
To disable the 'Tip of the Day' feature...

 

[Andrew McLaren]

I'm not sure if it is (as above). I think that fabrication spans what
you refer to as "pure 32-bit" and "64-bit" P4s.

It's just an OR/XOR confusion, based on imprecision in natural language.

The Prescott series included some chips which were 32-bit only, and some
chips which were 32/64 bit (ie, EM64T).

All Cedar Mill chips were 64-bit.

So, Prescott includes the last of the Pentium 4 chips that were 32-bit only.
These were a subset of the total set of Prescott chips. The set of Prescott
chips is the union of the sets of 32-bit Precott chips and 32/64-bit
Prescott chips. Prescott was the last core which had 32-bit only chips, but
not all Prescott chips where 32-bit only. Whereas, all Cedar Mill chips are
32/64 EM64T chips.

Now, let's see ...

X ? Y ? ?x, if x ? X then x ? Y, where X is the set of 32-bit Prescott
Processors and Y is the set of Prescott processors.

Or ... um, something like that, anyway ...

Let's not get too carried away with this 64-bit thing. It's not a
deep processor redesign, like going from 286 to 386 or from P4 to the
Core 2 core(s).

Well, having debugged a couple of Itanium memory dumps (or rather - I
*attempted* to debug a couple of Itanium memory dumps) I certainly agree
that EM64T is an evolutionary, not revolutionary change ... I saw the
revolution (Itanium) and it was a scary place (although a little bit
exciting, too).

Anyway ... probably something we should discuss over a beer, at the next MVP
Summit ... )

 

[Guest]

Andrew,

Thanks for the info on DEP.

I have shut mine off to install a piece of software (long story). Now I'd
like to be able to turn it on, but not always on. I'd like option 2.

I know bcdedit.exe /set {current} nx AlwaysOn turns it always on, but how to
I enable the other two options in the "Advanced system settings."?

Any help is welcome.

Jeff