Vista business memory limit




















The operating system therefore has more work to do when preparing and maintaining the page tables, and since the Translation Lookaside Buffer TLB has only half the capacity, memory references are more likely to miss the TLB and require additional bus cycles. The reduction in performance is surely measurable. If you have no need to access memory above 4GB and are concerned enough, then you would not enable PAE if performance is all that matters.

Note however that Microsoft does not regard this performance cost as worth troubling over as will be clear shortly, under the heading Data Execution Prevention. For this comparison, not only are the PTEs the same size but the algorithms are very similar. These are very fine trade-offs relative to the enormous overheads that embellish some of the wilder misunderstandings of PAE on the Internet.

Surely this is meant to have some objectivity, even if comparison of ratings for bit and bit Windows may not be strictly fair. Whether the memory manager in the Windows kernel uses PAE is configurable through the pae boot option. Indeed, bit Windows Vista is supplied with two kernels:. EXE, both in the Windows System directory. EXE knows how to set up the linear address space for mapping to physical addresses with or without PAE, but each kernel is specialised to one algorithm for the mapping. The pae option tells the loader which kernel to load.

This is not so that you can use physical memory above 4GB, else this article would not exist. This protects you from programs that try to execute data, whether in error or from suspected malice. In practice, much of that range of physical address space, most likely at the top, is given over to such things as the system BIOS and devices. What this gives you, however, is at best only an indication. It tells you that some addresses are used for devices. The memory map that matters most for the question of what physical memory the kernel can use is the map that the loader discovers from the firmware.

However, Windows Vista introduces some undocumented functions with which a kernel-mode driver can get the map fresh from the BIOS. Such a driver for viewing the firmware memory map is presented separately, along with a small console application that reports the results.

You will need administrative privilege to load the driver. On this machine, with its present configuration of hardware, if the kernel is limited to the first 4GB as its physical address space, then MB and the spare change is all the RAM that the kernel can possibly use. Get the kernel to recognise physical addresses above 4GB, and it picks up the other 5GB, for a total of MB as shown in the picture.

If the 4th gigabyte were left at 3GB, Windows would have access only to as much of it as does not get overridden. Whether this remapping is done at present on your particular machine can be checked by using the separately supplied driver.

If it is not done, then whether it can be arranged is an issue of hardware configuration. Of course, for a machine that has exactly 4GB of RAM and has bit Windows Vista pre-installed, you would expect that the manufacturer, having been told by Microsoft that Windows will not see any RAM above 4GB, might not have configured any of the 4GB to be remapped out of sight and into uselessness.

You should not be surprised to find that remapping is disabled. Worse, unless the manufacturer anticipates installing other Windows versions on the machine, there is no incentive even to provide for remapping above 4GB as something that you can configure if you want. If your chipset does not support remapping, then RAM that is overridden for device memory below 4GB will never be seen as usable RAM by bit Windows even with PAE enabled and is just as much lost to you if you install bit Windows.

Broadly speaking, there are two mechanisms by which your hardware and firmware can provide for memory above 4GB which Windows will then not try to use. One is that the kernel never learns of any such memory. The other is that the kernel knows the memory is there but deliberately ignores it.

The first of these mechanisms comes about from a boot option, named truncatememory , which tells the loader to discard all pages of physical memory that are not wholly beneath some specified address.

Thereafter, the discarded memory may just as well never have been reported by the firmware. When the kernel receives the memory map from the loader, memory at and above the truncatememory cut-off is already long gone from the map. By the time the kernel receives the memory map from the loader, the map has been much refined in order to account for how memory is already in use, but it is otherwise intact as a report of physical memory that the kernel can use.

Limits are applied both to the total amount of usable memory and to the maximum physical address. Memory in excess of these limits is discarded, such that although it was passed to the kernel from the loader, it may as well not have been.

The total amount of memory allowed is taken solely from the license value Kernel-WindowsMaxMemAllowedx86 , as read through the undocumented function ZwQueryLicenseValue. The data for this value is a number of MB, so that 0x, which is installed for all bit editions of Windows Vista, means 4GB. The maximum physical address is calculated as the least of three values: a license limit; a run-time limit; and a hard-coded limit.

For the ordinary kernel, the license value for the maximum physical address is the same as for the total amount of memory, but the PAE kernel has a separate license value, named Kernel-MaxPhysicalPage.

Again, the data for this value is a number of MB. Again, all bit editions of Windows Vista are installed with this value set to 0x, representing 4GB. The run-time limit arises from needing to be sure that an array of MMPFN structures can be set up to represent all the pages of physical memory, one structure per 4KB page, from zero up to the maximum physical address.

This gives the run-time limit on the maximum physical address. The preceding calculation also produces an architectural limit on the use of physical memory by bit Windows with a PAE kernel. The largest block of linear address space that is available even this early cannot be as large as 1GB and could be much smaller. For the question of whether the kernel in bit Windows Vista will use all the physical memory it learns about from the loader, the hard-coded limit of 4GB is dominant as the maximum address for the ordinary kernel, which truly cannot form addresses for physical memory above 4GB, but the license limit is dominant for the PAE kernel.

If you have physical memory above 4GB and wonder how it can be that the PAE kernel does not use that memory, the answer is licensing. Code for using memory above 4GB is present in bit Windows Vista as Microsoft supplies it, but Microsoft prepares license values in the registry so that this code never gets to work with any physical addresses above 4GB.

Microsoft is not exactly forward in describing this mechanism by which bit Windows Vista is restricted to 4GB. Some explanation may be that Microsoft takes licensing so much for granted that it is simply left as understood that the stated limits on physical memory are licensing limits. Though no drivers need to know the mechanics of PAE and only a small proportion work at all with physical addresses, they may be indirectly incompatible with PAE because as explained earlier they have been coded to an assumption that the physical address space is the same size as the linear address space.

This is not to say that Microsoft ought to allow such usage, just that the reasoning that Microsoft gives for its solution does not of itself compel that solution. Anyway, how significant could these incompatibilities be in real-world use of Windows Vista?

The drivers that Microsoft talks about are not the sort of things that users install willy-nilly. They are much more the sort that come installed with a new computer, such that they have been tested or ought to have been by the manufacturer. Moreover, as noted earlier, the main types of coding error that are exposed by using memory above 4GB on bit Windows are as much a problem to bit Windows.

It is beyond incredible that these errors are retained in bit drivers that have been ported to bit. However significant may have been the problems of bit drivers and hardware for the safe use of memory above 4GB by bit Windows in earlier versions, the natural expectation must therefore be that they are rapidly being eliminated from real-world occurrence by the widespread adaptation of those drivers to support bit Windows Vista.

Even Microsoft looks to be uncertain of its ground when talking about these incompatibilities. Another paragraph that Microsoft presents as More Information is even worse.

These errant drivers will still miscalculate the location of every PTE that they want to modify. If fear of this is an argument against using memory above 4GB, then it is just as much an argument against enabling DEP.

Yet Microsoft recommends that DEP should always be enabled. Add that Microsoft seems nowhere to say outright that bit Windows Vista already has the code for using memory above 4GB, and they look more like the sort of arguments someone might pass off to rationalise a decision made on other grounds.

I just smell something fishy when technical reasons and good engineering do not of themselves compel exactly what Microsoft has implemented, which Microsoft anyway does not present transparently to potential customers. Instead, the decision stands on ignorance: many customers are left with their mistaken belief that use of memory above 4GB is impossible for any bit operating system, and very few are well enough informed to know that working code for the use of such memory is already in the particular bit operating system known as Windows Vista.

See that the difficult-to-measure risk is merely asserted despite an acknowledgement that it seems implausible for new computers. Better instead to provide cover for moving consumers to bit Windows faster than they might otherwise go. Just accept it without question and be glad for the new business as consumers who install bit Windows start buying bit applications which they might otherwise do without for a while.

Who in the computer industry—whether a manufacturer of hardware or software, or even a commentator whom some might think is an independent analyst—is going to criticise Microsoft for a sleight of hand that brings forward a cycle of upgrades! If nothing else, when consumers pay for a software product in an edition that the manufacturer describes as Ultimate, they surely have a reasonable expectation that the software is licensed to do everything that its code is capable of.

If you buy only the Home Basic edition instead of Home Premium, then you expect to get less software and be licensed to use fewer features. But surely the point to an edition that is called Ultimate is that you get the whole package and are licensed to use it all. Note that this is not a case of a manufacturer puffing up a product description. An irony is that the very same driver incompatibilities that Microsoft talks of as a danger to users would surely have been eliminated—long ago—by the natural forces of competition among driver developers and device manufacturers except that Microsoft for many years misled those developers and manufacturers to believe that the bit client editions of Windows could not use memory above 4GB when in fact they could see below, under the heading Past.

That Microsoft now points its finger at the driver writers without acknowledging the part played by its own substantial influence is at best distasteful. By designing bit Windows for memory above 4GB but licensing all but exotic editions only for memory below 4GB, Microsoft suppressed competition in the subsidiary market of computers that run Windows.

Certainly, consumers have been worse off for not having the competition. When Microsoft and others make out that defective drivers are so widespread and dangerous that bit Windows Vista cannot be allowed to use memory above 4GB even as a configurable option, how is anyone to know the truth of it?

The closest that anyone can come is to test with bit Windows Server , which hardly any consumers ever get to see, and which of course was not available until some time after Windows Vista was first released. Even to begin to test whether a particular installation of bit Windows Vista cannot safely use memory above 4GB because of driver incompatibilities, you must somehow side-step the two relevant license values.

Let me stress that although I have to modify the kernel, using memory above 4GB does not require a change to even one byte of code. That I modify any code here is merely to simulate the provision of different license data by Microsoft. Much as you can buy Windows Vista Home Basic and then upgrade to Home Premium without having to reinstall Windows, you might upgrade to a configuration in which the two license values for memory limits are raised. Because Microsoft protects those license values, this patch is as close to that upgrade as can be arranged unless Microsoft makes the license upgrade available.

If you patch the kernel and your tests then show to your satisfaction that your drivers are safe though perhaps only after you disable defective drivers and install the latest updates from their manufacturers , then a license upgrade from Microsoft is what I intend you to seek.

You should understand now, i. My only hand in these offerings is that they draw from what I have written here. Most do not acknowledge their source. Some even claim to have devised their kernel patch independently. That a search through Google showed little or nothing about the relevant licence values and absolutely nothing like this patch is the main reason that I ever did get round to writing this article after sitting on the information since mid Except for that, I cannot help you choose one over another.

The known builds have an internal routine named MxMemoryLicense in which there are two sequences of nearly identical code, one for each relevant license value.

Each sequence calls the undocumented function ZwQueryLicenseValue and then tests for failure or for whether the data that has been read for the value is zero. In the known builds, each sequence has the following instructions in common:. At the time of executing, the eax register holds the status code from ZwQueryLicenseValue.

The first instruction is the test for failure indicated by a negative status code. The remaining instructions test whether the retrieved data is zero. In the known builds, the xx and yy placeholders are 0x11 and 0x0A respectively for the first sequence and 0x10 and 0x09 for the second, but even with the placeholders left unresolved, the sequence shown occurs just twice in the whole kernel. This may help you find the patch sites even if you have a different build such as you may have picked up from Windows Update.

Both occurrences are to be patched the same way. The patch is designed to vary the ordinary execution as little as possible. Change the 7 bytes starting from 0x8B so that you now have the following instructions:. The following table lists the English-language builds of the PAE kernel for some known releases of bit Windows and gives the file offsets for the two patch sites:. If you are not completely certain how to interpret file offsets, to check the bytes and to edit them, then do not try to patch the file.

Even if you think you know what you are doing, please take care to work on a copy. Since patching the kernel will almost certainly have invalidated this stored checksum, you need to reset it.

Signing the code, as discussed under the next heading, will do this. The command to run is. It is sometimes said that kernel-mode drivers are not checked for digital signatures in bit Windows, or more accurately that although hashes are computed, drivers are not rejected if the hash is not validated by a signature. The kernel is one of them, of course.

It must be signed by a certificate that derives from one of a handful of root certficates whose public keys are hard-coded into the loader. One of these exceptions is a Test Mode which Microsoft provides so that drivers can be tested during development.

In this sense, Test Mode is the most appropriate way around the digital signature. In Test Mode, the loader relaxes its integrity checking such that any root certificate is accepted. There is a price however: Test Mode has the detraction of placing small warnings on the desktop. With these, you can make your own certificate by running some such command as. MSC , which also lets you set a Friendly Name for the certificate if you want to keep it.

To sign your modified kernel with this certificate, run the command. Note that you do not need administrative privilege for these steps. Also, you can self-sign the kernel on one machine but test it on another. There is no need to transfer the certificate to the test machine. Indeed, there is no more need to keep the certificate. You can delete it from the Personal store either through the user interface of the Certificate Manager or by running the command.

You now have a modified kernel with which to test your bit Windows Vista for its use of physical memory above 4GB. Copy it to the Windows System directory of the machine that you will test.

For this, you typically will need administrative privilege for the target machine. Then, provided that you successfully self-signed the kernel, you have to restart that machine with three boot options:. It is prudent to work on a copy of the configuration that you want to test. Assuming that you are currently booted into this configuration, running the command. If you do turn out to have a defective driver and need to identify it and update it, then you can go through any of the usual processes of elimination even while starting in Test Mode.

Note in particular that Test Mode is not Safe Mode. By the way, if you have a defective driver and you proceed to replace it, then be sure to boot into your normal Windows configuration for the downloading and updating. Of course, if the need for this was news to you, then you might better not be trying any of this. If you already have an operating system configuration that has PAE enabled, then a less intrusive way to start your tests is to enter the options at the Edit Boot Options Menu.

This is admittedly a lot easier if your machine is already configured for booting multiple operating systems or the one operating system in multiple configurations so that you ordinarily see a boot menu during startup. At this boot menu, select the configuration that you want to test, then press F10 to open the Edit Boot Options Menu. INI switches:. Press Enter, and the selected operating system will start with your modified kernel in Test Mode.

This method has the advantage of not reconfiguring the selected operating system in any way that lasts, and the corresponding disadvantage that you have to type something every time you want to do the test. You cannot set this up entirely with boot options in the BCD store, because the option to disable integrity checking is not permitted to persist. The closest you can get is to disable integrity checking at one or other of the boot menus. Prepare a boot entry with just the pae and kernel options as above.

The alternative with the Edit Boot Options Menu is also available, with the same constraints about PAE being already enabled, but the switches to enter are now:. Curiously enough, booting with integrity checking disabled leaves no warnings on the desktop such as you get from booting in Test Mode.

I do not mean to recommend this method of testing. Although this article is motivated by the realisation that Microsoft introduced a formal scheme of license values for Windows Vista, two of which stop bit Windows Vista from using memory above 4GB, a few words might usefully be passed about earlier Windows versions. As noted above, the PAE kernel dates from Windows That was very definitely too small a list, but was surely more about what was intended than what actually was coded and released if not formally supported.

These each have four kernels:. In practice, Windows is installed with just two kernels, according to whether the machine has one logical processor or more. The single-processor kernels have the standard names. The multi-processor kernels are renamed at installation. As noted above, the kernel in Windows Vista limits memory use by filtering the map of physical memory as received from the loader, so that memory in excess of the limits is discarded before the kernel really starts working with the map.

This mechanism dates from at least Windows At first, there was just the one limit, of total physical memory. A limit on the maximum physical address begins chronologically with Windows Server In earlier versions than Windows Vista, the memory limits for different product types are hard-coded and the connection with licensing is only indirect.

INI options. EXE in each release. There may be errors in transcription, there being only so much time that I am willing to take over finding every last detail for this information. If you want more detail or reliability, try finding it from Microsoft.

Note that for nearly 5 years, i. Windows Server R2 is available only in bit editions. If the memory is remapped, X64 Windows can use this memory. Any X64 Windows or X86 Server release can. The limit that these versions impose is the highest permitted physical RAM address, not the size of the IO space. For example, drivers could map the "lost" memory regions located above 4 GB and expose this memory as a RAM disk. Physical Address Extension. Skip to main content. This browser is no longer supported.

Download Microsoft Edge More info. Contents Exit focus mode. Is this page helpful? Please rate your experience Yes No.

Any additional feedback? In this article. Windows 8.



0コメント

  • 1000 / 1000