DEP question

[Sunny]

I'm running XP SP2 on a dual PIII system - i.e. my processors do not
support hardware-based DEP.

A mainstream software vendor's technical support has advised me to
change my DEP settings from the default "Turn on DEP for essential
Windows programs and services only" to "Turn on DEP for all programs and
services except those I select", then add their executable to the
exception list. The vendor claims this is required for their software to
run under SP2.

This doesn't make sense to me for two reasons:

1. The third party executable should already be DEP-exempt when using
the default setting, since it's not an "essential Windows program or
service"

2. According to Windows Help, "If a program tries to run code—malicious
or not—from a protected location, DEP closes the program and notifies
you" - but I have never seen a DEP notification regarding any program
although I have been running with "Turn on DEP for all programs and
services except those I select" and an empty exception list for several
months.

Am I missing something, or is the software vendor's technical support
wrong on this one?

Sunny

 

[Tim]

The only thing you seem to be missing is a software vendor that is willing
to fix bugs in their software.
A slight concession: they may be using 3rd party libraries supplied by yet
another vendor that is the culprit however fixing the issue is there
responsibility not yours.

The vendor has had over a year to test this and get it right.

- Tim

 

[NoNoBadDog!]

First, with a P4, you do not have DEP. You Have No Execute Bit.

Similar, but not the same. Only AMD offers true hardware DEP.
The No Execute Bit attempts to emulate DEP, but does not offer the same
hardware protection that the AMD chips do, so there are different strategies
for the two different implementations.

Bobby

 

[Walter Clayton]

See http://support.microsoft.com/?kbid=875352

Full blown DEP isn't implemented unless running on hardware that supports
it. There is a soft emulation for system centric stuff though.

If you're not current seeing any DEP exceptions, then do nothing at present.

 

[Sunny]

First, with a P4, you do not have DEP. You Have No Execute Bit.

No, I don't. PIII != P4.

Similar, but not the same. Only AMD offers true hardware DEP.
The No Execute Bit attempts to emulate DEP, but does not offer the same
hardware protection that the AMD chips do, so there are different strategies
for the two different implementations.

Perhaps so, but irrelevant since the question pertains to software DEP
as implemented in XP Pro SP2.

 

[Sunny]

See http://support.microsoft.com/?kbid=875352

Full blown DEP isn't implemented unless running on hardware that supports
it. There is a soft emulation for system centric stuff though.

Actually my understanding is that hardware-based and software-based DEP
are quite independent, although this is not evident in the GUI as they
share configuration controls. The KB article you referenced appears to
be excerpted from a much more comprehensive paper:

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2mempr.mspx

If you're not current seeing any DEP exceptions, then do nothing at present.

Sounds reasonable on the surface, yet Symantec Technical Support insists
their software needs OptOut despite the fact no DEP exceptions are raised.

Perhaps their software handles the exception (thus the user is not aware
it has occurred) but cannot recover functionally - but if that were the
case, I would expect the default OptIn setting to work since no
exception would occur.

Based on the information published by Microsoft, there should be no
difference between OptIn and OptOut for an application which appears on
the OptOut list.

So my original question stands - Am I missing something, or is
Symantec's technical support wrong on this one?

Sunny

 

[Treeman]

Walter Clayton wrote:
-
See http://support.microsoft.com/?kbid=875352

Full blown DEP isn't implemented unless running on hardware that
supports
it. There is a soft emulation for system centric stuff though.-

Actually my understanding is that hardware-based and software-based
DEP
are quite independent, although this is not evident in the GUI as they
share configuration controls. The KB article you referenced appears to
be excerpted from a much more comprehensive paper:

http://tinyurl.com/4o6bb
-
If you're not current seeing any DEP exceptions, then do nothing at
present.-

Sounds reasonable on the surface, yet Symantec Technical Support
insists
their software needs OptOut despite the fact no DEP exceptions are
raised.

Perhaps their software handles the exception (thus the user is not
aware
it has occurred) but cannot recover functionally - but if that were
the
case, I would expect the default OptIn setting to work since no
exception would occur.

Based on the information published by Microsoft, there should be no
difference between OptIn and OptOut for an application which appears
on
the OptOut list.

So my original question stands - Am I missing something, or is
Symantec's technical support wrong on this one?

Sunny

Sunny,
You can just turn DEP off in boot.ini if you want.
Step 1 Disable DEP completely if using windows XP SP2

To do this, open My Computer, C:
Tools Folder Options View Tick Show Hidden Files and folders, and
untick "Hide Extensions for known file types" and "Hide protected
operating system files"

Now on root of c: you should see boot.ini

Open it up in notepad. The last line should end in /fastdetect
/noexecute=optin

Change it so it now ends /fastdetect /execute
(take note of spaces)
File Save Exit.
Treeman

 

[Walter Clayton]

Actually my understanding is that hardware-based and software-based DEP
are quite independent, although this is not evident in the GUI as they
share configuration controls. The KB article you referenced appears to be
excerpted from a much more comprehensive paper:

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2mempr.mspx


Sounds reasonable on the surface, yet Symantec Technical Support insists
their software needs OptOut despite the fact no DEP exceptions are raised.

Perhaps their software handles the exception (thus the user is not aware
it has occurred) but cannot recover functionally - but if that were the
case, I would expect the default OptIn setting to work since no exception
would occur.

Based on the information published by Microsoft, there should be no
difference between OptIn and OptOut for an application which appears on
the OptOut list.

So my original question stands - Am I missing something, or is Symantec's
technical support wrong on this one?

Sunny

I have to answer that question rather delicately. Let's just say that I
can't say much about Symantec since I was taught to say nothing if I had
nothing good to say...

What's fuzzy is exactly how Symantec hooks the system and if it's
dynamically hooking system code and data areas then it could fall afoul of
software DEP. I think the issue may revolve around the definition of what
'system binaries' encompasses.

I do have first hand experience with DEP being triggered via hardware. That
was an interesting experience since it was my AV that bit the dust initially
and it ran fine on x32 with SP2 in default DEP configuration. It didn't
become an issue until I upgraded to x64 hardware. That issue has been
resolved by the vendor however, and that without me having to do anything
other than upgrade the product. I do have to exempt the system spooler
though since my printer drivers will probably never be updated...

 

[Sunny]

I have to answer that question rather delicately. Let's just say that I
can't say much about Symantec since I was taught to say nothing if I had
nothing good to say...

Yes, they do have a bad habit of buying perfectly good products and
fouling them up, but I've found their email support to be no worse than
average provided you are logical and methodical - and prepared to go a
few rounds to get past the boilerplate responses.

In another recent case, I was told the product did not support my
requirement but I could file a feature request. I didn't buy it, figured
out how to make it work, and sent them the details - which they promptly
posted as a KB article.

What's fuzzy is exactly how Symantec hooks the system and if it's
dynamically hooking system code and data areas then it could fall afoul of
software DEP. I think the issue may revolve around the definition of what
'system binaries' encompasses.

I see your point, but if their code was triggering DEP exceptions in
system binaries, I would expect them to have me disable DEP entirely
(/execute in boot.ini), not extend DEP with OptOut.

The really annoying thing about all this is the previous version of the
product (before Symantec bought it) works perfectly on SP2, and the only
visible differences are branding - no new functionality aside from
LiveUpdate support AFAICT.

At least I have an alternative if Symantec fails to resolve the issue:
my product key works for the pre-Symantec version as well However,
I'd much prefer to get the issue sorted and the KB updated to save
others the trouble.

 

[Sunny]

Sunny,
You can just turn DEP off in boot.ini if you want.
Step 1 Disable DEP completely if using windows XP SP2

To do this, open My Computer, C:
Tools Folder Options View Tick Show Hidden Files and folders, and
untick "Hide Extensions for known file types" and "Hide protected
operating system files"

Now on root of c: you should see boot.ini

Open it up in notepad. The last line should end in /fastdetect
/noexecute=optin

Change it so it now ends /fastdetect /execute
(take note of spaces)
File Save Exit.
Treeman

You missed the last step: reboot

Thanks, I'd already tried disabling DEP completely - didn't solve the
issue or convince Symantec that DEP isn't the issue. I might have to
give up on them.

Sunny