Systems Internals Tips and Trivia
Copyright © 1996-1999 Mark Russinovich
Last Updated February 22, 1999
----------------------------------------------------------------------------------
Miscellaneous NT Information
Introduction This page is an ever-expanding collection of NT information that I
accumulate over time. You'll find practical tips as well useless
trivia, with new items added at the top of the page.
Named Pipe Directory Listings
NT's \dev\kmem
Boot.ini Option Reference
Hidden Registry Keys?
Fault Tolerance on Workstation?
The Native API
Idle Trivia
Never-ending Quantum?
NT's Main
Tuning Workstation for Server-like Loads
Named Pipe Did you know that the device driver that implements named pipes is
Directory actually a file system driver? In fact, the driver's name is
Listings NPFS.SYS, for "Named Pipe File System". What you might also find
surprising is that its possible to obtain a directory listing of
the named pipes defined on a system. This fact is not documented,
nor is it possible to do this using the Win32 API. Directly using
NtQueryDirectoryFile, the native function that the Win32 FindFile
APIs rely on, makes it possible to list the pipes. The directory
listing NPFS returns also indicates the maximum number of pipe
instances set for each pipe and the number of active instances.
To demonstrate the listing of named pipes I've written a program
called PipeList. PipeList displays the named pipes on your system,
including the number of maximum instances and active instances for
each pipe. Full source code is included.
Download PipeList (25KB)
NT's Many UNIX afficianados like to point out that UNIX has a flexible
"\dev\kmem" file system namespace that allows non-file system devices and
psuedo-devices to be accessed through it. The most commonly offered
example of this feature is the \dev\kmem file. When an application
opens and reads or writes this file (assuming it has permission to
do so) it is actually accessing the physical memory of the
computer.
What most people don't know is that NT charges its Object Manager
subsystem with providing a namespace (see my article on the Object
Manager for more information), and the Object Manager allows
virtually anything to be mapped as part of it, just like UNIX's
file system namespace. And what even fewer people know is that NT
does have an equivalent of \dev\kmem. Its a section (memory
mapping) object that is named \Device\PhysicalMemory in NT's
namspace (you can verify its existance by using our WinObj tool).
An application with sufficient access rights can open the section
and map portions of it into its own address space. The result of
such a mapping is the creation of a window to physical memory in
the application's virtual address map. By default administrators
have read-only access to physical memory, but it is possible for an
application running as administrator to modify the security
attributes so that write access is enabled.
In order to demonstrate the ability to view physical memory, and to
give you the opportunity of browsing through your computer's RAM,
I've written PhysMem. It is a Win32 console program that will open
the physical memory section and dump the contents of regions (in
hexadecimal and ASCII) that you specify in a simple command-line
interface. Here is what the interface looks like:
Physmem v1.0: physical memory viewer
By Mark Russinovich
Systems Internals - http://www.sysinternals.com
Enter values in hexadecimal. Enter 'q' to quit.
Address: 1000
Bytes: 1000
00001000: 4D 5A 90 00 03 00 00 00 -04 00 00 00 FF FF 00 00
MZ..............
00001010: B8 00 00 00 00 00 00 00 -40 00 00 00 00 00 00 00
+...............
00001020: 00 00 00 00 00 00 00 00 -00 00 00 00 00 00 00 00
................
00001030: 00 00 00 00 00 00 00 00 -00 00 00 00 80 00 00 00
................
00001040: 0E 1F BA 0E 00 B4 09 CD -21 B8 01 4C CD 21 54 68
..¦....-.+.L-.Th
00001050: 69 73 20 70 72 6F 67 72 -61 6D 20 63 61 6E 6E 6F is
program canno
00001060: 74 20 62 65 20 72 75 6E -20 69 6E 20 44 4F 53 20 t be run
in DOS
00001070: 6D 6F 64 65 2E 0D 0D 0A -24 00 00 00 00 00 00 00
mode............
00001080: 50 45 00 00 4C 01 06 00 -53 3A 4D 33 00 00 00 00
PE..L...S.M3....
...
While you are browsing your memory, some places of interest you
might want to take a look at are offset 0x1000, which is where
NTLDR is located (you can see its header in the example output
above, which states that it can't be run in DOS mode), and
0xF9000-0xFFFFF, which is where ROM BIOS is mapped. You'll likely
see strings belonging to the vendor of your computer and sometimes
video adapter strings in the BIOS.
The source code for PhysMem is fairly self-explanatory. PhysMem
uses the native API to open and map \Device\PhysicalMemory because
that name is inaccessible via the Win32 API. It also uses the
native APIs (all of which are documented in the Windows NT DDK) to
map and unmap views of the section, though this could have been
done using Win32.
Download PhysMem (28KB)
Hidden A subtle but significant difference between the Win32 API and the
Registry Native API (see Inside the Native API for more information on this
Keys? largely undocumented interface) is the way that names are
described. In the Win32 API strings are interpreted as
NULL-terminated ANSI (8-bit) or wide character (16-bit) strings. In
the Native API names are counted Unicode (16-bit) strings. While
this distinction is usually not important, it leaves open an
interesting situation: there is a class of names that can be
referenced using the Native API, but that cannot be described using
the Win32 API.
How is this possible? The answer is that a name which is a counted
Unicode string can explicitly include NULL characters (0) as part
of the name. For example, "Key\0". To include the NULL at the end
the length of the Unicode string is specified as 4. There is
absolutely no way to specify this name using the Win32 API since if
"Key\0" is passed as a name, the API will determine that the name
is "Key" (3 characters in length) because the "\0" indicates the
end of the name.
When a key (or any other object with a name such as a named Event,
Semaphore or Mutex) is created with such a name any applications
using the Win32 API will be unable to open the name, even though
they might seem to see it. The program below, RegHide(source code
is included), illustrates this point. It creates a key called
"HKEY_LOCAL_MACHINE\Software\Systems Internals\Can't touch me!\0"
using the Native API, and inside this key it creates a value. Then
the program pauses to give you an opportunity to see if you can
view the value using any Registry editor you have handy (Regedit,
Regedt32 or a third-party Registry editor). Because Regedit and
Regedt32 (and likely an third party Registry editor) use the Win32
API, they will see the key listed as a child of Systems Internals,
but when you try to open the key you'll get an error. This is
because the Registry editor will try to open "Can't touch me!"
without the trailing NULL (which is interpreted as the end of the
string) and won't find this name. After you've verified this exit
the program and this special key will be deleted.
Download RegHide (24KB)
Fault One of the differences I highlighted in my November 1996 Windows NT
Tolerance on Magazine article, "Inside the Difference Between Windows NT
Workstation? Workstation and Windows NT Server," was that fault tolerant disk
configurations are only available on Server. This is because the
Windows NT disk administrative program, Windisk.exe, checks to see
if its running on a Workstation, and if so, does not display its
Fault Tolerance menu, which contains the entries that are used to
create mirrors and parity striped sets.
It turns out that whoever wrote the Workstation Resource Kit
program FTEDIT was unaware of Microsoft's official policy on fault
tolerance and Workstation: it appears you can use this utility to
create mirrors and striped sets with parity on Workstations.
Update: several people have complained that this doesn't work,
which isn't surprising since I left out an important step: the
Fault-tolerant disk driver must be enabled. If you have an existing
volume-set then it is already is, but if you don't, use a Registry
editor to set the value of:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\FtDisk\Start
to 0. The next time you boot your workstation, the fault-tolerant
drives you have created will be functional.
The Native NT's native API are services that are core operating system
API services available to device drivers and user-mode applications.
The Win32 subsystem relies heavily on this API, as do many
Microsoft Windows NT Resource Kit utilities. There are over 200
system calls in NT's native API and only 21 of them are documented
by Microsoft.
Idle Trivia Did you know that unlike all the other threads in an NT system, the
idle-thread executes at an IRQL (interrupt request level) of
DISPATCH_LEVEL (rather than PASSIVE_LEVEL)? See Advanced DPCs for
more information.
On uniprocessor x86 systems the idle-thread actually performs a HLT
(Halt) instruction, which effectively turns the CPU off to
everything except for hardware interrupts.
Never-ending In NT, as with most time-sharing operating systems, threads run in
Quantum? turns called quantums. Normally, a thread executes until its
quantum runs out. The next time it is scheduled it starts with a
full quantum. However, in NT a thread also gets its quantum
refreshed every time its thread or process priority is set. This
means that a thread can reset its quantum by calling
SetThreadPriority (without changing its priority) before its turn
runs out. If it continues to do this it will effectively have an
infinite quantum. Why does NT do this? Its not clear, but it
appears to be a bug.
NTOSKRNL's NTOSKRNL.EXE, the core file of the kernel-mode component of Windows
Main NT, contains the Cache Manager, the Executive, the Kernel, the
Security Reference Monitor, the Memory Manager, and the Scheduler,
among other things, and is in charge of getting NT up and running.
You may be surprised to know that it has a standard main() that is
executed when it is loaded by the OSLOADER:
//
// NTOSKRNL main
//
int main()
{
//
// Fire up NT!
//
KiSystemStartup();
return 0;
}
Tuning NT Workstation and NT Server have vastly different performance
Workstation characteristics due to the internal tuning that the NT operating
for system, which is identical on both, performs. Most tuning
Server-like parameters are inaccessible, but a few are located in the Registry.
Loads If you are running Server and you double-click on the Server entry
of the Services tab in the Control Panel's Network applet, you will
get a dialog that lets you determine what type of application you
want the machine to be tuned for. Choices let you select between
"Minimize Memory Used", "Balance", "Maximize Usage for File
Sharing", and "Maximize Usage for Network Applications". This
dialog box is not presented on Workstation installations. The
various selections actually change the values of two Registry
values:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory
Management\LargeSystemCache
and
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\Size
This table (which was derived from sessions with NTRegmon) presents
the settings you should select on a Workstation to achieve the same
effect you would get using the dialog box were your system a
Server.
Tuning Target LargeSystemCache Size
Minimize Memory Used 0 1
Balance 0 2
File Sharing 1 3
Network Applications 0 3
----------------------------------------------------------------------------------
[Image]