Volume 7, Number 1

Copyright (C) 2005 Mark Russinovich

January 5, 2005 - In this issue:

- Got DEP?


- November Statistics
- Sysinternals Magazine Articles
- Sysinternals RSS Feed
- Mark is a Microsoft MVP
- Autoruns v6.01
- Process Explorer v8.61
- Sigcheck v1.0
- Bginfo v4.07
- Regjump v1.0
- Hex2dec v1.0
- Tcpvcon v2.34
- PsTools Updates
- Sysinternals at Microsoft

- Internet Browsing
- Using LiveKd to troubleshoot sick systems
- CreekSide?
- ChkReg Registry Fixer
- Windows Memory Diagnostic
- Researching undocumented interfaces

- Windows Connections in San Francisco
- Hands-on Windows Internals/Sysinternals Classes by Mark Russinovich & David

The Sysinternals Newsletter is sponsored by Winternals Software, on the Web at
http://www.winternals.com. Winternals Software is the
leading developer and provider of advanced systems tools for Windows

Winternals is pleased to announce the upcoming release of Administrator's Pak
5.0 with a comprehensive update including ERD
Commander 2005.

New features in ERD Commander 2005 include:
- Crash Analyzer: Quickly and easily diagnose the driver responsible for a
Windows crash - even if the system won't boot
- DiskWipe - Securely erase hard disks or volumes; Autoruns: See which
applications are starting at Windows setup and user
logon - useful for diagnosing system resource issues and finding potential
- FireFox Web Browser: download hotfixes, driver updates, search for help in the
Microsoft Knowledge Base - all on the system
you are trying to repair
- Hotfix Uninstall Wizard, which allows you to remove hotfixes and service packs
on an unbootable system
- System File Repair, which checks Windows system files for integrity.
These features, numerous improvements and usability enhancements to ERD
Commander 2005, and a new easier to build and use Remote
Recover client based on Windows PE are all included in the new Administrator's
Pak 5.0, available in late January 2005. To sign up
for an evaluation of the Administrator's Pak 5.0 when it is released, visit



Hello everyone,

Welcome to the Sysinternals newsletter. The newsletter currently has 40,000

The rising tide of malware, including spyware and viruses, has everyone
concerned about security. Good security measures include
keeping up with operating system and application patches, installing and
configuring firewall, antivirus, and spyware removal tools,
and exercising judgment when downloading from the Internet or opening e-mail
attachments. Despite thorough measures, however,
malware can still find ways to sneak by defenses and infect a computer. The most
common loophole in a system's defenses is the
buffer overflow vulnerability, and that's why you should be familiar with
Windows XP Service Pack 2's Data Execution Prevention
(DEP) feature.

A buffer overflow is a programming error that malicious programs can take
advantage of to take control of the thread that executes
the coding error. Buffer overflows are usually stack-based, meaning that an
attacker gives the program more data than will fit into
a buffer stored on the stack. The data is crafted in such a way that when the
function with the overflow tries to return to the
function from which it was invoked, it instead returns to a location in the

Unfortunately, buffer overflow errors can plague even the best-tested and
reviewed software. Multiple buffer overflows are announced
for Windows and its component software on a monthly basis (Linux and its
applications are not immune, with a number of buffer
overflow on par with Windows). A common theme for most buffer overflow exploits
is that they result in execution of code placed in
memory regions that should contain only data.

While the Intel Itanium processor has supported no-execute protection from its
release, it was not until Windows XP SP2 (and the
upcoming Windows Server 2003 SP1) that Windows actually makes use of this
hardware support, for example marking thread stacks and
heap memory as non-executable. Other processors that support no-execute hardware
protection include the 64-bit AMD64 Opteron and
Athlon 64 and Intel's clone called EM64T-now available on Xeon and Pentium 4
processors. AMD and Intel recently introduced 32-bit
processors with no-execute support: the AMD Sempron and the Pentium 4 "J" family
(such as the 520J, 540J, etc).

It might seem obvious to you that Windows should by default enforce no-execute
protection for stacks and application heap memory to
prevent buffer overflow exploits, but there are hundreds of thousands of
existing applications, some of which that might actually
rely on the setting not being enforced for correct operation. Therefore, Windows
XP SP2, the first release of Windows that enforces
no-execute protection, gives an administrator control over what processes get
protected and which ones don't. First, in a decision
aimed at improving security in the future, the 64-bit version of Windows always
enforces no-execute flags for all 64-bit processes.
If a software vendor wants to release a 64-bit application they need to make
sure that they don't execute code from non-executable
regions of memory (they can mark a data region as executable if they generate
code on-the-fly, as Java and .NET applications often

Second, since buffer overflow exploits are most commonly aimed at operating
system components, 32-bit Windows XP and Windows Server
2003 by default protect core operating system images. However, for 32-bit
applications (running on either 32-bit Windows or 64-bit
Windows), Windows XP defaults to an "opt-in" strategy (applications are not
protected by default) while Windows Server 2003 defaults
to "opt-out" (applications are protected by default but specific applications
can be excluded). This makes sense because security is
typically of higher priority on server systems. You can change the opt-in or
opt-out settings in the DEP configuration dialog that
you access through the Settings button in the Performance section of the
Advanced page of the System control panel applet.

As I mentioned earlier, with the exception of the relatively new AMD Sempron and
Pentium 4 "J" processors, all x86 compatible chips
released to date lack no-execute support. However, Windows XP and Windows Server
2003 implement a limited form of DEP on those
processors called "software DEP". Because the operating system gains control of
a thread when the thread generates a fault, it can
ensure that the fault handler it will execute is one that is statically
registered by the program's code. This prevents an exploit
that redirects a thread's fault handler to execute malicious code in an
overflowed stack buffer, which is what the CodeRed virus
caused IIS to do when it was released in 2001.

Despite its relative simplicity, DEP is one of the strongest defenses the
operating system offers in its shield against
self-propagating malware. Sadly, three things limit its power: lack of hardware
support in most currently-deployed processors for
the no-execute setting, the default opt-in setting in Windows XP such that only
core operating system processes are protected, and
lack of awareness. Software DEP is limited in its scope and so DEP is only
marginally effective unless you are running Windows on
hardware that supports no-execute. The fact that Windows XP defaults to opt-in
means that even when users run Windows on no-execute
hardware the only processes that get DEP protection are those of the operating
system - if there's a buffer overflow in you're
third-party firewall, Web browser, e-mail reader, or other network-enabled
application, you're still vulnerable. In fact, some of
the applications most-exploited by malware, IIS and Outlook, aren't protected
under the opt-in setting. Finally, because most people
aren't aware of its default behavior, or even DEP at all, systems will for the
most part remain at risk for buffer-overflow

Its time that Microsoft makes users pay the compatibility price in exchange for
better security or users are going to end up paying
a much higher price at the hand of viruses - and they will in turn pass the bill
onto Microsoft. In the meantime, I strongly
recommend you upgrade to Windows XP SP2 (Windows XP 64-bit Edition and Windows
Server 2003 SP1 also have support for no-execute),
switch to opt-in, and upgrade to a processor with no-execute support (sadly, I
won't get a commission).

Please pass the newsletter to friends you think might be interested in its



The official Microsoft book on the internals of Windows Server 2003, Windows
2000 and Windows XP, which I coauthored with Dave
Solomon, is now available in book stores. Dave and I expanded the coverage of
the previous edition by about 25%, adding new material
not only on Windows Server 2003 and XP changes, but on troubleshooting tools and
techniques. You'll find advanced tips on using
Process Explorer, Filemon and Regmon, and there's an entire new chapter on
Windows crash dump analysis.

Learn more about the book's content and order on-line at


I got the request to add a new-posting notification mechanism to Sysinternals so
often that I finally followed the web-wide trend
and added an RSS feed (if you're not familiar with RSS feeds, here's a good
primer: http://rss.softwaregarden.com/aboutrss.html).
The feed also gives me the opportunity to notify you of minor bug fixes and
updates that don't warrant a full listing on the front
page. It already looks like the preferred way for people to learn of updates
based on the number of hits the feed gets per day.

Access the Sysinternals RSS feed at:

About six months ago I started authoring a semi-monthly column in Windows IT Pro
Magazine (formerly Windows and .NET Magazine) on
Sysinternals tools. Each column describes a different tool, providing tips on
advanced usage and information on how they work.

Of the three that have been published, listed below, the first two are
accessible on-line by non-subscribers and the third will be
Autoruns: http://www.win2000mag.com/Windows/Article/ArticleID/44089/44089.html
Pslist and Pskill:
PsExec: http://www.winnetmag.com/Windows/Issues/IssueID/714/Index.html

The Platform SDK Microsoft Most Valuable Professional (MVP) lead has named me a
MVP for 2005. I'm grateful to him and Microsoft for
this official acknowledgement of the contributions I've made to Microsoft
customers with Sysinternals.

I finally got a decent web traffic analysis program for Sysinternals and have
analyzed the log files for the month of November. The
magnitude of the numbers amazed even me. Here are some highlights:

- 3.6 million page views
- 775,000 unique visitors
- 1.2 million utility downloads
- 200,000 downloads of Process Explorer, the #1 download

Autoruns has evolved a lot in the last several months with two major version
number updates. The latest release of Autoruns displays
auto-start locations in addition to the standard Run key and startup folders,
including Winlogon notification DLLs, Explorer
toolbars, namespace extensions and browser helper objects, and
auto-initialization DLLs. Another new feature, the Google menu item
(borrowed from Process Explorer) helps you identify unknown images by opening a
browser and initiating a search of the selected
image name.

Another new feature, image signing verification, can help you distinguish
between malware and system components or trusted
applications. Microsoft generally includes hashes of operating system files that
are signed with Microsoft's private signing key.
Windows cryptographic functions decrypt the signed hashes with Microsoft's
public signing key and Autoruns validates the images on
your system by comparing their hashes with the decrypted versions, prefixing the
image's company name with "(Verified)" when there's
a match. If an image has been tampered with, corrupted, replaced, or has a hash
signed by a publisher that is not trusted by your
system, Autoruns reports the company name for the image as "(Not Verified)".

As a systems administrator you may want to check the auto-starting images in
accounts other than the one you're logged-in as, so
Autoruns now includes a User menu with selections for each account that has a
profile stored on the computer.

Finally, there's now a command-line equivalent of the Autoruns GUI, called
Autorunsc, that lists autoruns information to the
console. Its ability to format the output as CSV, when combined with
Sysinternals' PsExec utility, makes it easy for you to generate
inventories of the configured auto-starting images for computers throughout your

Download Autoruns at

Once again, Process Explorer, a tool that replaces Task Manager as an advanced
process management utility, has been the tool on
which I've focused the most, and that's because I get so much feedback for it.
Since the last newsletter Process Explorer has gone
from version 8.4 to 8.6. A slew of new features mark these two releases,
including a Google menu item that initiates a search for
information about a selected process, a strings tab in the process properties
dialog that lists the ASCII and Unicode strings
present in a process image file, a strings menu entry that lists strings in a
selected DLL image file, and the name of the most
CPU-consuming process in the tooltip that shows when you hover the mouse over
the Process Explorer tray icon.

Many people requested features that they missed when switching from Task
Manager, such as the Task Manager Applications tab. The
Applications tab shows a list of top-level windows on the interactive desktop
along with the status of the thread that owns each
window: "Running" if the thread is currently waiting to receive a windows
message or has processed a windows message within the last
five seconds, and "not responding" otherwise (ironically, this generally means
that "running" indicates the thread is waiting and
"not responding" that its off running). You can now get this same information
with Process Explorer by adding the "Window Title" and
"Window Status" columns to the process view.

Process Explorer has had features targeted at.NET processes for some time,
including highlighting for .NET processes and a .NET
Performance tab in the process properties dialog of .NET processes. A .NET
process is one that has loaded and registered with the
.NET runtime. If a process registers sometime after it starts up Process
Explorer may not realize that it's a .NET process, but the
latest release rechecks processes for .NET status and job object membership when
you manually refresh the display, either by
pressing the refresh toolbar button, F5 key, or selecting the Refresh menu item.

For situations when you're not sure what process owns a window you can use the
new window-finder toolbar button to identify it.
Simply drag the toolbar button, which looks like a target, off the toolbar and
over the window in question and Process Explorer
selects the owning process in the process view.

An addition that will be immediately obvious to you is the mini-CPU graph that
displays near the toolbar. This graph shows the CPU
usage history of the system, and like the expanded version you get when you
click on it to open the Process Explorer System
Information dialog, presents a tooltip that includes the timestamp and highest
CPU consuming process for the point in the graph over
which you move the mouse. You can move the graph to anywhere in the toolbar
area, even onto its one row so that it stretches across
the width of the Process Explorer window.

Two security-related features are image-signing verification and data execution
protection (DEP) status. When you enable the image
signing option Process Explorer will check to see if a process image has been
digitally signed by trusted signer and, like Autoruns,
prefix the company name in the process properties dialog with "Verified" or "Not
Verified". The option is disabled by default
because the image signing check can take several seconds as the check goes to
web sites to verify the validity of signing

DEP, which I describe in this newsletter's introduction, is something that you
should enable on Windows XP SP2 for enhanced
protection against buffer overflow exploits. You can check the DEP status of a
process either by adding the "DEP Status" column to
the process view or by checking the "DEP status" field on the image page of the
process properties dialog.

Finally, Process Explorer now lists the drivers loaded on the system in the DLL
view of the System process, which is the process
associated with kernel and device driver worker threads. The same information is
available for each driver as for DLLs listed for
other processes, including version, company name, full path, and load address in
the system address space.

Download Process Explorer at

Many of Sysinternals tools are adopting features that help users identify
malware and Sigcheck is a command-line utility focused
almost exclusively on that goal. It uses the same image signing verification
functionality included in Autoruns and Process Explorer
to tell you whether or not a file has been digitally signed by a trusted
publisher. In addition, it reports file version information
for the image or images you specify, including the product name, description,
company name, and version. This information is similar
to that which the Filever tool that ships with Windows XP and Windows Server
2003 reports, but Sigcheck also reports the timestamp
when the file was originally "linked" or created for unsigned images, and the
timestamp of the image signing for ones that signed.
Finally, most signed hashes are signed with keys that themselves have been
signed, a sequence that forms what's called a certificate
signing chain. Sigcheck supports a command-line option that directs it to print
the signing chain with information about each of the
signers in the chain.

One of the potential security-related uses of Sigcheck is to investigate any
unsigned .exe .dll or .sys images in any of the
directories under the root of your Windows installation (typically \Windows).
You can easily identify unsigned .exe images by
running Sigcheck with this command-line, for example:

sigcheck -s -u c:\windows\*.exe

All Microsoft images should include valid signatures, but the above command will
sadly reveal that many don't, resulting in files
that can be potentially exploited to hide malware.

Download Sigcheck at

This minor update to Bginfo, a tool that displays the information you configure
on the desktop of the computer on which you run it
for easy viewing, has better support for bitmaps that it must stretch to fit the
size you specify, CPU detection enhancements,
support for MySQL, and improved multi-monitor display compatibility.

Download Bginfo at

If you've ever wanted to create Explorer shortcuts to specific Registry keys or
to simply enter a key's path and have Regedit open
to the target location then you'll find Regjump useful. Regjump is a
command-line utility that uses the same Registry "jump-to"
technology we pioneered in Regmon. Give Regjump a Registry path as its
command-line argument and Regedit will open and navigate to
the specified key or value.

Download Regjump at

Working with debuggers and disassembly I often find myself having to convert
hexadecimal to decimal and vice versa. I finally got
tired of opening Calc, entering a number, and then switching the base to see the
conversion and so I wrote a tiny command-line
conversion utility. Hex2dec converts in either direction and conveniently
identifies input as hexadecimal if it has a "0x" or "x"
prefix or includes the letters 'a'-'f' (its case insensitive).

Download Hex2dec at

Netstat is a command-line utility built into Windows NT and higher that shows
you the currently active TCP and UDP endpoints on the
system. The version Microsoft introduced with Windows XP includes a useful piece
of information: the process identifier (PID) of the
process that opened each endpoint. However, to determine the name of the process
or any other information about it you have to open
a process listing tool and find the process with that PID.

TCPView is a Sysinternals GUI application that shows the same active endpoint
information, but much more conveniently than Netstat,
because it includes the name of the process, quickly switches between DNS names
and raw IP addresses, and highlights with colors new
and deleted endpoints. TCPView's download now includes TCPVCon, a console
version of TCPView, for those of you that like to use
command-line interfaces. Unlike Netstat, TCPVCon displays the full path of the
process associated with each endpoint and includes a
switch that dumps output in CSV format.

Download Tcpvcon at

PsKill and PsLoglist are the two PsTools that have gained enhancements in the
last few months. PsKill, a command-line utility that
terminates processes on the local or a remote system, now supports a -t switch
so that you can end an entire tree of processes. A
number of people asked for this option to make it easy to clean up runaway trees
of batch scripts.

PsLoglist is a command-line tool that dumps event logs on local or remote
systems. Recent updates have added 5 options to its
already lengthy list of command-line qualifiers. The new arguments allow you to
exclude specified event types or event sources from
the output or only dump events from the last few minutes or hours. It now also
supports an event log monitoring mode where it runs
until you terminate it, printing event log records as they generate.

Download PsTools, including PsKill and PsLoglist, at

Here's the latest installment of Sysinternals references in Microsoft Knowledge
Base (KB) articles released since the last
newsletter. This brings to 63 the total number of public KB references to

FIX: Windows Media Player 9 Series for Windows frequently accesses the registry
and may affect performance

GDI+ 1.0 Security Update Overview

Registry Editing

You receive a "There is no information to display in this view" error message
when you try to access a Project View


About a year ago I announced that I had switched from IE to Mozilla because IE
lacked the features considered mandatory for a decent
Internet browser, like popup blocking, tabbed browsing, automatic form filling,
and advertisement filtering. Not long afterward
someone pointed me at Avant Browser, a small download that uses IE (it is not
its own browser) to give it all that and more.
Mozilla's clunky UI and lack of compatibility with certain sites I frequent made
the decision to switch easy. While the new FireFox
release is better in both respects, there are still some incompatible sites
(like Windows Update, for instance) and so I haven't
been compelled to switch again.

Microsoft's slow of progress improving IE, even in light of IE's modest Windows
XP SP2 enhancements, should shame them into buying
Avant Browser and building it into the next version of IE.

Download Avant Browser at:

LiveKd is a utility that I wrote for the 3rd edition of Inside Windows 2000
(it's now a freeware tool on Sysinternals). It lets you
use Windbg or Kd of the Microsoft Debugging Tools for Windows package to execute
debugging commands normally used to investigate
crash dumps and frozen systems on a system that's on-line and active. Microsoft
introduced a similar capability, called "local
kernel debugging", for the debugging tools when running on Windows XP and
higher. There are several things you can do with LiveKd,
however, that you can't with local kernel debugging. For example, you can't look
at kernel-mode thread stacks with local kernel
debugging and the list-kernel modules command, "lm k", lists only the operating
system kernel and not the other load drivers when
executed in local kernel debugging. Both commands work inside of LiveKd.

Another command that doesn't work in local kernel debugging, but that does in
LiveKd, is ".dump". I learned from a Microsoft Product
Support Services (PSS) engineer that the .dump command can be useful for
troubleshooting a sick system. A computer that is
experiencing problems, but delivering services such as web or database, may not
be a candidate for rebooting or traditional
debugging where the system is paused during the investigation. Running LiveKd
and executing .dump results in a crash-dump formatted
file that contains the contents of the system's physical memory. You can take
the dump file to another machine and analyze the state
of the operating system and service applications by loading the dump file into
WinDbg or Kd, thus avoiding an outage while you look
into the cause of a problem.

Download LiveKd at

I was recently investigating the initialization of Windows XP Service Pack 2
version of Winlogon, the system process responsible for
presenting the logon user interface, when I came across code in the disassembly
where Winlogon checks for the presence of a DLL
named ediskeer.dll in the \Windows\System32 directory, ensures that its
digitally signed by a trusted signer if it exists, and then
loads it and calls an unnamed function exported by the DLL. The Winlogon code
that executes when someone logs onto the system also
calls into the DLL if it was loaded during initialization.

I looked for the DLL on my system and didn't find it, and it's also not present
on the Service Pack 2 CD. So what is the DLL? Using
the debug symbols that Microsoft ships for the operating system I could see
Winlogon configure a variable named "Creekside" if
ediskeer.dll is present and signed and then I realized that "ediskeer" consists
of the last 8 letters of "creekside" in reverse
order. I'm still not sure what Creekside refers to, but I strongly suspect that
the DLL is one that ships only with Windows XP
Starter Edition, the low-cost version of Windows XP that Microsoft recently
introduced for developing countries. Starter Edition is
based on the same operating system core as Windows XP Professional and Home
Editions, but it imposes limits on the number of
applications a user can have concurrently running. If I'm correct, Winlogon
loads the DLL to enforce that limit, activating it every
time a new user logs on.

Over the years Bryce and I have gotten numerous requests for a Registry-analogy
for Chkdsk, the file system consistency checking
utility. We've never written one because we've felt the audience for one is too
small to justify the effort. About a year ago
Microsoft released the little-known Chkreg, a Chkdsk for the Registry that fixes
many types of Registry corruption.

Unfortunately, Chkreg is only supported on Windows 2000 (it may also work on
Windows NT 4 and Windows XP Registries) and is
implemented as a "native" application that uses the native API instead of the
Windows API and so it won't run under Windows. When
you download it you'll have to install it to a set of six Windows setup boot
floppies, a tedious and time-consuming affair. We've
contacted the developers of Chkreg and encouraged them to publicly release the
Windows version that we've learned that Microsoft
Product Support Services (PSS) is using in-house, but have no word on when or if
they will release it.

You can download Chkreg at

One of the most frustrating experiences for a Windows user is a crashing system.
In most cases the fault is a buggy 3rd-party device
driver, which you can remedy by disabling the driver or updating to a version
with a fix. About 10% of crashes reported to Microsoft
Online Crash Analysis (OCA) are caused by hardware problems, the majority of
which are disk and memory-related.

If you get crashes that OCA is unable to diagnose or you suspect a memory
problem then you should spend a few minutes with the
Microsoft Windows Memory Diagnostic (WMD), a memory checking tool Microsoft
recently released. The installer for WMD asks for a
floppy disk or CD to which it saves the WMD program. When you boot a machine
from the floppy or CD you created WMD runs and performs
a thorough test of the computer's memory, reporting its progress and any
problems to the screen. If you have memory errors WMD can
save you the frustration endless of Windows crashes.

You can download the Windows Memory Diagnostic at

The DEP status feature I describe in the section on Process Explorer
enhancements earlier in the newsletter relies on an
undocumented function. I thought many of you would be interested in learning how
I discovered, without access to Windows source code
(Dave Solomon, my coauthor for Windows Internals, has access, but I don't), the
function and its proper usage.

The first step in my analysis process was to hypothesize that a DEP status query
for a process would route through the
NtQueryInformationProcess API. Many Windows API functions that retrieve
information about a process use the
NtQueryInformationProcess interface to obtain the information. This function,
which is prototyped in the Ntddk.h file of the Windows
Driver Development Kit (DDK), is accessible from user-mode through the "native
API" system call interface:

IN HANDLE ProcessHandle,
IN PROCESSINFOCLASS ProcessInformationClass,
OUT PVOID ProcessInformation,
IN ULONG ProcessInformationLength,

Its first two arguments are a handle to a process and a "process information
class". The PROCESSINFOCLASS enumeration, the first few
of definitions of which are shown below, is also included in NTDDK.H:

typedef enum _PROCESSINFOCLASS {

Since DEP was introduced in Windows XP SP2 I didn't expect the information class
for DEP queries to be listed in the Windows XP or
Windows Server 2003 versions of Ntddk.h, and a quick check confirmed its
absence. I therefore had to investigate a disassembly of SP
2's Ntoskrnl.exe, the image where NtQueryInformationProcess is implemented, to
see if I could determine the DEP query information
class empirically.

A disassembler takes an executable image and lists the assembly language
instructions that make up its code. Assembly language
instructions map directly to the instructions executed by a processor. The
disassembler that I use is IDA Pro from
http://www.datarescue.com since it understands Microsoft's debug information
files and will integrate the information into the
assembly language output. In the disassembly I discovered the convoluted
sequence of instructions at the start of
NtQueryInformationProcess that take the process information class parameter and
executes code specific to each class. Since I knew
that the information class was new, I could skip over the execution of the
classes for which I saw definitions in Ntddk's
PROCESSINFOCLASS enumeration. This narrowed my investigation to the roughly 3 or
4 new classes introduced since Windows XP's

One of the classes, the one that corresponds to a ProcessInformationClass value
of 0x22, took me through a code path into a function
named MmGetExecuteOptions, the start of which is shown here:

PAGE:0054D7CC ; __stdcall MmGetExecuteOptions(x)
PAGE:0054D7CC _MmGetExecuteOptions@4 proc near ; CODE XREF:
NtQueryInformationPro0063ess(x,x,x,x,x)+251C p
PAGE:0054D7CC arg_4 = dword ptr 8
PAGE:0054D7CC mov edi, edi
PAGE:0054D7CE push ebp
PAGE:0054D7CF mov ebp, esp
PAGE:0054D7D1 mov eax, large fs:124h
PAGE:0054D7D7 mov eax, [eax+44h]
PAGE:0054D7DA mov cl, [eax+6Bh]
PAGE:0054D7DD mov eax, [ebp+arg_4]
PAGE:0054D7E0 and dword ptr [eax], 0
PAGE:0054D7E3 xor edx, edx
PAGE:0054D7E5 inc edx
PAGE:0054D7E6 test dl, cl
PAGE:0054D7E8 jz short loc_54D7EC
PAGE:0054D7EA mov [eax], edx
PAGE:0054D7EC loc_54D7EC: ; CODE XREF:
MmGetExecuteOptions(x)+1C j
PAGE:0054D7EC test cl, 2
PAGE:0054D7EF jz short loc_54D7F4
PAGE:0054D7F1 or dword ptr [eax], 2
PAGE:0054D7F4 loc_54D7F4: ; CODE XREF:
MmGetExecuteOptions(x)+23 j
PAGE:0054D7F4 test cl, 4
PAGE:0054D7F7 jz short loc_54D7FC
PAGE:0054D7F9 or dword ptr [eax], 4

IDA Pro showed me on the first line in the above output that the function
accepts one argument, which I suspected to be a pointer to
a variable that receives the DEP settings. I've spent enough time looking
through disassemblies of the Windows kernel to recognize
the instruction sequence "mov eax, large fs:124h; mov eax,[eax+44h]" as a read
of the current thread _KTHREAD data structure in the
processor control region (PCR) structure followed by a reference of the KPROCESS
field at offset 0x44 in the _KTHREAD structure.
The instructions following those read individual bits in the byte at offset 0x6B
in the _KPROCESS structure.

Not knowing off hand what's at offset 0x6B in a _KPROCESS I launched Windbg in
local-kernel debugging mode and executed the command
"dt _kprocess", which reported this:

+0x06b Flags : _KEXECUTE_OPTIONS

Looking at that structure with another dt command showed the bit definitions:

+0x000 ExecuteDisable : Pos 0, 1 Bit
+0x000 ExecuteEnable : Pos 1, 1 Bit
+0x000 DisableThunkEmulation : Pos 2, 1 Bit
+0x000 Permanent : Pos 3, 1 Bit
+0x000 ExecuteDispatchEnable : Pos 4, 1 Bit
+0x000 ImageDispatchEnable : Pos 5, 1 Bit
+0x000 Spare : Pos 6, 2 Bits

Sure enough, these bits relate to DEP and it appears that MmGetExecuteOptions
copies them from that structure to the corresponding
bits in the memory location passed as the ProcessInformation argument to
NtQueryInformationProcess. I had therefore determined that
I could query the DEP status of a process by calling NtQueryInformationProcess
with a ProcessInformationClass of 0x22, the address
of a DWORD (4-byte integer), and a length of 4. It appears that
MmGetExecuteOptions returns the flags for the current process only
and ignores the ProcessHandle parameter (Process Explorer queries the DEP status
of other processes by having its helper driver
switch into them via the KeAttachProcess API).

I was done except for a couple of subtle differences on the 64-bit version of
Windows, since I make available a 64-bit version of
Process Explorer. On 64-bit Windows MmGetExecuteOptions requires that
ProcessHandle be -1 and it returns a STATUS_INVALID_PARAMETER
error if the current process is a 64-bit process, since DEP is always on for
64-bit processes. I used Windbg to disassemble the
64-bit version of Ntoskrnl.exe, though since then have obtained the version of
IDA Pro that supports AMD64 image disassembly.


I'm delivering two sessions at the Windows Connections conference, which is run
by Windows IT Pro Magazine and taking place April
17-20 in San Francisco. One is a general session called "Understanding and
Fighting Malware: Viruses, Spyware, and Rootkits" where I
describe how malware exploits vulnerabilities to propagate and bypass security
measures, how they hide using sophisticated
techniques called "rootkits" and how to detect them and clean them from your

The other session is "Troubleshooting Windows Memory Problems" where I show you
how to answer the age old "what are the meaning of
the values I see in Task Manager", "what's using my memory", and "how big should
I make the paging file" questions.

Download the conference brochure and register at

Spend 5 days with Mark Russinovich and David Solomon, authors of the new book
Windows Internals 4th edition, learning advanced
troubleshooting techniques while delving into the internals of the Windows
NT/2000/XP/2003 operating system kernel. If you're an IT
professional deploying and supporting Windows servers and workstations, you need
to be able to dig beneath the surface when things
go wrong. Having understanding of the internals of the Windows operating system
and knowing how to use advanced troubleshooting
tools will help you deal with such problems and understand system performance
issues more effectively. Understanding the internals
can help programmers to better take advantage of the Windows platform, as well
as provide advanced debugging techniques. And
because the course was developed with full access to the Windows kernel source
code AND developers, you know you're getting the real

Upcoming dates include:


NOTE: This is a hands-on class--each attendee must bring their own laptop
(configuration instructions will be sent ahead of time).

You'll gain an in-depth understanding of the kernel architecture of Windows
NT/2000/XP/2003, including the internals of processes,
thread scheduling, memory management, I/O, services, security, the registry, and
the boot process. Also covered are advanced
troubleshooting techniques such as malware disinfection, crash dump (blue
screen) analysis, and getting past boot problems. You'll
also learn advanced tips on using the key tools from www.sysinternals.com (such
as Filemon, Regmon, & Process Explorer) to
troubleshoot a range of system and application issues, such as slow computers,
virus detection, DLL conflicts, permission problems,
and registry issues. These tools are used on a daily basis by Microsoft Product
Support and have been used effectively to solve a
wide variety of desktop and server issues, so being familiar with their
operation and application will assist you in dealing with
different problems on Windows. Real world examples will be given that show
successful application of these tools to solve real

To register, visit http://www.sysinternals.com/troubleshoot.shtml

Thank you for reading the Sysinternals Newsletter.

Comments (23)
  1. Anonymous says:

    Fill advance card cash credit advance? cash loan online payday ?

  2. Anonymous says:

    How casino’ on line advance america cash advance

  3. Anonymous says:

    Play cash till payday loan advance cash loan loan payday

  4. Anonymous says:

    Commonly advance card cash credit advance cash loan online

  5. n0fteg0nh9 says:

    9d54pyfpfff <a href = http://www.412058.com/398566.html > wo8a32ldugwi </a> [URL=http://www.886653.com/643416.html] jhh1bop4 [/URL] 1q2xcku0z0a

Comments are closed.

Skip to main content