PIFLAG_DEBUGGER_ATTACHED in Vista

I'm having problems with several windows programs under vista including
IExplorer.exe, Explorer.exe, and several others. These programs appear to
have code in them that either directly test PIFLAG_DEBUGGER_ATTACHED or make
a system call which I assume does the same test. Then if it indicates that a
debugger is attached, they issue an int 3 (breakpoint). If I have Visual
Studio installed I get a JIT message that allows me to attach a debugger and
nop the int 3, but if I don't have visual studio installed the app (such as
IE or Explorer) simply crashes with an unhandled exception. I suspect that
something somewhere is corrupting the PIFLAG_DEBUGGER_ATTACHED flag causing
it to always indicate that a process is being debugged, but I'm not sure what
is corrupting that flag. I have also seen posts on the net to the effect that
some games (who are trying to prevent hacking and testing by testing that
flag) don't work on Vista because of this problem with
PIFLAG_DEBUGGER_ATTACHED. Is this a known problem and if so is there a fix
for it?

On 19/01/2010 04:31, John Erickson wrote:
> I'm having problems with several windows programs under vista including
> IExplorer.exe, Explorer.exe, and several others. These programs appear to
> have code in them that either directly test PIFLAG_DEBUGGER_ATTACHED or make

Hi John

It sounds like you're seeing frequent application crashes from a variety
of programs - right?

If the system has a debugger installed (eg from VS) then the exception
handler will go to the AEDebug-specified debugger and run it: in this
case, Visual Studio. If no debugger is installed, then you'll get an
unhandled exception.

This is all completely normal Windows error-handling behaviour (well,
apart from the crashes themselves) so I'd suggest you forget about
Process Info Flags, and the like, and focus more on why you are seeing
so many crashes!

You may see compatibility problems when running 3rd party apps on Vista;
but Explorer.exe and IExplorer.exe are both intended to be stable
applications on Windows :-) If they crash frequently, then you have a
problem.

I recommend you troubleshoot it as for a normal instability scenario: eg
run antivirus and anti malware scans with latest signatures; run sfc to
confirm core system files are okay; CHKDSK; look for bad drivers; look
for bad Shell extensions, browser plug-ins, spurious
automatically-started "helpful" programs etc; look for troublesome
device drivers; test physical memory; etc.

FWIW I don't believe the user-mode Windows bits (explorer.exe, etc) have
explicit anti-debugging code. They can all be debugged using WinDBG etc.
Some games and cryptography apps have code to crash if a debugger is
attached.

Hope it helps

Andrew

--
amclar at optusnet dot com dot au

On 20/01/2010 15:44, John Erickson wrote:
> I wouldn't call them application crashes exactly. They are breakpoints set in
> the code to be invoked only if the process is attached to a debugger. The

If you're running the Checked Build of Windows, then all bets are off.
Yes, the Checked Build will abend in lots of unusual and unexpected
places. That's what it's for ;-)

The Checked Build is usually available for download from MSDN, although
not from TechNet. Not sure how you would have picked up a Checked Build;
but quality control on MSDN and TechNet downloads is way, way lower than
on actual, shipping MSFT product - I have hit strange and unexpected
problems in MSDN downloads many times over the years, which could not
be reproduced in shipping RTM software. Just a fact of life. They aim
for "commercially acceptable" quality, not 100% bomb-proof quality
(that's expensive).

Try re-downloading and make sure you get the non-Checked Build. Or
report the error to TechNet help.

Hope it helps,

Andrew

--
amclar at optusnet dot com dot au