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.
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.
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.
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 |