Increase registry size windows xp

Larger Registries are required to support Terminal Server systems with hundreds of active users. The Configuration Manager has also been recoded to minimize lock contention on key control blocks, as well as the in-memory data structures that represent Registry keys, and to pack Registry data more tightly in memory as the system is running. Finally, to further minimize memory footprint, the Configuration Manager maintains a security cache in memory to store security descriptors that are used by more than one key.

By doing this, if a device driver attempted to modify a read-only part of the operating system, the system would crash immediately with the finger pointing at the buggy driver, instead of allowing the corruption to occur later and result in a system crash that is difficult to diagnose.

However, for performance reasons, Windows does not attempt to map any parts of the kernel and hardware abstraction layer HAL as read-only pages if more than MB of physical memory is present.

This is because on such systems, these files and other core operating system data such as initial nonpaged pool and the data structures that describe the state of each physical memory page are mapped with 4MB "large pages" as opposed to the normal 4KB page size on the x 86 processor set. By mapping this core operating system code and data with 4MB pages, the first reference to any byte within each 4MB region results in the x 86 memory management unit caching the address translation information to find any other byte within the 4MB region without having to resort to looking in page table data structures.

This speeds address translation. The Windows XP change was needed because of the continual increase in typical memory configurations of PC systems. The minimum memory to use large pages is now more than MB, instead of more than MB. Finally, note that large pages are never used if Driver Verifier is active. The way Windows XP decides which pages to remove in working sets when the system needs to create additional free pages is greatly improved for multiprocessor systems.

In Windows , pages in working sets are aged, meaning the system increments a count every time it visits a page in a working set if the page has not been accessed since the last time it was scanned. In this way, when the system needs to trim a working set to create free pages, it can remove pages that have not been referenced the longest. However, this algorithm was performed on uniprocessor systems only. Windows XP page aging is done on multiprocessor systems as well.

A number of critical internal locks used to synchronize access to various internal memory management data structures have been either removed completely or optimized, resulting in much less contention.

The following operations no longer involve acquiring locks: charging nonpaged and paged pool quotas, allocating and mapping system page table entries, charging commitment of pages, and allocating and mapping physical memory allocated through the address windowing extensions AWE functions.

Access to the lock that synchronizes access to the structures that describe physical memory the PFN database has been improved. These changes translate into greater parallelism and scalability on multiprocessor systems, since the number of times the memory manager may have to block while another CPU is making a change to a global structure has been reduced or eliminated. Windows XP introduces a new locking mechanism, called push locks, as a synchronization mechanism for protecting pageable data in kernel mode.

The advantages of push locks over the alternative mechanisms used prior to Windows XP are that they require only the size of a pointer in storage 4 bytes on bit Windows XP and 8 bytes on bit Windows XP , and acquisition and release are performed without the use of kernel mode spin locks if there is no contention on the push lock.

This new approach to locking improves both performance and scalability in a multiprocessor environment. However, these other synchronization objects are larger and utilize spin locks during acquisition and release which lock a multiprocessor's bus for an instant, which reduces scalability , making push locks attractive.

The areas of the operating system where push locks have been retrofitted include the Object Manager, where they protect global Object Manager data structures and object security descriptors, and the Memory Manager, where they protect AWE data structures. The place where they have the most impact on system performance, however, is in their use to protect handle table entries in the Executive.

One other performance improvement is in the area of system call dispatching. Those familiar with the internals of Windows NT associate the assembly language instruction "INT 0x2E" with system calls, since it's with this instruction that Windows NT and Windows transition from user mode to the kernel-mode system call interface where the native API is implemented.

Many Win32 APIs invoke system calls. This instruction sequence requires fewer clock cycles to execute, improving the speed of system calls. One of the goals of Windows XP was to improve the user experience. Users consider boot and application startup time to be a big part of the experience.

Therefore, developers at Microsoft have spent a great deal of effort on improving the performance of the boot process and application startup. They've addressed this in several ways. Now serial and networking device drivers initialize in parallel, unlike in Windows where they initialize serially. Logons are allowed sooner, laptops can hibernate and resume more quickly, and applications start faster. If your account doesn't depend on a roaming profile, and a domain policy that affects logon hasn't changed since your last logon, Winlogon doesn't wait on the workstation service which waits on networking services to start before presenting the logon dialog and allowing a user to log on.

This means disconnected laptop users with domain accounts won't be held up during logon as their system times out to look for a domain controller. The implementation of hibernation has been revamped for better performance. When the operating system hibernates, it informs device drivers to stop operations on their devices.

When the computer resumes, the operating system loader reads the contents of the hibernation file into memory and tells device drivers to restart their devices, after which the computer is back to the state it was in before the power-off. The hibernation improvements come in several areas. The Power Manager compression algorithm, which it uses to compress the contents of memory before writing it to disk, has been improved to both run faster and obtain better compression ratios than in Windows Other changes help resume-from-standby and hibernation performance.

For example, the resume code in NTLDR, the component that reads a hibernation file's contents into memory, has been streamlined to perform larger, more sequential reads.

When a system is running on battery DC power , the Power Manager automatically adjusts the processor's clock rate to accommodate the processing demands of applications, throttling back the speed during idle periods to save power.

All versions of Windows except real-mode Windows 3x are demand-paged operating systems, where file data and code is faulted into memory from disk as an application attempts to access it. Data and code is faulted in page-granular chunks where a page's size is dictated by the CPU's memory management hardware. A page is 4KB on the x Prefetching is the process of bringing data and code pages into memory from disk before it's demanded.

In order to know what it should prefetch, the Windows XP Cache Manager monitors the page faults, both those that require that data be read from disk hard faults and those that simply require that data already in memory be added to a process's working set soft faults , that occur during the boot process and application startup. By default it traces through the first two minutes of the boot process, 60 seconds following the time when all Win32 services have finished initializing, or 30 seconds following the start of the user's shell typically Microsoft Internet Explorer , whichever of these three events occurs first.

The Cache Manager also monitors the first 10 seconds of application startup. After collecting a trace that's organized into faults taken on the NTFS Master File Table MFT metadata file if the application accesses files or directories on NTFS volumes , the files referenced, and the directories referenced, it notifies the prefetch component of the Task Scheduler by signaling a named event object. The Task Scheduler then performs a call to the internal NtQuerySystemInformation system call requesting the trace data.

The file's name is the name of the application to which the trace applies followed by a dash and the hexadecimal representation of a hash of the file's path. The file has a. Only after the Cache Manager has finished the boot trace the time of which was defined earlier does it collect page fault information for specific applications. When the system boots or an application starts, the Cache Manager is called to give it an opportunity to perform prefetching.

The Cache Manager looks in the prefetch directory to see if a trace file exists for the prefetch scenario in question. If it does, the Cache Manager calls NTFS to prefetch any MFT metadata file references, reads in the contents of each of the directories referenced, and finally opens each file referenced.

It then calls the Memory Manager to read in any data and code specified in the trace that's not already in memory. The Memory Manager initiates all of the reads asynchronously and then waits for them to complete before letting an application's startup continue. How does this scheme provide a performance benefit? The answer lies in the fact that during typical system boot or application startup, the order of faults is such that some pages are brought in from one part of a file, then from another part of the same file, then pages are read from a different file, then perhaps from a directory, and so on.

This jumping around results in moving the heads around on the disk. Microsoft has learned through analysis that this slows boot and application startup times. By prefetching data from a file or directory all at once before accessing another one, this scattered seeking for data on the disk is greatly reduced or eliminated, thus improving the overall time for system and application startup.

Figure 1 shows the contents of a prefetch directory, highlighting the layout file. Then it launches the system defragmenter with a command-line option that tells the defragmenter to defragment based on the contents of the file instead of performing a full defrag. The defragmenter finds a contiguous area on each volume large enough to hold all the listed files and directories that reside on that volume and then moves them in their entirety into that area so that they are stored one after the other.

Thus, future prefetch operations will even be more efficient because all the data to be read in is now stored physically on the disk in the order it will be read. Since the number of files defragmented for prefetching is usually only in the hundreds, this defragmentation is much faster than full defragmentations. It runs on the new Intel Itanium processor at one time internal builds of Windows were running in native bit mode on the Compaq Alpha AXP processor, but this was never released.

To port Windows XP to Itanium was a major development effort. First, the architecture-specific code in the kernel, memory manager, and HAL had to be written from scratch. This includes support for trap dispatching, context switching, and the new three-level page table structure. Then, thousands of changes were required to get the millions of lines of code that comprise Windows XP to compile and run properly using the native bit compiler and data types. However, the end result is a system that feels like its bit counterpart.

In fact, there are virtually no visible differences to the user or administrator other than text on the system properties page and various system display utilities that report processor type, and the fact that the new Visual Styles, like the Luna theme, are not supported on bit Windows; only classic-style Windows is supported.

The most significant change is, of course, the fact that the virtual address space is huge compared to bit Windows. While 32 bits provides 4GB of address space, 64 bits means over 17 billion GB 16 exabytes of available address space. However, the way this address space is divided and laid out is quite different.

Whereas bit Windows divides the address space in half—2GB for user processes and 2GB for system space—bit Windows provides GB to each user process. Figure 2 bit Address Space Layout This larger virtual address space means applications can process vast amounts of data in a flat address space without resorting to mapping tricks like the AWE introduced in Windows that allow bit applications to utilize more than 2GB of memory.

Also, since the address space for the operating system is much larger, key system memory pools can be much larger now.

This translates to the ability for the system to run more and bigger programs, load more and bigger device drivers, and cache more data. These larger limits are detailed in Figure 3. Itanium runs firmware that's compliant with the new Extensible Firmware Interface EFI , a specification that is maintained by a consortium of companies.

For example, all disk offsets in the partition table are bit instead of bit quantities, and the partition table information is mirrored at the start and end of a disk. Furthermore, there's no nesting of partitions as is required in MBR partitioning when there are more than four partitions on a disk. Rather than physically accessing XP's Iconcache. By default, Windows XP doesn't reserve a lot of memory for icon caching. By sacrificing a little bit of RAM, you can speed up perceived workstation performance.

Speeding things up You'll make the changes in the system registry. In the right pane, look for the value named Max Cached Icons. If the value exists, it's probably set to , which is the default value for the key. To change the value, double-click it. You'll then see the Edit String screen. Enter a value of in the Value Data field and click OK. If the value doesn't exist, you'll need to add it.

Select New String Value from the Edit menu. The new value will appear in the right pane, prompting you for a value name. Type Max Cached Icons and press [Enter]. Therefore, regardless of the size of the registry data, it is not charged more than 4 megabytes MB. Windows Server with SP1, Windows Server and Windows XP: There are no explicit limits on the total amount of space that may be consumed by hives in paged pool memory and in disk space, although system quotas may affect the actual maximum size.

The maximum size of the system hive is limited by physical memory as shown in the following table. Registry data is stored in the paged pool, an area of physical memory used for system data that can be written to disk when not in use. The RegistrySizeLimit value establishes the maximum amount of paged pool that can be consumed by registry data from all applications.

This value is located in the following registry key:. By default, the registry size limit is 25 percent of the paged pool. The default size of the paged pool is 32 MB, so this is 8 MB. If the value of this entry is greater than 80 percent of the size of the paged pool, the system sets the maximum size of the registry to 80 percent of the size of the paged pool.

This prevents the registry from consuming space needed by processes.