+7 (495) 668-0-866
Среда, ноября 22, 2017

Справка по системам NT

 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]


  • Среда, 02 мая 2012

Оставить комментарий

Вы комментируете как Гость.

Эта форма защищена Aimy Captcha-Less Form Guard