|
Last
updated February 22, 1999
|
|
|
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 |
|
| Did you know that the
device driver that implements named pipes is actually
a file system driver? In fact, the driver's name
is 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)
Related tip: You can watch named pipe activity with
Filemon by selecting the Drives, Named Pipe menu
entry. |
| |
|
Many UNIX afficianados
like to point out that UNIX has a flexible 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 has a mechanism that lets an application
view (and even modify, with the proper security
configuration) a system's physical memory. 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
Sysinternals
- 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)
|
|
A subtle
but significant difference between the Win32 API
and the Native API (see Inside the Native API for more information
on this 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\Sysinternals\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
Sysinternals, 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) |
|
| One of
the differences I highlighted in my November 1996
Windows NT Magazine article, "Inside
the Difference Between Windows NT 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.
|
|
| NT's native
API are services that are core operating system
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. |
|
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. |
|
| In NT,
as with most time-sharing operating systems, threads
run in 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.EXE,
the core file of the kernel-mode component of Windows
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( boot parameters )
{
//
// Fire up NT!
//
KiSystemStartup();
return 0;
}
|
|
| NT Workstation
and NT Server have vastly different performance
characteristics due to the internal tuning that
the NT operating system, which is identical on both,
performs. Most tuning parameters are inaccessible,
but a few are located in the Registry. 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
Regmon) 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
|
|
|
Back to Top |
|
|
|
|
