Vista - Data Execution Prevention with Windows Vista

> 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/d...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.
--
Andrew McLaren
amclar (at) optusnet dot com dot au

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."
>--------------- ---- --- -- - - - -

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"
>---------- ----- ---- --- -- - - - -

"cquirke (MVP Windows shell/user)" <cquirkenews@nospam.mvps.org> wrote ...
> 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.


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
amclar (at) optusnet dot com dot au

"cquirke (MVP Windows shell/user)" <cquirkenews@nospam.mvps.org> wrote ...
> 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,
--
Andrew McLaren
amclar (at) optusnet dot com dot au

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

"mikeyllo" wrote:

> 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

On Mon, 13 Aug 2007 08:09:14 +1000, "Andrew McLaren"
>"cquirke (MVP Windows shell/user)" <cquirkenews@nospam.mvps.org> wrote ...
>> 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.

>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...
>-------------------- ----- ---- --- -- - - - -

"cquirke (MVP Windows shell/user)" <cquirkenews@nospam.mvps.org> wrote...
> On Mon, 13 Aug 2007 08:09:14 +1000, "Andrew McLaren"
>>"cquirke (MVP Windows shell/user)" <cquirkenews@nospam.mvps.org> wrote ...
>>> On Sun, 5 Aug 2007 22:01:28 +0100, "Synapse Syndrome"
> 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 ... :-))
--
Andrew McLaren
amclar (at) optusnet dot com dot au

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

"Andrew McLaren" wrote: