Let’s begin with a look at the upgrade paths for Windows 7 and Windows Server 2008 R2. First, the basic upgrade matrix for Windows 7:
| If you are currently running: | You can upgrade to: |
| Windows Vista Home Basic (SP1 or SP2) |
|
| Windows Vista Home Premium (SP1 or SP2) |
|
| Windows Vista Business (SP1 or SP2) |
|
| Windows Vista Enterprise (SP1 or SP2) | Windows 7 Enterprise (x86 and x64) |
| Windows Vista Ultimate (SP1 or SP2) | Windows 7 Ultimate (x86 and x64) |
Note: There is no supported direct upgrade from Windows XP to Windows 7.
And here is the basic upgrade matrix for Windows Server 2008 R2:
| If you are currently running: | You can upgrade to: |
| Windows Server 2003 Standard (SP2 or R2) x64 |
|
| Windows Server 2003 Enterprise (SP2 or R2) x64 |
|
| Windows Server 2003 Datacenter (SP2 or R2) x64 | Windows Server 2008 Datacenter R2 (x64) |
| Windows Server 2008 Standard (Core) x64 |
|
| Windows Server 2008 Enterprise (Core) x64 |
|
| Windows Server 2008 Datacenter (Core) x64 | Windows Server 2008 Datacenter (Core) R2 x64 |
| Windows Server 2008 Web Server (Core) x64 |
|
| Windows Server 2008 Standard x64 |
|
| Windows Server 2008 Enterprise x64 |
|
| Window Server 2008 Datacenter x64 | Windows Server 2008 Datacenter R2 x64 |
| Windows Server 2008 Web Server x64 |
|
| Windows Server 2008 Foundation (SP2) x64 | Window Server 2008 Standard R2 x64 |
Some things to note about the upgrade paths for both Windows 7 and Windows Server 2008 R2:
- Cross architecture in-place upgrades (for example, x86 –> x64 or x64 –> x86) are not supported
- Cross language in-place upgrades (for example, en-us –> de-de) are not supported
- Cross build-type in-place upgrades (for example, fre –> chk) are not supported
OK – let’s briefly go over some of the Registry Enhancements. There were two main areas in which management of the registry in Windows 7 and Windows Server 2008 R2 was enhanced:
- The Locking Mechanism
- WoW64 Redirection and Reflection
Let’s start by taking a look at the locking mechanism. The locking mechanism for registry keys was enhanced in the Windows 7 codebase to minimize performance issues caused by contention for a lock on one or more keys.
The Configuration Manager (CM) stores and maintains configuration information in the registry hives. A Key Control Block (KCB) is a structure that represents a unique registry key (the full path). A KCB table contains hash entries that allow quick reference to KCBs. Multiple KCBs (possibly representing registry keys from different hives) can use the same table entry. Pushlocks are used to lock the KCB table entries.
In previous versions of Windows, the KCB table entry locking mechanism could at times cause deadlock contention and Event ID 333. The reasons for this were:
- A single system-wide KCB table was shared among all registry hives. This meant that a KCB for a key in the Software hive might share a lock with KCBs for keys in the System hive and a User hive. So it would not be uncommon for a lock requested for the purpose of updating the key in the Software hive to cause unnecessary contention for access to the other, possibly unrelated keys.
- An “Eager” locking method often locked more table entries than were really needed since multiple keys that were part of the full path to a key might be locked. For example, if a lock was required for key HKLM\System\CurrentControlSet\Services\MyService\Parameters, a lock might be acquired for one or more parent keys in that path, even though a lock was really only required for the Parameters key.
- Per-hive flush locks delayed in-memory registry updates until disk-intensive flush operations were completed.
-
These issues were addressed in Windows 7 and Windows Server 2008 R2 as follows:
- Each registry hive now has its own KCB table, which reduces lock contention significantly.
- Only KCBs and table entries that are really needed for an operation are locked now – usually just the leaf object in the path.
- A second per-hive flush lock was added that allowed “dirty” hive data to be identified in-memory, and updates to continue without having to wait for a flush operation to continue.
Let’s move on to WoW64 Redirection and Reflection. Wow64 provides an emulation environment for 32-bit applications to run seamlessly on 64-bit Windows platforms. As a part of this design Wow64 provides separate registry views to 32-bit and 64-bit applications, avoiding conflicts potentially caused by sharing architecture-specific data.
There were two key mechanisms that made this split personality registry design work: Redirection and Reflection.
Redirection: Wow64 does not require applications to have knowledge about the registry layout of a 64-bit OS. It transparently redirects applications to the proper locations depending on the architecture of the application.
Using registry redirection, WoW64 splits the registry at certain points into 32 bit and 64-bit views. For example, keys under HKLM\Software are split. Beneath the keys that are split is a key that represents the redirection point, WoW6432Node. That key is used as the root key for the 32-bit keys. Registry keys that are not split are referred to as “shared” or “merged” keys. The combination of shared and split keys makes up an architecture-specific view, so we have both a 32-bit view and a 64-bit view.
Some common redirection points were:
- HKLM\Software\Wow6432Node
- HKLM\Software\Classes\Wow6432Node
- HKU\<sid>\Software\Classes
- HKU\<sid>_CLASSES\Wow6432Node
A redirected key actually consists of two physical keys, which means that the certain parts of the registry are doubled in size. In previous versions of Windows the policy that was used for redirection was “split by default”. This meant that, for example, even if only the key HKLM\Software\MyCompany\MyApp\Parameters contained architecture-specific values, the entire HKLM\Software\MyCompany key might be split, resulting in a much larger than necessary registry footprint.
Reflection: WoW64 used Registry Reflection to copy data between 32-bit and 64-bit copies of split registry keys based on rules to keep COM-specific keys synchronized. In particular, communication between 32-bit and 64-bit COM clients and servers required COM objects and Proxy/Stub DLL registration data to be written in both registry hives. At times, this would cause data inconsistency in the registry because reflection was not atomically performed at the time the key was written.
The following improvements to these features in Windows 7 and Windows Server 2008 R2 reduce the size of the registry, improve registry consistency, and could have an overall impact on performance by reducing memory and CPU usage.
The registry key split policy has been changed to “shared by default”. Now only those keys that contain architecture-specific data are split, greatly reducing the registry footprint. For example, if a 32-bit application needs to update the registry key HKLM\Software\MyCompany\MyApp\Parameters, only that key will be redirected, rather than at the level of one of the parent keys. Reflection has been completely eliminated. It was previously required only for COM components and the need for using reflection has been negated by updating COM to only use shared keys.
Before we wrap up our post for today, let’s go over some changes to Crash Dump Retention and Page Files. One common theme you will see in Windows 7 is an effort to reduce the disk footprint of Windows. The purpose of this effort is not only to preserve disk space on desktops and laptops, but also to accommodate increasingly popular netbooks, which in many cases are available with solid state drives (SSDs) as small as 16 GB. Depending on the amount of memory a machine has, the size of the paging file size and the way that memory dumps are retained can have a significant effect on the disk space used.
Three enhancements in the area of crash dump retention and page file size were introduced in Windows 7 and Windows Server 2008 R2:
Page file size equal to RAM: Prior to Windows 7 the default paging file size was determined differently on different versions of Windows. But in general terms, when the paging file size was configured as “system-managed” its size would typically be calculated as RAM x (some number greater than 1) or RAM + (some number) .
In Windows 7 and Server 2008 R2 the default size is equal to the amount of memory installed in the machine. Your gut reaction to this is probably the same as mine was – to get a successful complete memory dump the paging file needs to be a little larger than RAM. How much larger probably goes back to what version of Windows you are running and other factors, but 300 MB is generally considered plenty of padding for the purposes of getting a complete dump.
Not to worry. A default installation of Windows 7 or Server 2008 R2 is configured to generate a kernel memory dump and also with a system-managed paging file size. So a paging file equal to RAM is plenty. If you decide that you want to capture a complete memory dump, simply change the dump option to “Complete memory dump” and restart (be sure to leave the paging file size as system-managed). After the restart the paging file should be RAM + 300 MB . This applies to both client and server SKUs.
New memory dump retention criteria: In the event of a system crash, memory is dumped to the paging file, then copied to the location specified in the Advanced System Properties during the subsequent reboot. After the restart the dump and associated information may be uploaded to Microsoft depending on the Windows Customer Experience Improvement Program options chosen during installation or controlled by the administrator through group policy. Once this process is complete, the dump file will be retained or deleted depending on the following factors:
- Whether it is a server or client SKU
- Whether it is joined to a domain
- The amount if free disk space
- Whether retention is overridden in the registry
If the machine is a server SKU and/or joined to a domain, the memory dump is always retained. For client machines not joined to a domain, the dump will be retained as long as the amount of free space on the system drive is greater than 25 GB. If the following registry value is set to “1” then the dump file will be retained regardless of any other factor: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl\AlwaysKeepMemoryDump
Configurable mini-dump retention: Unlike complete or kernel memory dumps which are overwritten each time a new system crash occurs, small memory dumps are retained indefinitely (in the folder %WinDir%\Minidump by default). Minidump files are named using the format MiniMMDDYY-nn.dmp, where “MMDDYY” is the date on which the dump was produced and “nn” represents the instance of a minidump produced on that date.
In Windows 7 and Windows Server 2008 R2, the number of minidumps retained can now be controlled by a registry key value: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl\MinidumpsCount. The default value of MinidumpsCount is 50.
Well, that brings us to the end of the first post. Tomorrow, Tim Newton will be going over Memory Management changes and Fault-Tolerant Heap.
- Jim Martin
| Share this post : |
|
|
|
|
|
|
|
|
<br/>