NH Setup W01 M05 x64

Setup New Hire Week 1 Module 5
Examining Windows 64-Bit Architecture
FINAL
Released: September 22, 2010
Conditions and Terms of Use

Microsoft Confidential - For Internal Use Only This training package content is proprietary and confidential, and is intended only for users described in the training materials. This content and information is provided to you under a NonDisclosure Agreement and cannot be distributed. Copying or disclosing all or any portion of the content and/or information included in this package is strictly prohibited. THE CONTENTS OF THIS PACKAGE ARE FOR INFORMATIONAL AND TRAINING PURPOSES ONLY AND ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, WHETHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT. Training package content, including URL and other Internet Web site references, is subject to change without notice. Because Microsoft must respond to changing market conditions, the content should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. Unless otherwise noted, the companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred.
Copyright and Trademarks

2010 Microsoft Corporation. All rights reserved. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. For more information, see Use of Microsoft Copyrighted Content at http://www.microsoft.com/about/legal/permissions/. Microsoft, Internet Explorer, and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Microsoft products mentioned herein may be either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. All other trademarks are property of their respective owners.
Table of Contents
Module 5. Examining Windows 64-Bit Architecture .............................................................................. 7 1. Introducing Microsoft Windows x64 Editions ................................................................................ 8
Before You Begin ............................................................................................................................................8 What You Will Learn.......................................................................................................................................8 Commonly Used Terms ......................................................................................................................................9 Itanium Architecture Overview ......................................................................................................................10 Differences Between Itanium and x64 Edition Versions ................................................................................11 System Requirements ......................................................................................................................................12 Features Included in x64 Editions ....................................................................................................................13 Using GPT Drives ..........................................................................................................................................13 Examining Drive Configurations ...................................................................................................................14 Servicing Considerations for x64 Editions ........................................................................................................18 Summary ..........................................................................................................................................................19
2. Understanding the x64 Architecture ................................................................................................ 21

Before You Begin ..........................................................................................................................................21 What You Will Learn.....................................................................................................................................21 Processor Architecture and Memory Management .........................................................................................22 Registers Supported in 64-bit Mode ............................................................................................................23 Memory Management on x64 Systems .......................................................................................................24 Data Execution Prevention (DEP) Support .......................................................................................................26 Hardware-enforced DEP...............................................................................................................................26 Software-enforced DEP ................................................................................................................................27 Power Management in x64 ..............................................................................................................................28 Enabling AMD CoolnQuiet..........................................................................................................................28 Verifying CoolnQuiet Operation .................................................................................................................29 HyperTransport Technology ..........................................................................................................................30 HyperTransport Data Transfer ..................................................................................................................31 Identifying HyperTransport Devices .............................................................................................................32 PCI Express Technology .................................................................................................................................33 Identifying PCI Express Components ............................................................................................................34 Identifying x64 Processors................................................................................................................................35 DEMO: Identifying x64 CPUs ........................................................................................................................35
Resources ........................................................................................................................................................ 36 Summary ......................................................................................................................................................... 37
3. Examining Key Changes.................................................................................................................... 39

Before You Begin ......................................................................................................................................... 39 What You Will Learn .................................................................................................................................... 39 File System Changes in x64 Editions ................................................................................................................ 40 WOW64 File System Redirection ................................................................................................................ 40 Windows File Protection Changes ............................................................................................................... 41 Verifying File Bit Level ................................................................................................................................. 41 Registry Changes in x64 Editions ..................................................................................................................... 42 Registry Redirection .................................................................................................................................... 42 Registry Reflection ...................................................................................................................................... 43 Remote Registry Access in 64-bit Windows ................................................................................................ 45 Enhanced Memory and CPU Capabilities in x64 Editions ................................................................................ 47 Installation and Configuration Changes .......................................................................................................... 49 New Version Mismatch Error Messages ..................................................................................................... 49 HAL Support Changes in x64 Editions .......................................................................................................... 49 New Driver INF Requirements ..................................................................................................................... 50 Mass Storage Driver Installation Changes ................................................................................................... 51 Application Support Changes .......................................................................................................................... 53 16-bit Application Support .......................................................................................................................... 53 32-bit Application Support .......................................................................................................................... 53 64-bit Application Support .......................................................................................................................... 54 DEMO: Identifying 32-bit Application Processes ......................................................................................... 54 Memory Dump Options ................................................................................................................................... 55 Debugging 64-bit Memory Dumps .............................................................................................................. 55 Resources ........................................................................................................................................................ 56 Summary ......................................................................................................................................................... 57
4. Installation and Configuration ......................................................................................................... 59

Before You Begin ......................................................................................................................................... 59 What You Will Learn .................................................................................................................................... 59 Installation Considerations .............................................................................................................................. 60 Hotfix Considerations .................................................................................................................................. 62 Driver Support Considerations ........................................................................................................................ 63
INF Requirements for x64 ................................................................................................................................64 INF Decoration Behavior for Windows Server 2003 and Earlier ..................................................................64 INF Decoration Behavior for x64 Editions ....................................................................................................66 Deployment Options for x64 Editions ..............................................................................................................67 Using Unattended Installation for x64 Editions ...........................................................................................67 Using System Preparation Tool (Sysprep) for x64 Editions ..........................................................................69 Using Remote Installation Server (RIS) for x64 Editions ..............................................................................69 Automated Deployment Services Support for x64 Editions .........................................................................71 Windows Preinstallation Environment (WinPE) Changes for x64 Editions ..................................................71 Machine Check Architecture (MCA) Events .....................................................................................................82 Floppy-free Computer Considerations .............................................................................................................84 Best Practices for Dual Boot Configurations ....................................................................................................85 Removing x64 Operating Systems from a Dual Boot Configuration ............................................................87 Transferring Files and Settings .........................................................................................................................89 Directory Structure and 32-bit Driver Changes ................................................................................................92 32-bit Driver CAB File Changes .....................................................................................................................97 Resources .........................................................................................................................................................98 Summary ..........................................................................................................................................................99
FINAL
Module 5. Examining Windows 64-Bit Architecture
Global Technical Readiness Microsoft Confidential - For Internal Use Only
Examining Windows 64-Bit Architecture 1. Introducing Microsoft Windows x64 Editions
FINAL
1. Introducing Microsoft Windows x64 Editions

This session defines terms and discusses technologies associated with 64-bit operating systems, describes enhancements provided by the Microsoft Windows x64 Edition architecture, and discusses system requirements and servicing considerations for x64 operating systems. Prior to the x64 platform, Microsoft only offered 64-bit computing for the Itanium platform in the Microsoft Windows XP Professional 64-Bit Edition and Microsoft Windows Server 2003 64-Bit Editions. While the Itanium architecture is widely used for highly available, highly scalable workstation and server systems, the hardware cost and operating system version feature set make it less desirable as a desktop platform. The introduction of x64 Edition operating systems marks the entry of Microsoft into the 64bit desktop computing world. These operating systems provide a feature-rich, affordable, yet scalable alternative to end users who have requested the resources and memory management that 64-bit systems offer.
Before You Begin

Before starting this session, you should: Complete the course Introducing Microsoft Windows x64 Editions.
What You Will Learn

After completing this session, you will be able to: Define terms that are commonly used in 64-bit computing discussions. Describe key technologies specific to the Itanium architecture. Describe the differences between x64 and Itanium versions. List the enhancements to the feature set for x64 operating systems. List the system requirements for installing Windows x64 edition operating systems. Describe the servicing considerations for Windows x64 Editions.
2010 Microsoft Corporation. All rights reserved.
FINAL
Commonly Used Terms

Terms commonly used in 64-bit computing discussions include the following: 64-bit An operating system based on 64-bit code. Also, a computer capable of running a 64bit operating system, which includes both x64 and Itanium architectures. Itanium Indicates support for 64-bit technology implemented by Itanium processors that require a processor-specific operating system. x64 Indicates support for 64-bit extended technology implemented by x64 processors that provide 64-bit extensions to the industry-standard x86 instruction set. x64 Editions 64-bit operating systems developed by Microsoft for the Advanced Micro Devices (AMD) and Intel x64 class of processors. AMD64 AMD implementation for the x64 platform. AMD is currently producing Opteron, Athlon, and Turion Central Processing Units (CPUs) using AMD64 architecture. EM64T Intel implementation for the x64 platform. Intel is currently producing Xeon64 and Pentium 4 CPUs using EM64T architecture. WOW64 An emulation layer provided with 64-bit operating systems, which allows the 64-bit operating system to run native 32-bit code. This layer provides backward compatibility for 32-bit processes and applications.
Windows x64 Edition operating systems were developed from a separate code base designed to run only on the x64 platform hardware. Code compiled for the x64 Edition operating systems will not run on Itanium computers, and code compiled for Itanium operating systems will not run on x64 hardware. However, the x64 Edition and Itanium operating systems use similar directory and registry structures as discussed later in this training.
Important: The x64 Edition operating system family is a new software platform built for a new generation of CPUs. Changes require different support methodologies, and updates and hotfixes must be obtained through different channels, as discussed in Servicing Considerations for x64 Editions on page 18.
FINAL
Itanium Architecture Overview

In July of 2002, Microsoft entered the 64-bit computing market with the introduction of Microsoft Windows Advanced Server, Limited Edition version 1.2. The Intel Itanium processor differs from x86 and x64 CPUs at an architectural level. Using Explicitly Parallel Instruction Computing (EPIC), Itanium processors can compute as many as 20 instructions in parallel. This capability represents a significant performance improvement over traditional Reduced Instruction Set Computing (RISC) and Complex Instruction Set Computing (CISC) CPUs that process one instruction per clock cycle. EPIC architecture uses three key technologies specific to the Itanium platform: Parallelism: The ability to deliver high performance and scalability by allowing compilers to provide more information to the processor, allowing it to execute more operations on a continuous basis. Predication: The ability of Itanium-based CPUs to predict an If-Then-Else type outcome by running both the Then and Else processes in parallel, and discarding the improper outcome. Speculation: The ability to cache instructions on the processor itself, eliminating bottlenecks seen from late instructions arriving from main memory or cache. This allows the processor to hold instruction information before it is needed, in effect speeding up processes as they arrive because the needed instructions are already available on the processor.
Computers based on Itanium architecture boot from the Extensible Firmware Interface (EFI) partition. EFI provides an interface between the machine firmware and the operating system. EFI was originally designed to replace non-standardized machine basic input/output system (BIOS) versions typically developed for specific hardware architectures with a standardized boot environment. EFI technology enables the use of the Globally Unique Identifier (GUID) Partitioning Table (GPT) disk format on the Itanium platform. GPT disks support volumes up to 18 exabytes in size with up to 128 primary partitions, a large improvement over standard Master Boot Record (MBR) disks that only support volumes up to 2 terabytes in size with four primary partitions per drive. When used with x64 Edition operating systems, GPT disks locate data critical to platform operation on partitions rather than on hidden or un-partitioned sectors.
10
FINAL
Differences Between Itanium and x64 Edition Versions

The Itanium and x64 Edition operating system versions target different sectors within the 64-bit market. Each platform provides unique advantages for its intended market as follows: Itanium systems offer a highly scalable 64-bit platform that delivers industryleading performance for mission-critical, high-end systems. Itanium systems can run 32-bit code without recompiling, but require hardware or software emulation for 32-bit processes, which may not allow those processes to run at full speed. In contrast, x64 systems provide greater versatility by allowing 32-bit and 64-bit code to run at higher speed. The x64 hardware can also run 32-bit operating systems in native mode without emulation, while Itanium hardware requires Itanium-based operating system code. Itanium operating environments are not feature rich. Itanium does not support multimedia features such as Windows Media Player, Windows Movie Maker, or DirectX. In contrast, x64 offers near-feature parity with current x86 desktop and enterprise environments.
Neither the Itanium platform nor the x64 platform support 16-bit application code. As a result, some features dependent on 16-bit code have been removed from both operating systems.
11
FINAL
System Requirements
Current system requirements for x64 Edition operating systems include the following:
Currently Supported Processors:
o AMD Athlon 64 (FX) o AMD Opteron o AMD Turion o Intel Xeon with Intel EM64T support o Intel Pentium 4 with Intel EM64T support
Minimum Random Access Memory (RAM):
o Windows XP Professional x64 Edition: 256 MB o Windows Server 2003 x64 Editions: 512 MB
Note:
Minimum Hard Disk space available: 1.5 GB Video: Super VGA (800x600) or higher resolution video card CD-ROM or DVD drive Keyboard and Microsoft Mouse or compatible pointing device
System requirements are subject to change. For the latest information about x64 Edition system requirements, see: http://www.microsoft.com/windowsserver2003/64bit/x64/standard.mspx http://www.microsoft.com/windowsserver2003/64bit/x64/enterprise.mspx http://www.microsoft.com/windowsxp/64bit/evaluation/upgrade.mspx
12
FINAL
Features Included in x64 Editions

The Windows XP Professional 64-bit Edition for the Itanium platform did not provide the full range of features available in 32-bit versions. However, the Windows XP Professional x64 Edition provides near-feature parity with 32-bit versions, including Windows Media Player 10, Microsoft DirectX 9.0c, Windows Movie Maker, and Windows Firewall, and other key end-user features. Windows Server 2003 x64 Editions also include Windows Media Server, Windows Fax Server, and support for GUID Partitioning Table (GPT) disks. The following features have been limited or removed in all Windows x64 Edition operating system versions: 16-bit application support is limited.
Windows x64 Edition operating systems provide limited support to convert known 16-bit installers to 32-bit versions but do not provide support for 16-bit applications. MSDOS has been removed. Open Shortest Path First (OSPF) has been removed.
Tools that ship with x64 operating systems are functionally equivalent to the tools provided with x86 operating systems. Some tools have been updated to accommodate new features available in Windows x64 Edition operating systems.
Using GPT Drives

While MBR disks can support up to 4 primary partitions and an infinite number of partitions inside an extended partition, GPT disks allow up to 128 primary partitions. However, GPT disks allow a much larger volume size (greater than 2 TB, which is the limit on MBR disks) and provide greater reliability due to replication and cyclical redundancy check (CRC) protection of the partition table. GPT disks can be used as storage volume on all x64 platforms, including Windows XP Professional x64 Edition. Windows Server 2003 SP1 will also enable support for GPT in x86 versions of the Windows Server 2003 family. Unlike the Itanium platform, x64 Edition operating systems only support the use of GPT drives as data volumes. Because the x64 architecture does not provide support for an EFI boot partition, a GPT drive cannot be used to boot an x64 computer.
Warning: Computers running x64 Edition operating systems must be equipped with more than one physical drive to allow the use of the GPT disk format. You can only convert raw drives or empty MBR drives to the GPT format. Any attempt to convert the system or the boot drive to the GPT format will remove all data from the drive.
13
FINAL
Examining Drive Configurations

You can use the following methods to determine if a drive is configured as a GPT or an MBR disk: In the Disk Management console, open the View menu and select Top, and then select Disk List. The upper pane displays a list of disk drives that specifies the partition style in the last column. In the Disk Management console, right-click the drive to display conversion options. o If the drive is configured as an un-partitioned GPT disk, the Convert to MBR Disk option is displayed as shown in Figure 1. If the drive is partitioned, this option is disabled.
Figure 1. Using the Disk Management Console to Identify GPT Disks
o o
If the drive is configured as an un-partitioned MBR disk, the Convert to GPT Disk option is displayed. If the drive is partitioned, this option is disabled. In Device Manager, right-click the drive, select the Volume tab, and then click Populate to display the Partition style and other information as shown in Figure 2.
14
FINAL
Figure 2. GPT Disk Properties Displayed in Device Manager
Launch the DiskPart utility and enter the command list disk. The disk list indicates GPT or MBR in the last column of the command output.
Creating GPT Drives

Important: Only physically separate empty un-partitioned disks can be converted to GPT disks.
You can use the following methods to create GPT disks: In the Disk Management console, right-click the MBR drive you want to convert to GPT and choose Convert to GPT Disk as shown in Figure 3. If the drive is not empty or contains partitions, this option is disabled.
Figure 3. Using the Disk Management Console to Convert MBR Disks to GPT
In the DISKPART utility, select the drive you want to convert and enter the following command:
15
FINAL
CONVERT GPT
For raw disks, two additional methods can be used: After installing a new raw disk, opening the Disk Management console launches a wizard to configure the new disk. The wizard includes options to initialize the disk as MBR or GPT. The new disk can also be initialized at a later time using the Initialize disk option in the Disk Management console.
DEMO: Creating and Identifying GPT Drives

This demonstration illustrates: How to create a GPT disk using the Disk Management Console. How to identify MBR and GPT drives in: o o Disk Management Console. Device Manager Disk Properties.
Installation Considerations for GPT Drives

Installing Windows x64 Edition operating systems on a GPT disk is not supported. Attempting to do so will yield the following error:
Setup cannot install to the selected partition. You can only install to GPT disks on IA-64 machines and MBR disks on X-86 machines. You can only upgrade installations on GPT disk on IA-64 machines and MBR disks on X-86 machines. To go back to the previous screen press ENTER
Although Setup does allow you to choose a GPT disk partition on the partition selection screen during text mode, doing so will display the error message shown previously. To assist users in avoiding this error, the partition selection screen clearly indicates whether the partition is configured as an MBR drive or a GPT drive as shown in the following Setup screen example.
Windows Server 2003, Enterprise Edition Setup The following list shows the existing partitions and unpartitioned space on this computer. Use the UP and DOWN ARROW keys to select an item in the list. To set up Windows on the selected item, press ENTER To create a Partition in the unpartitioned space, press C. To delete the selected partition, Press D.
16
FINAL
78529 MB disk 0 on Id 0 on bus 0 on atapi [MBR] C: Partition1[NTFS] D: Partition1[NTFS] E: Partition1[NTFS] 19470 MB Disk -: Partition1 I: Partition2 J: Partition2 0 at Id 1 on bus 0 on atapi [GPT] [Reserved] (New Volume) NTFS [unknown]
12002 MB (7045 MB free) 12002 MB (7045 MB free) 12002 MB (7045 MB free)
128 MB ( 0 MB free) 3000 MB (2982 MB free) 3000 MB (3000 MB free)
GPT disks only support the NTFS file system. Note:
17
FINAL
Servicing Considerations for x64 Editions

Despite the similarity in product names, Windows XP Professional x64 Edition is not the same as the Microsoft Windows XP Home or Professional x86 operating system versions. This difference may cause some confusion among customers who are not aware of the architectural differences between the 32-bit and 64-bit versions of Windows XP. Windows XP Professional x64 Edition was developed from the same code tree that was used to develop Windows Server 2003 Service Pack 1 (SP1). The consequences are as follows: Updates included with SP1 for Windows Server 2003 are included in the Windows XP Professional x64 Edition product. Although Windows Server 2003 x64 Editions do not include SP1 in their Stock Keeping Unit (SKU) product codes, these operating system versions already contain SP1 updates because they are built from the Windows 2003 SP1 code tree.
Important: Windows Server 2003 x64 Editions do not require Windows Server 2003 SP1 updates.
All updates and hotfixes for Windows XP Professional x64 Edition must be based on the Windows Server 2003 SP1 code tree. Updates and hotfixes released for Windows XP x86 editions do not apply to Windows XP Professional x64 Edition. If a similar update is required for the x64 platform, it will be released as a Windows x64 update or hotfix. Updates that do not specifically apply to Windows x64 editions may not be applicable. For example, when Service Pack 3 (SP3) for Windows XP is released, the updates it contains will not apply to Windows XP Professional x64 Edition; however, when Windows Server 2003 Service Pack 2 (SP2) is released, the updates it contains will apply to Windows XP Professional x64 Edition. Updates and service packs from the x86 Windows XP Service Pack 2 (SP2) code tree cannot be installed on Windows XP Professional x64 Edition. In most cases, these updates and service packs will fail to install because they are 32-bit updates.
All operating system updates will be provided in the same way they are provided today through service packs, Windows Updates, and security hotfixes. All Windows x64 Edition operating systems, including Windows XP Professional x64 Edition, will be serviced from the Windows Server 2003 SP1 code tree.
18
FINAL
Summary
Topics discussed in this session include: Commonly Used Terms Overview of Itanium Differences Between Itanium and x64 Versions Feature Included in x64 Editions System Requirements Servicing Considerations for x64 Editions
19
FINAL
20
FINAL
2. Understanding the x64 Architecture

This session describes the basic features of the x64 architecture, discusses data execution and power management features, describes bus technologies available on x64 computers, and explains how to identify CPU versions installed in computers running Microsoft Windows x64 Edition operating systems.
Before You Begin

What You Will Learn

After completing this session, you will be able to: Describe the basic features of the x64 architecture. Describe the data execution and power management features provided in Windows x64 Editions operating systems. Describe the HyperTransport technology available on x64 hardware. Describe the PCI Express technology available on x64 hardware. Identify CPU versions installed in x64 computers.
21
Examining Windows 64-Bit Architecture 2. Understanding the x64 Architecture
FINAL
Processor Architecture and Memory Management

The x64 architecture is built to run on both AMD64 and EM64T, the processor classes of Advanced Micro Devices (AMD) and Intel Corporation, respectively. The Windows code base used with both the AMD and the Intel Central Processing Units (CPUs) is the same, and is built from the Microsoft Windows Server 2003 Service Pack 1 (SP1) code tree. Major feature changes in the x64 architecture include: The x64 CPUs provide an extension of the x86 instruction set to handle 64-bit data. Registers have been extended from 32-bit to 64-bit. Eight new registers have been added. To extend instruction encoding, a REX prefix has been added to instructions as necessary to specify access to 64-bit resources. The x64 implementation includes ten new instructions as shown in Table 1.
Table 1. New Instructions in x64
64-bit Instruction CDQE CMPSQ CMPXCHG16B LODSQ MOVSQ MOVZX STOSQ SWAPGS SYSCALL SYSRET
1 1 1
Description Convert doubleword to quadword Compare strings by quadword Compare and exchange 16 bytes Load string quadword Move string quadword Move with zero-extend Store string quadword Swap GS base register Fast system call to ring 0 Return from fast system call
Notes New mnemonic for old opcode New mnemonic for old opcode New instruction New mnemonic for old opcode New mnemonic for old opcode 64-bit version of old instruction New mnemonic for old opcode Supported by AMD64 and EM64T Supported by AMD64 and EM64T Supported by AMD64 and EM64T
Notes Windows x64 Editions use the CPUID instruction to identify CPUs that support these instructions. For CPUs that support these instructions, operating system level support is automatically enabled without additional user setting or intervention.
22
FINAL
The new instruction CMPXCH16B compares 32-bit source and destination register operands and determines if they are equal. If the values are equal, the value in the source operand is copied. If the values are not equal, the value in the destination operand is copied. For more information about x64 CPU instructions and application and driver programming, refer to technical documentation available from the following locations: For AMD AMD64 processors: o http://www.amd.com/us-en/Processors/TechnicalResources/ 0,,30_182_739_7044,00.html
For Intel EM64T processors: o http://developer.intel.com/technology/64bitextensions
For Windows x64 Editions: o http://msdn.microsoft.com/library/default.asp?url=/library/enus/kmarch/ hh/kmarch/64bitAMD_1f7a33fb-6c2c-416c-9ac75e9324026364.xml.asp http://msdn.microsoft.com/library/default.asp?url=/library/enus/kmarch/ hh/kmarch/64bitAMD_1f7a33fb-6c2c-416c-9ac75e9324026364.xml.asp
Registers Supported in 64-bit Mode

Register extensions and 64-bit long mode support provided by the AMD64 CPU are shown in Figure 4.
Figure 4. Register Extensions and Long Mode Support
Eight General Purpose Registers (GPR) RAX-RSP have been extended to support 64-bit long mode functions. The 64-bit MMX registers have been added to support 64-bit media instructions and the 128-bit XMM registers have been added to improve performance for
Global Technical Readiness Microsoft Confidential - For Internal Use Only 23
FINAL
graphics and multimedia applications that perform complex math operations and process large amounts of data in small segments. For more information about AMD64 CPU architecture, refer to technical documentation available from: http://www.amd.com/usen/Processors/DevelopWithAMD/0,,30_2252_875_7044,00.html
Memory Management on x64 Systems

Memory management on x64 systems uses a flat addressing model rather than the segmented memory model used by x86 systems. In x64, data, code, and stack segments all share the same memory space when running 64-bit processes; 32-bit processes still use a segmented memory model. However, as shown in Figure 5, x64 operating systems move segments into the 64-bit flat model through a process that is transparent to users.
Figure 5. Memory Management Models in 64-bit and Legacy Modes
Physical memory addressing is performed in a similar fashion. 64-bit processes can generate 64-bit virtual addresses capable of gaining access to physical addresses up to 52 bits in size. 32-bit processes running on x64 systems still generate 32-bit virtual addresses in the same way as x86 systems do, allowing x64 systems to gain access to large amounts of memory when running 64-bit processes while maintaining backward compatibility for 32bit processes. Figure 6 illustrates 64-bit and 32-bit addressing methods.
24
FINAL
Figure 6. Addressing Methods in 64-bit and Legacy Modes
The x64 processors still support legacy x87 floating point programming instructions. These instructions can run in 64-bit mode with recompilation or in compatibility mode without recompilation.
25
FINAL
Data Execution Prevention (DEP) Support

Data execution prevention (DEP) includes a set of hardware and software technologies that perform additional checks on memory to help protect against malicious code exploits. In Windows x64 Editions, DEP is enforced by both hardware and software.
Hardware-enforced DEP
Hardware-enforced DEP marks all memory locations in a process as non-executable unless the location explicitly contains executable code. One class of attacks attempts to insert and execute code from non-executable memory locations. DEP helps prevent these attacks by intercepting them and raising an exception. Hardware-enforced DEP relies on processor hardware and operating system software to mark memory with an attribute to indicate that code should not be executed from that memory. DEP functions on a per-virtual memory page basis, usually changing a bit in the page table entry (PTE) to mark the memory page. The actual hardware implementation of DEP and marking of the virtual memory page varies by processor architecture. However, processors that support hardware-enforced DEP are capable of raising an exception when code is executed from a page marked with the appropriate attribute set. Both Advanced Micro Devices (AMD) and Intel Corporation have defined and shipped Windows-compatible architectures that are compatible with DEP. Hardware enforced DEP support began with Microsoft Windows XP Service Pack 2. Windows x64 Editions use the no-execute page-protection (NX) processor feature as defined by AMD or the Execute Disable bit feature as defined by Intel. Hardware DEP is enforced on all 64-bit systems in the native 64-bit environment. DEP protection is controlled by the user or group policy in the 32-bit WoW64 environment. The default for the WoW64 is to enable DEP as shown in Figure 7.
Figure 7. Performance Options - Enabling DEP Protection
26
FINAL
Software-enforced DEP
Additional DEP security checks have been added to Windows x64 editions. These checks, known as software-enforced DEP, are designed to mitigate exploits of exception handling mechanisms in Windows. Software-enforced DEP: Runs on any processor that is capable of running Windows x64 Editions. Only protects limited system binaries, by default, regardless of the hardwareenforced DEP capabilities of the processor. Can be disabled for 32-bit applications. Cannot be disabled for 64-bit applications.
27
FINAL
Power Management in x64

AMD x64 systems feature AMD CoolnQuiet technology that allows Windows x64 Editions to perform processor performance state throttling, a mechanism that reduces processor power consumption while delivering performance on demand when system loading requires higher performance states. AMD CoolnQuiet technology automatically and continuously adjusts CPU voltage and operating frequency based on application and other system loading factors. AMD CoolnQuiet is designed to work with CPU cooling devices that support thermal control of fan speed to reduce system noise and further reduce overall power consumption. AMD CoolnQuiet can be enabled on computers that meet the following requirements: AMD Athlon 64-bit processor Motherboard with a basic input/output system (BIOS) that supports AMD CoolnQuiet technology A properly installed and configured AMD processor driver and utility
Enabling AMD CoolnQuiet

Windows x64 Editions support a variety of power options as shown in Figure 8.
Figure 8. Using Windows Power Options to Enable CoolnQuiet
To enable AMD CoolnQuiet, open the Power Options applet in the Windows Control Panel, select the Power Schemes option tab, and then select Minimal Power Management shown in Figure 8. The Minimal Power Management option shown in Figure 8 supports AMD CoolnQuiet. The Portable/Laptop and Presentation options also allow processor performance state
28
FINAL
throttling but use different settings for turning off the monitor and hard disk and switching to system standby. The Max Battery option also uses this technology and forces the system into the lowest state for maximum power savings and minimum noise emission for properly equipped systems. Other options such as Home/Office Desk and Always On do not enable AMD CoolnQuiet.
Verifying CoolnQuiet Operation

To verify that CoolnQuiet is enabled, open the System Properties dialog and select the General tab as shown in Figure 9. When CoolnQuiet is enabled and the system is idle, the dialog box will display a clock frequency or processor speed of 800 MHz. When the system is active, the dialog box will display a higher clock frequency.
Figure 9. System Properties with CoolnQuiet Enabled
Third party CPU clock utilities such as WCPUCLK may also be used to verify clock frequency. For more information about AMD CoolnQuiet technology, see:
http://www.amd.com.hk/us-en/processors/ProductInformation/ 0,,30_118_9485_9487^10272,00.html
29
FINAL
HyperTransport Technology
HyperTransport technology is a new, low latency input/output (I/O) bus and interprocessor communications technology available only on AMD processors. HyperTransport technology is implemented at the motherboard level to increase the data transfer rate between HyperTransport-aware devices and system resources based on the core clock speed of such devices. Figure 10 illustrates the HyperTransport architecture.
Figure 10. HyperTransport Architecture
On a system equipped with HyperTransport capabilities, the I/O bus creates links between embedded devices such as the Accelerated Graphics Port (AGP) slot, Universal Serial Bus (USB) host controller, system memory as well as a CPU-to-CPU connection in multiprocessor computers. Because the current Peripheral Component Interconnect (PCI) bus architecture supports a maximum data rate of 133 megabytes per second (MB/sec) and current system devices such as CPUs and video cards can move data at up to 20 gigabytes per second (GB/sec), the PCI bus may limit system performance. HyperTransport eliminates this problem while maintaining compatibility with other bus architectures. HyperTransport does not affect the core clock speed of devices attached to the bus, but reduces latency and boosts communication speed for HyperTransport-aware devices. AMD processors use a coherent version of HyperTransport as an inter-processor communications link to create a multi-processor system. This multi-processor configuration is referred to as a ccNUMA architecture. The ccNUMA architecture based on HyperTransport has the advantage of scaling memory and I/O bandwidth with the number of processors, is fully supported by the x64 Windows operating system, and its operation is completely transparent to the end user.
30
FINAL
HyperTransport Data Transfer

The HyperTransport data transfer model is similar to the Open Systems Interconnection (OSI) model. The architecture defined by AMD uses five different layers: The physical layer defines the physical and electrical characteristics of the protocol. This layer interfaces to the physical world and includes data, control, and clock lines. The data link layer includes the initialization and configuration sequence, periodic cyclic redundancy check (CRC), disconnect/reconnect sequence, information packets for flow control and error management, and double word framing for other packets. The protocol layer includes the commands, the virtual channels in which they run, and the ordering rules that govern their flow. The transaction layer uses the elements provided by the protocol layer to perform actions, such as reads and writes. The session layer includes rules for negotiating power management state changes, as well as interrupt and system management activities.
HyperTransport supports links of 2, 4, 8, 16, and 32-bits in width with clock frequencies ranging from 200 MHz to 800 MHz. At peak capacity on a 32-bit link running at 800 MHz, HyperTransport provides a total data transfer rate (throughput) of 51.2 GB/sec on the link as shown in Table 2.
Table 2. HyperTransport Throughput Scalability Chart
Clock Rate
Link Width (Number of Bits) 2 4 1.6 GB/sec 3.2 GB/sec 4.0 GB/sec 4.8 GB/sec 6.4 GB/sec 8 3.2 GB/sec 6.4 GB/sec 8.0 GB/sec 9.6 GB/sec 12.8 GB/sec 16 6.4 GB/sec 12.8 GB/sec 16.0 GB/sec 19.2 GB/sec 25.6 GB/sec 32 12.8 GB/sec 25.6 GB/sec 32.0 GB/sec 38.4 GB/sec 51.2 GB/sec
200 MHz 400 MHz 500 MHz 600 MHz 800 MHz
0.8 GB/sec 1.6 GB/sec 2.0 GB/sec 2.4 GB/sec 3.2 GB/sec
31
FINAL
Identifying HyperTransport Devices

Figure 11 shows HyperTransport components displayed in Device Manager on a multiprocessor computer.
Figure 11. Using Device Manager to Identify HyperTransport Components
32
FINAL
PCI Express Technology

As stated earlier, the PCI bus has been a serviceable I/O standard for over 10 years but has now become a system bottleneck due to increases in the speed of other system devices. PCI Express was developed by PCI-SIG, the Special Interest Group responsible for PCI Express architecture, as a means of implementing a new standard based on the PCI standard that will eventually replace PCI and AGP as the primary PC I/O bus. PCI is a parallel bus. PCI Express is a serial-based bus that uses lanes and links to move data. Links define the shared serial interface used by two devices, and lanes represent the dual unidirectional channel for communications between two PCI Express devices. Lanes consist of two low voltage signal pairs that can carry 2.5 GB/sec in one direction. PCI Express devices are connected by links that may include one or more lanes as shown in Figure 12. Links may be 1, 2, 4, 8, 12, 16, or 32 bits in width.
Figure 12. PCI Express Data Links
PCI Express uses 8-bit or 10-bit encoding, which allows for two extra bits of encoding for embedding clock signal in a data stream. Using the 2.5 GB/sec of throughput provided by the specification, you can determine the throughput in MB/sec of each lane. Table 3 illustrates how you can increase throughput by adding lanes.
Table 3. PCI Express Throughput Scalability
Number of Lanes per Link 1 2 4 8 12 16 32
Bidirectional Throughput in MB/sec 250 500 1,000 (approximately 1 GB/sec) 2,000 (approximately 2 GB/sec) 3,000 (approximately 3 GB/sec) 4,000 (approximately 4 GB/sec) 8,000 (approximately 8 GB/sec)
PCI Express technology is CPU architecture-independent, while HyperTransport technology is specific to AMD processors. Motherboards manufactured for both Intel and AMD processors provide PCI Express slots. For more information on PCI Express, see: http://www.pcisig.com/home.
33
FINAL
Identifying PCI Express Components

PCI Express components appear in Device Manager as shown in Figure 13.
Figure 13. Using Device Manager to Identify the PCI Express Components
34
FINAL
Identifying x64 Processors

The x64 platform supports both AMD and Intel CPU implementations. Different methods may be required to identify the installed processor described as follows: Use Device Manager to check the CPU designation: AMD processors are identified as AMD64. Intel processors are identified as Genuine Intel. The Details tab in the CPU Properties dialog box should display the EM64T processor family designation. Using the Registry Editor, check the value of the PROCESSOR_IDENTFIER registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\ Environment\PROCESSOR_IDENTIFIER
o o
For AMD processors, the registry key value is set to AMD64. For Intel processors, the registry key value is set to EM64T.
In a command window, use the set command to display the environment values. o o The PROCESSOR_ARCHITECTURE value will show AMD64 for both AMD and Intel x64 processors. The PROCESSOR_IDENTIFIER values show the vendor family, model, and stepping. This value will indicate whether the CPU is an AMD or Intel processor.
DEMO: Identifying x64 CPUs

This demonstration illustrates: How to identify x64 CPUs in Device Manager. How to identify x64 CPUs in the registry.
35
FINAL
Resources
For more information about technologies discussed in this section, see: AMD CoolnQuiet technology resources at: http://www.amd.com/usen/Processors/SellAMDProducts/0,,30_177_4458_3505^ 9487^10272,00.html HyperTransport technology resources at: http://www.HyperTransport.org PCI Express technology resources at: http://www.pcisig.com/home
36
FINAL
Summary
Topics discussed in this session include: Overview of the x64 Architecture Data Execution Prevention Support HyperTransport Technology PCI Express Technology Identifying x64 Processors
37
FINAL
3. Examining Key Changes

This session describes key hardware, directory, registry, and application support changes that have been implemented in Microsoft Windows x64 Edition operating systems, and explains the impact of those changes on installation and troubleshooting of x64 systems.
Before You Begin

What You Will Learn

After completing this session, you will be able to: Describe file system changes implemented in Windows x64 Editions operating systems. Explain how the 64-bit Windows on Windows (WOW64) subsystem uses the registry to maintain compatibility with both 32-bit and 64-bit applications. Describe enhanced memory and CPU capabilities available on x64 systems. Describe new error messages provided by Windows x64 Editions operating systems. Describe changes in hardware abstraction layer (HAL) support, mass storage driver installation, and Windows File Protection implemented in Windows x64 Editions operating systems. Explain support for 16-bit, 32-bit, and 64-bit applications available in Windows x64 Editions operating systems and identify 32-bit application processes. Describe memory dump options available on x64 systems and explain how to obtain memory dumps.
39
Examining Windows 64-Bit Architecture 3. Examining Key Changes
FINAL
File System Changes in x64 Editions

With the introduction of x64, Microsoft had to make several changes to the core operating system to facilitate the ability to run 32-bit and 64-bit code simultaneously.
32- and 64-bit code cannot run simultaneously in the same process. However, an application that uses a 32-bit UI and 64-bit back-end or engine may contain a 32-bit process interacting with a 64-bit process and 32-bit and 64-bit applications may run simultaneously.
Note:
The x64 processors support 32-bit code running without recompilation because the x64 instruction set is an extension of the x86 instruction set. To accommodate 32-bit and 64-bit applications, the following directory changes have been implemented in Windows x64 Editions operating systems: %systemroot%\system32 This folder houses 64-bit system files. 64-bit applications install files to this folder. %systemroot%\syswow64 This folder houses 32-bit system files and is used for backward compatibility. 32-bit application files that would normally install to \system32 are redirected to this folder. %systemdrive%\Program Files This folder houses 64-bit applications. %systemdrive%\Program Files (x86) This folder houses 32-bit applications.
The existing Itanium Windows platform uses a similar directory structure. A detailed description of directory changes will be provided later in this course.
WOW64 File System Redirection

The %systemroot%\System32 directory is reserved for 64-bit applications. Because most dynamic link library (DLL) file names were not changed when they were ported to 64-bit versions, 32-bit applications must use a different directory as their System32 directory. WOW64 hides this difference through use of a file system redirector. Whenever a 32-bit application attempts to access %systemroot%\System32, the access is redirected to the new %systemroot%\SysWOW64 directory. Additionally, when a 32-bit application is installed on an x64 system, WOW64 takes over the installation process and seamlessly moves the 32-bit application files to the Program Files (x86) directory without any user intervention. As a result, users do not observe any changes regarding the installation process. A more detailed discussion of the WOW64 subsystem follows later in this course.
40
FINAL
The following directories are currently exempted from redirection: %windir%\system32\spool %windir%\system32\catroot %windir%\system32\catroot2 %windir%\system32\drivers\etc
Windows File Protection Changes

To guard protected system files, Windows File Protection (WFP) is used a little differently in x64 than in x86. In x64, the dllcache folder holds both 32-bit and 64-bit protected copies of system files. Since the 64-bit and 32-bit versions of a file may have the same file name, 32-bit files have the letter w prefixed to their file names; for example, the 32-bit version of notepad.exe will appear as wnotepad.exe in dllcache. This change is required to differentiate between 32-bit and 64-bit files with otherwise identical names.
32-bit DLLs located in the i386 directory on the Windows x64 installation CD also have the letter w prefixed to their file names.
Note:
Verifying File Bit Level

You can check bit state information (16, 32, or 64) by using the filever.exe utility that is included in the Support Tools file (support.cab) to determine if an application is compatible with 64-bit systems. This utility displays bit-level file information as shown in the following filever.exe output:
--a-d-----a---a---a---a-W16 W32i W16 WAMD64 W32i64 DLL DLL APP APP APP ENU ENU ENU ENU ENU 1.7.0.0 1.7.1.1 1.7.0.0 1.7.1.0 1.7.1.0 shp shp shp shp shp 0 50,688 49,680 41,472 70,144 94,784 03-12-2004 twain.dll 08-11-2004 [twain_32] 08-09-2004 twain_32.dll 03-12-2004 twunk_16.exe 08-09-2004 twunk_32.exe 02-05-2003 twunk_32.exe
The output shown in this example includes the following bit level information: W16 indicates a 16-bit file. No bit level value is displayed for a directory listing. W32i indicates a 32-bit file. WAMD64 indicates a 64-bit x64 file. W32i64 indicates a 64-bit Itanium file.
41
FINAL
Registry Changes in x64 Editions

The Windows x64 Editions use a different registry layout to accommodate 32-bit and 64-bit applications. Registry layout changes ensure that hard-coded DLL paths, applications settings, and other parameter values are not overwritten. 32-bit and 64-bit applications running in Windows x64 Edition operating systems operate in different modes and use different registry sections as follows: Native Mode 64-bit applications run in native mode and access keys and values stored in the following registry section:
HKEY_LOCAL_MACHINE\Software
WOW64 Mode 32-bit applications run in WOW64 mode and access keys and values stored in the following registry section:
HKLM\Software\WOW6432node
To accomplish these tasks, Windows x64 Editions store the settings for 32-bit applications in a new branch in the registry. Users will not notice any changes during application installations; registry redirection and reflection allows application installations and configuration settings to access the different registry sections without user intervention.
Registry Redirection
To support the coexistence of 32-bit and 64-bit COM registration and application states, the WOW64 subsystem presents 32-bit applications with an alternate view of the registry. The WOW64 subsystem uses registry redirection to intercept registry calls at a bit level and ensure that registry calls are directed to the proper trees in the registry. During installation or normal operations, registry calls made by 64-bit applications access HKLM\Software key without redirection. WOW64 intercepts registry calls to HKLM\Software made by 32-bit applications and redirects them to HKLM\Software\WOW6432node key. By redirecting only 32-bit calls, WOW64 ensures that applications always write to the appropriate registry key. Registry redirection does not require application code modification and is performed transparently.
Keys Included in Redirection

The following keys are redirected in current versions of Windows x64 Edition operating systems: HKEY_LOCAL_MACHINE\Software\Classes HKEY_LOCAL_MACHINE\Software\Ole HKEY_LOCAL_MACHINE\Software\Rpc
42
FINAL
HKEY_LOCAL_MACHINE\Software\COM3 HKEY_LOCAL_MACHINE\Software\EventSystem
Important:
Registry key redirection may change in later operating system versions. Software developers are encouraged to avoid writing application code based on previously documented lists of redirected keys; instead, code should be written to verify redirection status before making calls to the 32-bit or 64-bit logical view of the registry.
Registry Reflection
Registry reflection provides a real-time method to hold the 32-bit and 64-bit sections of the registry open at all times. For example, consider a 32-bit application named Hello.exe that acts as a 32-bit OLE server but can also serve requests from 64-bit clients. Registry reflection allows the Hello.exe application to keep both the 32-bit registry and the 64-bit registry open to handle both 32-bit and 64-bit application calls. Reflection allows the existence of two physical copies of the same registry to support simultaneous native and WOW64 operations. Most of the keys that are reflected are class keys. Class keys are written with a last writer wins philosophy, and the handle to the key is closed when either the 32-bit or 64-bit class key is written and closed. The following is an example of last writer wins: 1. After a clean installation of a Windows x64 Edition operating system, 64-bit Wordpad.exe is registered to handle .doc files. The registry reflector copies the .doc registration from the 64-bit registry section into the 32-bit registry section. 2. An administrator installs 32-bit Office, which registers Winword.exe to handle .doc files, in the 32-bit registry view. The registry reflector copies this information into the 64-bit registry section so both 32-bit and 64-bit applications launch the 32-bit version of Winword.exe for .doc files. 3. An administrator installs 64-bit Office, which registers the 64-bit version of Winword.exe in the 64-bit registry section to handle .doc files. The registry reflector copies this information into the 32-bit registry section so both 32-bit and 64-bit applications launch the 64-bit version of Winword.exe for .doc files.
Developers can use RegQueryReflectionKey function to determine the reflection state for a particular key and use the RegDisableReflectionKey and RegEnableReflectionKey functions to disable and enable registry reflection for a particular key programmatically.
Note:
Shared Registry Keys

Certain keys contain constant information that exists in only one copy of the registry even though these keys appear in both 32-bit and 64-bit registry views. In current version of the Windows x64 Edition operating systems, the following keys are shared across 32-bit and 64-bit applications and are not rewritten based on the 32-bit or 64-bit level of the application or process:
FINAL
HKLM\SOFTWARE\Microsoft\SystemCertificates HKLM\SOFTWARE\Microsoft\Cryptography\Services HKLM\SOFTWARE\Classes\HCP HKLM\SOFTWARE\Microsoft\EnterpriseCertificates HKLM\SOFTWARE\Microsoft\MSMQ HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkCards HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Ports HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Control Panel\Cursors\Schemes HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Telephony\Locations HKLM\SOFTWARE\Policies HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\OC Manager HKLM\SOFTWARE\Microsoft\Software\Microsoft\Shared Tools\MSInfo HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup HKLM\SOFTWARE\Microsoft\CTF\TIP HKLM\SOFTWARE\Microsoft\CTF\SystemShared HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts HKLM\SOFTWARE\Microsoft\RAS HKLM\SOFTWARE\Microsoft\Driver Signing HKLM\SOFTWARE\Microsoft\Non-Driver Signing HKLM\SOFTWARE\Microsoft\Cryptography\Calais\Current HKLM\SOFTWARE\Microsoft\Cryptography\Calais\Readers HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones HKLM\SOFTWARE\Microsoft\Transaction Server
44
FINAL
Important:
Registry key reflection may change in later operating system versions. Software developers are encouraged to avoid writing application code based on previously documented lists of reflected keys; instead, code should be written to verify reflection status before making calls to the 32-bit or 64-bit logical view of the registry.
Registry Editor Changes

Both 32-bit and 64-bit versions of the Registry Editor are included with x64 Edition operating systems. The 64-bit version of the Registry Editor can be launched from the Run dialog by entering regedit.exe. The 32-bit version of the Registry Editor can be launched from the Run dialog by entering %systemroot%\syswow64\regedit.exe m. The m switch allows you to run multiple instances of the Registry Editor.
To better understand the 64-bit and 32-bit application sections of the registry, perform the following steps: 1. 2. Open the Run dialog and enter regedit.exe to launch the 64-bit Registry Editor, examine the syswow64 node key, and then close regedit.exe. In the Run dialog, enter %systemroot%\syswow64\regedit.exe m to open the 32-bit version of the Registry Editor and note the differences.
Note:
DEMO: Examining 32-Bit and 64-Bit Registry Keys

This demonstration illustrates: How to use regedit.exe to view 64-bit registry keys and values. How to use %systemroot%\syswow64\regedit.exe to view 32-bit registry keys and values. Changes resulting from installation of a 32-bit application.
For more information about registry redirection and reflection, see the following articles available in the Microsoft MSDN Library: http://msdn.microsoft.com/library/default.asp?url=/library/enus/win64/win64/registry_redirector.asp http://msdn.microsoft.com/library/default.asp?url=/library/enus/win64/win64/registry_reflection.asp
Remote Registry Access in 64-bit Windows

Clients running Microsoft Windows Server 2003 SP1 or later or x64 Edition operating systems can view the 64-bit portion of the registry on remote systems running Microsoft Windows Server 2003 SP1 or later or an x64 Edition operating system. However, clients running 32-bit operating system versions without SP1 can only view the 32-bit portion of the registry on remote systems.
FINAL
When you troubleshoot 32-bit application settings on remote systems, remember that all 32-bit calls to the HKLM\Software key are redirected to the HKLM\Software\WOW6432node key and make sure you access the appropriate registry section on the remote system.
46
FINAL
Enhanced Memory and CPU Capabilities in x64 Editions

The Windows x64 Edition operating systems extend memory and CPU limits as compared to 32-bit Windows operating systems. Table 4 compares maximum memory and CPU capabilities.
Table 4. Comparing Memory and CPU Limits in x86 and x64 Operating Systems
x86 operating system on x86 hardware Operating System Windows XP Professional Windows Server 2003 Standard Windows Server 2003 Enterprise Windows Server 2003 Datacenter Memory 4 GB 4 GB 32 GB / 64 GB
1
x64 operating system on x64 hardware Memory 128 GB 32 GB 1 TB 1 TB CPUs 1-2 1-4 1-8 1 - 64
CPUs 1-2 1-4 1-8

1
64 GB / 128 GB
1 - 32
Notes 1. Extended with Microsoft Windows Server 2003 Service Pack 1.
Table 5 compares virtual address space, paged and non-paged pool, desktop heap, and system cache capabilities for 32-bit and 64-bit operating systems. Notes at the bottom of the table describe applicable conditions and requirements.
Table 5. Comparison Between Memory Limits of 32-bit and 64-bit Systems
Memory Limits for Virtual Address Space Total Virtual Address Space per 32-bit Process Virtual Address Space per 64-bit Process Paged Pool Non-paged Pool Desktop Heap System Cache
32-bit 4 GB 2 GB / 3 GB 1 Not applicable 470 MB / 650 MB 3 256 MB 48 MB 4 1 GB
64-bit 16 TB 2 GB / 4 GB 2 8 TB 128 GB 128 GB 104 MB 5 1 TB
47
FINAL
32-bit 64-bit
Memory Limits for Notes
Applications must be compiled with /LARGEADDRESSAWARE and the /3gb switch must be included in BOOT.INI. Applications must be compiled with /LARGEADDRESSAWARE, but the /3gb switch is not needed in BOOT.INI. Extended with Windows Server 2003 Service Pack 1. May be configured to larger values dependent on amount of physical memory and other factors; larger values may not exceed 1 GB and may be limited to much lower values on some computers. Configurable up to 8 GB for Itanium; configurable up to 1 GB in pre-release x64 versions but may increase in later versions.
Windows x64 Edition operating systems offer much higher physical and virtual limits than x86 operating systems can provide. In the x64 environment, the /PAE switch available in the x86 operating systems is no longer needed because 64-bit memory addressing allows x64 operating systems to access large amounts of RAM at the hardware level. Note that the Address Windows Extensions (AWE) application programming interface (API) and the accompanying /AWE switch can be used in both x86 and x64 operating environments. The /3GB switch is not supported on Windows x64 Editions. Windows x64 Editions provide 2 GB of virtual address space to 32-bit processes. Windows x64 Editions can allocate 4 GB of virtual address space to 32-bit processes compiled with the /LARGEADDRESSAWARE switch. Windows provides 4 GB of virtual address space to 32-bit processes. 32-bit processes are limited to the first 2 GB unless the 32-bit processes have been compiled with the /LARGEADDRESSAWARE switch. Processes compiled with the /LARGEADDRESSAWARE switch can access the full 4 GB of virtual memory address space.
48
FINAL
Installation and Configuration Changes

Changes in Windows x64 Edition operating system installation and configuration accommodate x64 hardware changes and file system and registry changes implemented in the new operating system versions. Changes include: New Version Mismatch Error Messages HAL Support Changes New Driver INF Requirements Mass Storage Device Driver Installation Changes
New Version Mismatch Error Messages

Attempting to launch the 64-bit setup program included on an x64 operating system CDROM within any version of Windows for the x86 platform displays the error message shown in Figure 14.
Figure 14. Incorrect Version Error Message 1
You may also receive the following error message:

Figure 15. Incorrect Version Error Message 2
These error messages are displayed because Winnt32.exe on a Windows x64 Edition installation CD is a 64-bit application and cannot be launched from within a 32-bit operating system.
HAL Support Changes in x64 Editions

Windows x64 Editions only support the Advanced Configuration and Power interfaceAdvanced Programmable Interrupt Controller (ACPI-APIC) Hardware Abstraction Layer
FINAL
(HAL). Proper installation requires support for the ACPI-APIC multiprocessor HAL. Some computer manufacturers disable ACPI-APIC in the system basic input/output system (BIOS) by default; on such systems, ACPI-APIC must be enabled prior to installing Windows x64. The F5 key can still be used to specify a hardware vendor-supplied HAL driver. If a vendorsupplied HAL driver is not available, the F5 options will only allow selection of a single or multiprocessor APIC HAL. Attempting to install Windows x64 on a computer that does not support the ACPI-APIC HAL will result in one of the following errors:
Attempting to load an x86-64 operating system, however this system does not support a local APIC. Check the system's firmware settings. In particular, ensure that the firmware has enabled the APIC on this system. If the firmware does not have an APIC setting, please contact the system manufacturer for a firmware update to enable the local APIC.
Or
Check your firmware settings. In particular, ensure that the firmware has enabled the APIC on this system. If the firmware does not have an APIC setting, please contact the system manufacturer for a firmware update to enable the local APIC.
To resolve this issue, first determine if the motherboard supports the ACPI-APIC HAL. If the motherboard does not support this type of HAL, Windows x64 Editions cannot be installed. If the motherboard supports the ACPI-APIC HAL, ensure that BIOS options are set to boot the correct HAL.
New Driver INF Requirements

On Microsoft Windows XP and on the original release of Windows Server 2003, the INF parser uses the decorated section name if specified; otherwise, it uses the undecorated section name. However, in Windows Server 2003 SP1 and later versions, the INF parser looks for undecorated sections only on x86-based platforms. On non-x86-based platforms running Windows Server 2003 SP1 and later versions, the INF parser requires the TargetOsVersion decoration for the [Models] section. For example, if a user attempts to install an undecorated driver package on an x64-based system, Plug and Play (PnP) does not find a decorated [Models] section, and therefore, does not try to match any device IDs. Table 6 describes installation behavior based on different operating system versions.
Table 6. Installation Behavior on Different Platforms
Operating System
Undecorated
Decorated for x86 X
Decorated for Itanium N/A
Decorated for x64 N/A
Windows 2000 x86 platform

50
FINAL
Operating System Undecorated Decorated for x86 X X
Decorated for Itanium X X X
Decorated for x64 N/A X X
Windows XP x86 platform Windows Server 2003 SP1 x86 platform Windows Server 2003 SP1 Itanium platform Windows Server 2003 SP1 x64 platform
X* X
Legend Device models within the corresponding INFs are found and matched for potential installation. X Device models within the corresponding INF are not found; installation does not occur. * Undecorated INFs for Itanium-based platforms are allowed for packages with a DriverVer date before release to manufacturing (RTM) of Windows Server 2003 SP1 to avoid breaking released driver packages.
Driver INF file requirements are discussed in more detail in later sections of this course.
Mass Storage Driver Installation Changes

To clarify issues related to installing 32-bit mass storage drivers and to simplify procedures for troubleshooting issues that involve 64-bit mass storage drivers, the prompt for installing mass storage drivers during setup using the F6 key has changed in x64 Editions. A new error message indicates potential mass storage driver problems as follows:
Setup could not determine the type of one or more mass storage devices installed in your system, or you have chosen to manually specify an adapter. Currently setup will load support for the following mass storage device: <none> To specify additional SCSI adapters, CD-ROM drives, or special disk controllers for use with Windows, including those which you have a device support disk from a mass storage device manufacturer, press S If you do not have any device support disks from a mass storage device manufacturer, or do not want to specify additional mass storage devices for use with Windows, press ENTER
This change enables users, particularly those in the consumer segment, to install their own device drivers manually for use with Windows and assists Microsoft technical support personnel in resolving such issues.
51
FINAL
If users attempt to install 32-bit device drivers, the following error message will be displayed:
The device associated with the following device driver will not work correctly on this computer: %path%\devicedriver.sys The device driver is only compatible with the 32-bit version of Windows. This device driver may be required to complete Windows Setup. Please contact the device manufacturer to obtain drivers compatible with the 64-bit version of Windows.
The F6 prompt change also relates to changes in the mass storage controller driver search process. In 32-bit Windows, using F6 to specify a driver manually initiated a search of the root of the drive to locate the txtsetup.oem file required for driver installation. The x64 Editions use the AMD64 folder for installation; if an original equipment manufacturer (OEM) driver package does not include the AMD64 folder in its directory structure, the setup program will be unable to locate the txtsetup.oem file. To avoid this problem, the x64 Edition setup program begins by searching for an AMD64 folder on the floppy drive. If the txtsetup.oem cannot be located on the floppy drive, the setup program then searches the root of the drive for the file. If the driver file specified in the txtsetup.oem file is a 32-bit driver, the driver incompatibility message shown in the previous example will be displayed. For more information about changes for vendor-provided storage drivers loaded using F6, see: http://www.microsoft.com/whdc/device/storage/f6dirs.mspx.
Important: Some OEM computer systems include mass storage drivers stored in firmware on the motherboard. The BIOS mounts the firmware as a virtual OEM device and assigns it a floppy drive letter. The Setup loader searches these locations for the existence of a txtsetup.oem file. These computers do not require the user to press F6; instead, the mass storage driver is automatically provided to Text Mode setup. In x64, this method of providing mass storage drivers may cause issues because firmware files may include 32-bit drivers that cannot be properly loaded by Windows x64 setup. As a result, the user will receive an error message about specifying a 32-bit driver even though F6 was not pressed. In such cases, check for a BIOS upgrade to resolve the issue. Note that pressing F4 when the option to press F6 is displayed skips the check for the virtual OEM device. Unattended installation options can also be used to control this behavior.
52
FINAL
Application Support Changes

Windows x64 Edition operating systems include changes in 16-bit, 32-bit, and 64-bit application support.
16-bit Application Support

Windows x64 Edition operating systems do not support installation or use of any 16-bit applications. For customers that require support for 16-bit applications, a dual-boot configuration may be implemented by installing a 32-bit operating system prior to installing the x64 operating system. This configuration allows use of the 32-bit operating system for 16-bit application support. Because of this change, the following sub-systems and network protocols are no longer available in x64: MS-DOS Open Shortest Path First (OSPF)
The Windows x64 Edition operating systems provide limited support for 32-bit applications with 16-bit installers. When a 32-bit application with a 16-bit installer attempts to install on a Windows x64 Edition, the installer is checked against the entries in the following registry key:
HKLM\Software\Microsoft\Windows NT\Current Version\NTVDM64
If an applications installer is listed in the branches under this key, then Setup16.exe is called from the SysWOW64 directory and used as a shim to upgrade the 16-bit installer to a compatible 32-bit installer. This allows the application to install without additional user intervention. Applications that use this shim appear to install the same as on an x86 platform. For applications that cannot be shimmed, customers must contact the specific Independent Software Vendor (ISV) responsible for the installer to obtain a compatible 32-bit or 64-bit installer.

The Windows x64 Edition operating systems provide full support for 32-bit applications, but do not allow the use of 32-bit kernel-mode drivers. This means that antivirus programs and other applications that use 32-bit kernel-mode drivers and filter drivers must be upgraded to use 64-bit drivers in order to install and run properly. Although applications that use 32-bit kernel mode drivers may install properly on x64, launching such applications will generally result in a blue screen or user mode error. If an application causes a blue screen error, check for the existence of 32-bit kernel-mode drivers and filter drivers in the Windows\System32\Drivers and the SysWOW64 directories. If the
53
FINAL
application has installed 32-bit kernel-mode drivers, you should have the customer uninstall the application and contact the ISV to obtain a compatible product.

All 64-bit applications require a 64-bit installer to properly access the system folder and the native 64-bit registry hives. If a customer encounters issues with a 64-bit application installing to the SysWOW64 hive or (x86) Program Files directory, check for use of a 32-bit installer file. If the installer is a 32-bit version, the ISV must provide a 64-bit installer to enable access to the 64-bit directories and registry keys.
DEMO: Identifying 32-bit Application Processes

This demonstration illustrates: How to launch 32-bit applications. How to identify 32-bit processes in Task Manager.
54
FINAL
Memory Dump Options

Memory dumps in x64 editions are functionally the same as in x86 versions. Mini dumps have grown in size from 64 KB in x86 to 128 KB in x64. However, the ability to support such large amounts of physical RAM will now enable customers to write extremely large memory dump files when their systems are set to write full memory dumps. For example, if configured with a pagefile at the root as large as the amount of physical RAM + 12 megabytes (MB), a fully configured system running Microsoft Windows Server 2003 Datacenter Edition could write a 1 terabyte memory.dmp file. Such a scenario would be plausible in a storage area network (SAN) implementation. The largest memory dump file size observed thus far is 16 terabytes; the system in question took 30 hours to create this file. The /MAXMEM switch in BOOT.INI (or /burnmemory) is still a viable option for creating memory dump files on large RAM-enabled systems, if needed. Mini dumps are still the default memory dump type in Windows x64 Editions.
Debugging 64-bit Memory Dumps

Debugging 64-bit memory dumps is different from the method for debugging x86 memory.dmp files. When debugging x64 systems, be aware of the following: The current version of WinDBG can debug x64-generated memory.dmp files regardless of whether the debugger is installed on a 32-bit or 64-bit operating system. You can run a live debug session on an x64 system from an x86 client, but you may be warned that you are using a 32-bit debugger to debug a 64-bit process.
For best results, use a 32-bit debugger installed on a 32-bit operating system when you debug a 32-bit process and use a 64-bit debugger installed on a 64-bit operating system when you debug a 64-bit process. This recommendation only applies to crash dumps generated within an x64 environment. Updates planned for the Microsoft Visual Studio 2005 release will fully support debugging 32-bit and 64-bit processes on any platforms.
Note:
55
FINAL
Resources
The following resources provide additional information about topics discussed in this session: For more information about registry redirection and reflection, see the following articles available in the Microsoft MSDN Library: o o http://msdn.microsoft.com/library/default.asp?url=/library/enus/win64/win64/registry_redirector.asp http://msdn.microsoft.com/library/default.asp?url=/library/enus/win64/win64/registry_reflection.asp
For more information about changes for vendor-provided storage drivers loaded using F6, see: o http://www.microsoft.com/whdc/device/storage/f6dirs.mspx
56
FINAL
Summary
Topics discussed in this session include: File System Changes in Windows x64 Editions o o WOW64 File System Redirection Windows File Protection Changes
Enhanced Memory and CPU Capabilities in Windows x64 Editions Installation Changes in x64 Editions o o o New Version Mismatch Error Messages HAL Support Changes x64 Editions Mass Storage Driver Installation Changes
16-, 32-, and 64-bit Application Support Memory Dump Options in x64
57
FINAL
58
FINAL
4. Installation and Configuration

This session describes the setup process for Microsoft Windows x64 Editions operating systems, and discusses special considerations for operating system and driver installation and configuration.
Before You Begin

What You Will Learn

After completing this session, you will be able to: Describe special considerations for installing Windows x64 Edition operating systems and hotfixes. Explain INF decoration requirements for drivers used with Windows x64 Edition operating systems. Describe the options for deploying Windows x64 Edition operating systems. Enable use of Windows Management Instrumentation (WMI) providers in Windows Preinstallation Environment (WinPE). Describe Machine Check Architecture (MCA) events. Explain how to use single and dual boot options available in Windows x64 Edition operating systems. Remove the x64 operating system from a dual boot configuration. Transfer files from x86 to x64 systems. Compare the directory structures used in x86 and x64 operating systems.
59
Examining Windows 64-Bit Architecture 4. Installation and Configuration
FINAL
Installation Considerations
The Windows x64 installation process is similar to the installation process for the x86 platform. The x64 installation still copies the needed files to temporary directories, reboots the system into graphical user interface (GUI) mode, performs Plug and Play (PnP) detection and installation, and then completes the setup process. Although some GUI mode graphics have been updated to profile new features in x64, the installation procedure appears almost identical to the end user. Windows x64 Edition installation differs from x86 installation as follows: Boot floppies cannot be used for installation, primarily because the kernel supplied with x64 Edition operating systems is now over 2 MB in size and will not fit on a floppy disk. Currently installed Windows x86 versions cannot be upgraded to x64 Editions. However, Windows x64 Edition operating systems do support upgrades from Windows Server 2003 x64 Standard Edition to Windows Server 2003 x64 Enterprise Edition. The installation process for x64 Edition operating systems cannot be launched from within a 32-bit operating environment. The installation process for x86 32-bit operating systems cannot be launched from within the x64 operating environment. The installation process for x64 Edition operating systems does not support MSDOSbased mechanisms. The installation process primarily relies on files stored in the AMD64 folder but also requires 32-bit file versions stored in the i386 folder. In addition, you cannot perform an installation by copying the AMD64 directory to a hard drive and running Winnt32.exe because the installation process requires files stored in multiple folders on the installation CD. For this reason, installations must be performed from an installation CD or from properly configured installation sources described later in this course. The Windows x64 Edition operating systems are not currently available as retail products. Current release and distribution plans target MSDN, Software Assurance, volume channels, and original equipment manufacturer (OEM) channels.
CD-ROM Layout Changes

The CD-ROM layout has changed in x64. The primary installation directory in x64 is now the AMD64 directory; however, the i386 directory is still present and contains files required for operating system installation. For this reason, launching an installation from a local or network share copy of the AMD64 directory would require starting setup from within a 64-bit operating system and copying a number of other directories. Because the installation process uses more than just the AMD64 directory, the full directory structure that is provided on the installation CD must be available for all installations.
60 2010 Microsoft Corporation. All rights reserved.
FINAL
Preferred Installation Methods

Because of these changes, Microsoft technical support recommends a clean installation of Windows x64 Editions operating systems from CD-ROM for most customers. The Windows x64 Editions operating systems may also be deployed using Unattended Installation, System Preparation Tool (Sysprep), and Remote Installation Services (RIS) methods as discussed later in this course. Volume-licensed media will be available to accommodate large deployments.
Troubleshooting Installation Issues

Troubleshooting procedures for Windows x64 Editions installations are also similar to troubleshooting procedures for x86 installations. For example, computer hardware issues are a common cause of clean installation failures. In most cases, such problems can be resolved by testing to ensure that the mass storage controller driver is a 64-bit driver and that the device is compatible with x64 Edition operating systems. When you attempt to run WINNT32.EXE from an x64 installation CD within a 32-bit operating system, you will receive the error message shown in Figure 16.
Figure 16: WINNT32 Version Mismatch Error Message
If you attempt to run the 32-bit instance of WINNT32.exe from within an x64 operating system, you will receive the error message shown in Figure 17.
Figure 17: Windows Setup Version Mismatch Error Message
61
FINAL
In either instance, you will not be able to install the corresponding operating system. To build a dual-boot system, you must first install the 32-bit operating system and then install the x64 operating system on a new partition or hard disk.
Hotfix Considerations
As expected, x64 will have its own tree of security updates and hotfix installable executables. The Windows x64 Edition operating systems support sticky hotfixes. Sticky hotfixes ensure that the latest versions of system files are installed on the computer when hotfixes or updates are applied by only overwriting existing files on the computer when files in the hotfix provide a more recent version. Attempting to install the 32-bit version of a Windows Server 2003 or Microsoft Windows XP security update or hotfix on x64 Editions displays the error message shown in Figure 18.
Figure 18: Hardware Mismatch Error Message
Customers may also attempt to install Itanium versions of security updates and hotfixes because 64-bit Edition is included in Itanium product names. Attempting to install the Itanium version of a Windows Server 2003 or Windows XP security update or hotfix on x64 Editions displays the error message shown in Figure 19.
Figure 19: Machine Type Mismatch Error Message
Important:
A clear understanding of version update requirements and specific 64-bit hardware supported by Microsoft is critical for successful installation of Windows x64 Editions operating systems, security updates, and hotfixes.
62
FINAL
Driver Support Considerations

As mentioned previously, Windows x64 Editions require all applications and devices to use 64-bit drivers when running within Windows x64. 32-bit operating systems installed on x64 capable hardware still use 32-bit drivers as noted in Table 7.
Table 7: Driver Support Chart
x86 Hardware and Operating System 32-bit Application 32-bit Windows 32-bit Drivers Devices
Itanium and x64 Hardware and Operating System 32-bit Application 64-bit Windows 64-bit Drivers (No 32-bit Drivers) Devices 64-bit Application 64-bit Windows 64-bit Drivers (No 32-bit Drivers) Devices
Table 7 indicates that x64 Editions support the use of 32-bit and 64-bit applications; however, all Windows 64-bit operating systems require 64-bit device drivers. Additional 64-bit drivers that are not provided on Windows x64 Edition installation CD must be obtained from the device manufacturer. WHQL-certified drivers may also be downloaded from the Windows Update Web site. It is the responsibility of the specific hardware or software vendor to ensure application and device driver compatibility with x64 Editions..
Important: Both the drivers and the driver install packages must be 64-bit compatible.
Note that the requirements for drivers apply to both kernel mode and user mode components. As a result, drivers for devices such as printers, cameras and scanners, which are often user mode components, must be 64-bit drivers. Additionally, the drivers included in SP1 are not identical between the x86 and x64 editions of the products. This means that drivers available for the 32-bit version of a Microsoft Windows Server 2003 may not be available for the corresponding x64 product. Itanium-based 64-bit drivers are incompatible with x64 operating systems because they are compiled for the Itanium platform and not the x64 platform. Attempts to install Itanium drivers will fail on x64 systems. In addition, if a 64-bit driver that is not supplied with Windows fails to install, check the INF for proper decoration as described later in this session.
63
FINAL
INF Requirements for x64

Device Driver INF files on Windows x64 Editions must decorate entries in the [Manufacturer] section and the [Models] section names with .ntamd64 to specify the operating system version. INF decoration is required for all INF files in Windows x64 Editions. Because operating systems may now be installed in x86, Itanium, or x64 environments, the decoration requirements are intended to prevent consumers and administrators from installing drivers that are not intended for the specific platform being installed.
This requirement does not apply to non-device drivers that do not have [Manufacturer] and [Models] sections.
Note:
INF Decoration Behavior for Windows Server 2003 and Earlier

This section describes how the operating system treats decorated and undecorated INF files during installation for the original release of Microsoft Windows Server 2003 and earlier versions of Windows. The following example shows how typical undecorated [Manufacturer] and [Models] sections might look in a device driver package INF file:
[Manufacturer] %mycompany% = MyCompanyModels [MyCompanyModels] %MyDev% = mydevInstall, mydevHwid
This example does not use TargetOsVersion decorations. Device matching syntax rules for Windows Server 2003 and earlier versions of Microsoft Windows allow these statements to be parsed to install on any platform. Ideally, the user would not be given the choice of installing this device package unless it was certain that the package had the correct binary files, but this INF file would not prevent such an installation. The following sample shows the same [Manufacturer] and [Models] sections with a TargetOSVersion decoration that specifies the x64-based platform, where x64 refers to the 64-bit architecture used in AMD64 and Intel Extended Memory 64 Technology (EMT64) systems. The NTamd64 decoration in the INF file is used for all x64-based systems.
[Manufacturer] %mycompany% = MyCompanyModels,NTamd64 [MyCompanyModels.NTamd64] %MyDev% = mydevInstall, mydevHwid
64
FINAL
The INF file may also specify multiple architectures as shown in the following sample:
[Manufacturer] %mycompany% = MyCompanyModels,NTx86,NTItanium [MyCompanyModels.NTx86] %MyDev% = mydevInstallx86,mydevHwid [MyCompanyModels.NTItanium] %MyDev% = mydevInstallItanium,mydevHwid
When this driver package is installed, the INF parser builds up a section name including the decoration, and then checks to see whether the section name applies to the platform being targeted. If so, then the INF parser looks for that section name within the INF file and uses that section if it exists. On Windows Server 2003 and earlier versions of Windows, if the decorated section does not exist, the INF parser then checks any undecorated sections for a match. Because these decorations are not commonly used, if the parser finds a match in an undecorated section then Plug and Play (PnP) may attempt to install a driver that is not compatible with the hardware platform. Storage drivers for x64-based systems must use 64-bit INF decorations to be installed on Microsoft Windows Server 2003 Service Pack 1 (SP1) and later versions of Windows. Storage drivers that do not use 64-bit INF decorations will initially load using F6 but will generate a bug check (STOP 0x0000007B) when the system restarts for the last time after GUI Mode setup because the F6 mechanism does not use SetupAPI logic to load the storage drivers. It is not possible to recover from this STOP error; instead, you must update the storage driver and restart the setup process using F6. In such cases, you must either obtain a version of the driver that uses 64-bit INF decorations or decorate the INF file manually for 64-bit systems as described previously in this session. For more information on changes for vendor-provided storage driver loaded using F6, see: http://www.microsoft.com/whdc/device/storage/f6dirs.mspx
65
FINAL
INF Decoration Behavior for x64 Editions

Device drivers that are supplied with undecorated INF files cannot be installed on x64 operating systems. Attempts to do so produce the error message shown in Figure 20.
Figure 20. Undecorated INF Error Message
Although this requirement ensures that only drivers tested for compatibility with x64 can be installed, you may encounter situations where tested x64 drivers are not yet available. Use the following methods to troubleshoot undecorated INF issues: Ensure that you are using an x64 compatible driver for the device in question. Check for new or updated drivers with properly decorated INF files. Disable INF decoration by adding the registry key DisableDecoratedModelsRequirement in HKLM\Software\Microsoft\Windows\CurrentVersion\Setup with a non-zero DWORD value. The presence of this key and value disables the decoration requirement and allows all 64-bit drivers to install. Decorate the INF sections manually. If you need to decorate an INF manually, inform the independent software vendor (ISV) or independent hardware vendor (IHV) that the INF must be updated for x64 compatibility and inform the customer regarding the required update.
Attempts to modify 32-bit driver INF files for compliance with INF decoration requirements will fail. Such attempts will fail because the driver file remains a 32-bit driver. The x64 Edition operating systems require 64-bit driver files with correct INF decoration to verify compatibility. For more information about INF requirements for 64-bit systems, see: http://www.microsoft.com/whdc/driver/install/64INF_reqs.mspx.
66
FINAL
Deployment Options for x64 Editions

Deploy.cab is provided on the installation media in the Support\Tools folder of the CDROM. This folder contains the following files: Deploy.chm Windows Corporate Deployment help file. Factory.exe, Setupcl.exe and Sysprep.exe Tools used for hard disk duplication. Ref.chm Windows Preinstallation Environment (WinPE) reference help file. Wfinf_guide.doc OEM Preinstallation Kit (OPK) design notes for the Windows Firewall INF.
You can automate Windows x64 Edition deployment using the following methods: Unattended installation using unattend.txt or winnt.sif. System Preparation Tool (Sysprep) image deployment Remote Installation Service (RIS) deployment (requires use of a computer running Windows Server 2003 SP1 or later as a RIS server).
In addition, the next version of Automated Deployment Services (ADS) will support the automated deployment of Windows x64 Edition operating systems. Individual deployment methods and differences applicable to the x64 platform are discussed in more detail later in this session.
Using Unattended Installation for x64 Editions

The following Unattend.txt sections were added with Windows XP Service Pack 2 (SP2) and are also used for x64 installation:
[IEHardening] [WindowsFirewall] [WindowsFirewall.profile_name] [WindowsFirewall.program_name] [WindowsFirewall.service_name] [WindowsFirewall.portopening_name] [WindowsFirewall.icmpsetting_name]
The Unattend.txt [Components] section now includes the following parameters: IEHardenAdmin applies the Enhanced Security Configuration to members of the Administrators and Power Users groups. IEHardenUser applies the Enhanced Security Configuration to members of the Restricted Users and Guests groups.
67
FINAL
WbemCrrl specifies whether to install the Windows Management Instrumentation (WMI) event correlation component. WbemFwrd specifies whether to install the WMI event forwarding components. WbemMSI specifies whether to install the WMI Windows installer provider.
In the [Data] section, AutomaticUpdates specifies whether to enable Automatic Updates. In the [GuiUnattended] section, EMSSkipUnattendProcessing prevents Windows Setup from modifying Unattend.txt or Sysprep.inf during an unattended installation to an Emergency Management Services (EMS) server. In the [Unattended] section, DUStopOnError specifies whether to stop the Dynamic Update process when an error is detected. The following entries have been deleted from the [Components] section: iis_www_vdir_scripts AutoUpdate VirtualOEMDIsks More recent HP and Compaq systems provide drivers that are installed during text mode setup. When the basic input/output system (BIOS) mounts a read-only memory (ROM) image, these drivers are loaded into a virtual floppy device that is parsed during setup. The drivers on the virtual floppy device are used during setup in the same way as using the F6 option to install additional mass storage drivers. The virtual floppy device appears as the B floppy drive. In most cases, the virtual device contains only mass storage drivers. Because mass storage drivers are required to enable writing to the physical hard drive, these drivers must be loaded very early in text mode setup. Use of the virtual floppy device automates this process and allows OEMs to ship additional mass storage drivers that load during CD boot for system installation. Setup loads these drivers automatically unless parameters in the VirtualOEMDisks section of Unattend.txt are used to disable driver loading. DisableVirtualOemDevices This entry specifies whether to load virtual OEM devices during Setup. Syntax:
DisableVirtualOemDevices = [Yes | No]
where: Yes = Disables loading virtual OEM devices during Setup. No = Does not disable loading virtual OEM devices during Setup. The default for preinstallation is Yes; in all other cases, the default value is No.
68
FINAL
Example
DisableVirtualOemDevices = Yes
For more information about the format and usage of unattended installation files, refer to the article Overview of Unattended Installation available on the Microsoft Web site at: http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/de ployguide/enus/Default.asp?url=/resources/documentation/WindowsServ/2003/all/deploygui de/en-us/acicb_ui_bsay.asp.
Using System Preparation Tool (Sysprep) for x64 Editions

The System Preparation Tool utility sysprep.exe has not changed with the introduction of the x64 Edition operating systems. Sysprep.exe is located in the deploy.cab file located in the Support\Tools directory on the x64 Edition CD-ROM. Sysprep.inf does not provide new entries for x64 Editions.
Both the 32-bit and 64-bit versions of sysprep.exe will run on x64 Edition operating systems; however, the 64-bit version of sysprep.exe is not backward compatible and will not run on x86 systems.
Note:
Using Remote Installation Server (RIS) for x64 Editions

The x64 Edition operating systems can be deployed by means of Remote Installation Server (RIS) only on servers running Windows Server 2003 SP1 or Windows x64 Editions. If an earlier operating system version is installed on the RIS server, Risetup will display the following error when attempting to add an image to the local RIS server:
File Missing A file that is needed to set up the installation image on the server was not found. This may indicate that the image source is corrupt or that the source is not a valid Windows installation source. Verify that the path you entered points to a valid Windows installation source.
This error occurs because prior to SP1, RIS did not understand the x64 image structure. RIS would find an i386 directory, but would be unable to locate the required files in this directory, and setup of the x64 image would subsequently fail. This is due to the fact that the root directory in x64 Editions is AMD64 rather than i386, although the i386 directory still exists in the x64 Editions as an installation point for 32-bit DLLs required for backward compatibility. Risetup has also been changed to correctly identify the 64-bit versions of the core RIPREP files riprep.exe, riprep.inf, and setupcl.exe and to populate the
69
FINAL
remoteinstall\admin\amd64 directory with the correct files. Because you can deploy x64 images from x86 or Itanium computers, x64 versions of the files may not be present on the computer prior to installing the RISETUP image. In such cases, the files are copied from the x64 CD to the RIS server to ensure compatibility. In addition, a file version checking mechanism has been implemented to ensure that the latest versions of the riprep files are present on the RIS server. If the versions being copied are newer versions, they will overwrite the files that reside in the AMD64 directory on the RIS server to ensure that the latest versions are available. Because all RIPREP files are backward compatible, this does not cause any compatibility issues. In the event that the riprep files are the same version or older, no action occurs.
Client Installation Wizard Changes

The Client Installation Wizard (CIW) has also changed with the addition of x64 as a RIScapable platform. The new x8664.osc file has been added to allow an administrator to deploy x64 images only with the proper registry settings. X8664.osc may be added to RIS servers by using either of the following methods: If the x64 image is the first image being copied to the RIS server, it is added to the remint\OsChooser\<Language> directory by default. If images exist on the RIS server, the .OSC file is added during the first x64 image acquisition, but administrators must choose to overwrite, or rename and overwrite, existing .OSC files to implement the changes. Custom .OSC file changes may not be saved during this process; always make sure that the customer has a backup for these files prior to overwriting them.
The following key specifies architectures that may be installed by users:

HKLM\System\CurrentControlSet\Services\BINLSVC\Parameters\ DefaultPlatformsforX8664
Because the x64 platform supports both x86 and x64 code natively, administrators can choose to install only x86 architecture, only x64 architecture, or both. The default option is to install both. The DefaultPlatformsforX8664 section includes the following values: i386: presents only the x86 images in the OSChoice.osc. amd64: presents only x64 images in OSChoice.osc. no value: is the default value and will display x86 and x64 images available as well as Install Default Windows. Choosing the last option will display the x86 images available in OSChoice.osc.
This behavior applies only to RIS servers that supply x64 images. If an RIS server houses only x86 images, the x8664.osc file is not copied and RIS functions remain unchanged. In addition, if an administrator chooses not to overwrite the .OSC files, then the x8664.osc file may not be properly copied and x64 images will not appear during the OSChooser
70
FINAL
portion of the installation. To enable this new functionality, recopy the image and choose to rename or overwrite the .OSC file.
Automated Deployment Services Support for x64 Editions

Current versions of Automated Deployment Services (ADS) cannot be used to deploy x64 Editions. Updated versions of ADS planned for release in the near future will support deployment of x64 Editions.
Windows Preinstallation Environment (WinPE) Changes for x64 Editions

New WinPE versions included with x64 Editions and Windows Server 2003 SP1 include the following changes: RAM disk support New versions of Microsoft Windows Preinstallation Environment (WinPE) may be loaded directly into random access memory (RAM) or a RAM disk, allowing OEMs and system builders to gain access to the CD-ROM drives of a system, which in turn would allow additional drivers to be loaded and applications to be installed to an image. WMI support OEMs and system builders can use extended WMI features in new WinPE versions to test and verify device driver and application compatibility before building an image. New factory.exe that supports multi-homed computers New versions of Factory.exe for all classes of computers allow WinPE to statically assign IP addresses on multi-homed computers. This change allows WinPE to be used as a deployment mechanism in data center environments when Dynamic Host Configuration Protocol (DHCP) is not available. Third party driver support As a result of extended WMI features, new versions of WinPE can also test third party drivers when such drivers are loaded by WinPE.
Booting WinPE from a RAM Disk

Normally, when you start a computer from a hard disk drive, CD-ROM, or RIS Pre-boot Execution Environment (PXE) server, Windows keeps operating system file handles open and dedicated to that instance of Windows. Therefore, you cannot remove the CD that you used to start the computer and insert another CD. You also cannot delete the hard disk partition from which you started the computer. Similarly, the RIS (PXE) server used to start the computer must keep those file handles open, and WinPE client computers cannot be detached from the network without causing WinPE to become unstable. The size of WinPE (about 160 MB) makes it possible to load the entire WinPE operating system image into RAM, and to start the computer from a RAM disk. The RAM disk boot
71
FINAL
feature provides a virtual CD file system in memory. This virtual CD is treated as read only. The Windows operating system Setup Loader now supports loading WinPE from a RAM disk. The RAM disk driver supports loading an ISO-9660 (CD) image as a RAM disk. Booting WinPE from a RAM disk enables you to perform the following tasks: Swap the CD used to start the computer and insert another CD to add drivers, utilities and applications, or a Windows operating system image. Start the computer from a RIS (PXE) server with the ability to disconnect from the network after WinPE has loaded. After the initial download of the WinPE image, there is no longer any dependency on network resources, such as file handles, which normally must remain loaded until the WinPE client computer restarts. Delete and repartition the hard disk from which WinPE has just started. Reduce total boot time.
WinPE assigns the letter X as the drive letter for any media used to boot the computer. This assignment cannot be modified.
Note:
Prerequisites for Starting WinPE from a RAM Disk

The following items are required for starting WinPE by using a RAM disk: An x86- or x64 based computer WinPE does not support booting from RAM Disk for x64 operating system installation. A customizable WinPE image The image must be created from a Windows Server 2003 SP1 product CD or appropriately configured installation source. A minimum of 256 MB of RAM The 256 MB of RAM minimum only supports use of a default un-customized version of the WinPE disk image.
To use a customized RAM disk image, the customized RAM disk image must be smaller than 512 MB and the physical memory installed in the computer must be at least 100 MB larger than the size of the customized RAM disk image. If the computer does not have enough physical memory to store the RAM disk image and start the operating system, WinPE will fail to boot.
Options for Booting WinPE from a RAM Disk

After you have created an ISO image of WinPE, you can use any of the following methods to start WinPE from a RAM disk: A bootable WinPE RAM disk CD-ROM. A hard disk that contains a bootable WinPE RAM disk image.
72
FINAL
A RIS server that contains a WinPE RAM disk image.
A PXE server other than RIS that contains a WinPE RAM disk image.
For more information about creating a bootable ISO image of WinPE, see Creating a Customizable Version of WinPE in the WinPE help file.
Creating a Bootable WinPE RAM Disk CD

To create a bootable WinPE RAM disk CD: 1. Create a customizable WinPE image, and then use the Oscdimg command to create an .ISO file from your customized image, as described in the Creating a Customizable Version of WinPE section of the WinPE help file. 2. Create a \working folder on your hard disk to store the contents of the WinPE RAM disk CD. For example, type:
md c:\work
3. Copy the .ISO file of your customized WinPE image into the \working folder. For example, type:
copy c:\winpex86.iso c:\work
4. In the \working folder, create the subfolder \<platform>. For example, type:
md c:\work\i386
5. Navigate to the <platform> folder of your WinPE image, and then copy Bootfix.bin, Ntdetect.com and Setupldr.bin (not Setupldr.exe) from this folder into the \working\<platform> folder on your hard disk. For example, type:
copy c:\winpe_tmp\i386\bootfix.bin c:\work\i386 copy c:\winpe_tmp\i386\ntdetect.com c:\work\i386 copy c:\winpe_tmp\i386\Setupldr.bin c:\work\i386
6. Create a text file named Winnt.sif in the working folder and add the text shown in the following example, replacing the variable <platform> with i386 or amd64 as appropriate for your installation.
[SetupData] BootDevice = "ramdisk(0)" BootPath = "\<platform>\System32\" OsLoadOptions = "/noguiboot /fastdetect /minint /rdexportascd /rdpath=<bootimage>" Architecture = "<platform>"
7. Navigate to the build_version folder on your hard disk that contains the WinPE build tools and run the Oscdimg command with the minimum options shown in the following example.
oscdimg -blocation -n working image_file
73
FINAL
For example, type:

oscdimg -bc:\build_x86\etfsboot.com -n c:\work c:\winpex86ram.iso
8. Use CD recording software to burn the newly created .ISO file to a blank CD.
Important: Copying the .ISO file to the CD-ROM will not work. To create a bootable CD-ROM you must use CD recording software that extracts and burns the .ISO image file directly to a CD-ROM.
9. Insert the CD into the computer on which you want to run WinPE and start the computer from the CD. 10. The computer will start WinPE by using the RAM disk image.
The <bootimage> variable represents the path to the WinPE boot image file. The path to this file may be specified as a relative path. For example, if the image file winpex86.iso is located in the root directory, <bootimage> may be specified as winpex86.iso. You can also place the image file in a subfolder such as <root>\tmp and specify <bootimage> as tmp\winpex86.iso, or place the image file in any ARC-accessible location and specify a full ARC path such as multi(0)disk(0)rdisk(0)partition(1)winpex86.iso.
Note:
The Architecture entry must be present for x64 computers. For i386 computers, you can omit this line or ensure that the value of the Architecture entry equals i386. The Location entry denotes the location of the Etfsboot.com file, which is located with the other build tools in the build_version folder.
Creating a Bootable WinPE RAM Disk on a Hard Disk

To create a bootable WinPE RAM disk on a hard disk: 1. Create a customizable WinPE image and then use the Oscdimg command to create an .ISO file from your customized image as described in the Creating a Customizable Version of WinPE section of the WinPE help file. 2. Create an active partition. For example, start the computer from a WinPE RAM disk CD and use the following DiskPart commands:
diskpart select disk 0 create partition primary select partition 1 active assign letter c: exit
3. Format the active partition. For example, type:
74
FINAL
format c: /fs:ntfs /q
4. Copy the .ISO file to the active partition. The .ISO file should be placed in the root directory of the boot partition. For example, type:
copy d:\winpex86.iso c:\
5. Copy \<platform>\Setupldr.bin (not Setupldr.exe) into the root directory of the boot partition and rename the file as ntldr. For example, type:
copy d:\i386\setupldr.bin c:\ntldr
6. Copy \<platform>\Ntdetect.com into the root directory of the boot partition. For example, type:
copy d:\i386\ntdetect.com c:\
7. Create a text file named Winnt.sif in the root directory of the boot partition. The Winnt.sif file must contain the same entries as described in the steps for creating a bootable WinPE RAM disk CD-ROM. For example, type:
copy d:\winnt.sif c:\
8. Shut down and restart the computer. The computer will start into WinPE from the RAM disk image on the hard disk drive.
If you use DiskPart to create a partition on a blank hard disk, use the Clean command before creating the partition to erase all partitions and data completely from the hard disk.
Note:
Creating a Bootable WinPE RAM Disk Image on a RIS Server

To create a bootable WinPE RAM disk image on a RIS server: 1. Navigate to the \RemoteInstall\Setup\<language>\Images folder on the RIS server and create a subfolder for WinPE. For example, type the following commands.
e:\ cd \RemoteInstall\Setup\English\Images md winpe
In this example, e: is the drive letter assigned to the hard drive on which RIS is installed and English is the language specified in the WinPE image. 2. Navigate to the \winpe folder and create the subfolder <platform>. For example, type:
md winpe\i386
75
FINAL
3. Copy the customized WinPE .ISO file that you created earlier into the \winpe\<platform> folder. For example, type:
copy c:\work\winpex86.iso e:\RemoteInstall\Setup\English\Images \winpe\i386
4. Navigate to the \winpe\<platform> folder and create the subfolder \templates. For example, type:
md winpe\i386\templates
5. Navigate to the \<platform> folder of your WinPE image, and then copy Ntdetect.com and Startrom.com to the \winpe\<platform>\templates folder. For example, type:
c:\ cd \winpe\i386 copy ntdetect.com e:\RemoteInstall\Setup\English\Images\winpe\i386\templates copy startrom.com e:\RemoteInstall\Setup\English\Images\winpe\i386\templates
6. Copy \<platform>\Setupldr.exe (not Setupldr.bin) from your WinPE image into the \winpe\<platform>\templates folder, and then rename Setupldr.exe to Ntldr. For example, type:
copy setupldr.exe e:\RemoteInstall\Setup\English\Images\ winpe\i386\templates\ntldr
7. Navigate to the \winpe\<platform>\templates folder and create a text file named Winnt.sif that contains the text shown in the following example.
[SetupData] BootDevice = "ramdisk(0)" BootPath = "\<platform>\System32\" OsLoadOptions = "/noguiboot /fastdetect /minint /rdexportascd /rdpath = %INSTALLPATH%\%MACHINETYPE%\<bootimage>" Architecture = "<platform>" [RemoteInstall] Repartition = No [OSChooser] Description = "<brief description>" Help = "<longer description>" LaunchFile = "%INSTALLPATH%\%MACHINETYPE%\templates\startrom.com" ImageType = Flat Version = "5.2 (0)"
76
FINAL
Winnt.sif Example Notes
Replace <platform> with i386 or amd64 as appropriate for your installation and <bootimage> with the filename for the .iso image. The OSLoadOptions command line in the previous example is a single command line that wraps to the next line in the display. The Repartition = No entry in Winnt.sif avoids displaying a warning in the Client Installation Wizard (OSChooser) that the disk will be erased. Text for the Description and Help entries may include any relevant information. The LaunchFile and ImageType entries must be entered exactly as shown in the example. You can assign any name to the Winnt.sif file as long as you specify the .sif extension.
8. Start the client computer from the RIS server, and then choose the image that you created. The computer will start into WinPE using the RAM disk. If client computers fail to start using RIS, open a command window on the RIS server and use the following commands to restart the RIS service:
net stop binlsvc net start binlsvc You can put the i386 and amd64 folders within the same \winpe folder on a RIS server. For example, you can create the following folder structure: \RemoteInstall\Setup\English\Images\winpe\i386 \RemoteInstall\Setup\English\Images\winpe\amd64
Note:
Creating a Bootable WinPE RAM Disk Image on a PXE Server

To create a bootable WinPE RAM disk image on a third-party PXE server: 1. Start the computer over the network from a Pre-Boot Execution Environment/Trivial File Transfer Protocol (PXE/TFTP) server that is not a Microsoft RIS server. The details depend on your specific PXE server. 2. Copy the customized WinPE .ISO file that you created earlier into the appropriate folder on the PXE server. 3. Navigate to the <platform> folder of your WinPE image, and then copy Ntdetect.com and Startrom.com into the appropriate folder on the PXE server. 4. Verify that the initial boot program is Startrom.com. 5. Copy Setupldr.exe (not Setupldr.bin) from your WinPE image into the same folder as Startrom.com and Ntdetect.com, and then rename Setupldr.exe to Ntldr. 6. Copy Winnt.sif from a WinPE RAM disk CD into the same folder as Startrom.com.
77
FINAL
7. Start the client computer from the PXE server, and then choose the image that you created. The computer will start into WinPE by using the RAM disk.
You may need to edit the value of \rdpath= in the Winnt.sif file to ensure that the path properly resolves to the .ISO file location.
Note:
Potential WinPE Errors

This section describes errors that may occur when using WinPE images to deploy Windows x64 Edition operating systems.
Incorrect Operating System Version

WinPE images built using the AMD64 bits will not allow you to boot the WinPE CD on an x86 system. If you attempt to do so, you will see the following error:
Attempting to load an x64 operating system, however this CPU is not compatible with x64 mode. Please install a 32-bit x86 operating system. Setup cannot continue. Press any key to exit
Because you can create an x64 WinPE image on x64 or x86 hardware, you may also see the following error message:
This version of Windows cannot be installed on this machine
This error message is displayed when you insert a Windows x64 Editions CD-ROM on an x86-based system and Autorun is enabled for the system. This message is provided for information only and can be safely ignored.
Incorrect Platform Designation

The AMD64 designation is required for x64 class systems. If the BootPath section of winnt.sif does not specify the appropriate <platform> designation, the following error may occur:
File \<platform>\System32\biosinfo.inf could not be loaded. The error code is 18. Setup cannot continue. Press any key to exit.
Incorrect BootImage Designation

The <bootimage> entry in winnt.sif defines the path to the WinPE boot image file. If the file is on the local root directory, the path will be winpex64.iso. When a <bootimage> value is not specified in the OSLoadOptions section of the winnt.sif file, the following error may occur:
Windows could not start due to an error while booting from a RAMDISK. Windows failed to open the RAMDISK image. File <bootimage> could not be loaded. The error code is 14. Setup cannot continue. Press any key to continue.
78
FINAL
Windows Management Instrumentation Support in WinPE

You can add support for Windows Management Instrumentation (WMI) to WinPE images by using the mkimg command with the /wmi option to create your WinPE image as follows:
Mkimg.cmd source_directory destination_directory [image_name] /WMI
You can use the mkimg command with the /wmi option to build a WinPE image that contains the WMI classes and providers installed by the Wbemoc.inf file. These classes and providers allow you to create automated diagnostic procedures for operating system deployment to new hardware. To use Windows Script Host (WSH) scripts with WMI scripting interfaces, add WSH support to your WinPE image by running the BuildOptionalComponents.vbs script with the /WSH option. For details, see the Adding Scripting Support to WinPE section in the WinPE help file. To verify the presence of WMI in the WinPE image: 1. Start the computer by using WinPE. 2. Open a command prompt and type wbemtest to load the Windows Management Instrumentation Tester tool. 3. Click Connect. 4. In the Connect window, click Connect. 5. In the Windows Management Instrumentation Tester window, click Enum Classes. 6. In the Superclass window, click Recursive and then click OK. 7. The enumeration query produces a list of the available Common Information Model (CIM) classes used by the WMI providers. For more information about WMI, search http://msdn.microsoft.com for WMI.
Using WMI Scripts: ListProviders.vbs

The VB script ListProviders.vbs lists all available WMI Win32 providers that are used to monitor and configure computer hardware and operating systems.
Important: Before you run this script, add support for WSH to your WinPE image. For details, see the Adding Scripting Support to Windows PE section in the WinPE help file.
To run the ListProviders.vbs script: 1. Copy the script to a file named ListProviders.vbs. 2. From a command prompt, navigate to the directory containing the script and type the following command:
cscript ListProviders.vbs > listproviders.txt
79
FINAL
3. Open listproviders.txt and identify the available WMI providers.

ListProviders.vbs Script WScript.Echo "*********************************************" WScript.Echo "cscript ListProviders.vbs" On Error Resume Next Set NamespaceSet = GetObject("WinMgmts://./root").InstancesOf ("__NAMESPACE") WScript.Echo "=============================================" WScript.Echo WScript.Echo NamespaceSet.count & "WMI Namespaces on the local computer" WScript.Echo WScript.Echo "=============================================" Dim ConnectionString Dim ProviderCount Dim ClassCount ProviderCount = 0 ClassCount = 0
4. For each Namespace in NamespaceSet, add the following entries:

ConnectionString = "WinMgmts://./root/" & Namespace.Name Set ProviderSet = GetObject(ConnectionString ).InstancesOf ("__Win32Provider") WScript.Echo ProviderSet.count & "providers in //./root/" & Namespace.Name & "namespace:" WScript.Echo
5. For each Provider in ProviderSet, add the following entries:

WScript.Echo "" & Provider.Name WScript.Echo "" & Provider.CLSID WScript.Echo ProviderCount = ProviderCount + 1
6. Add the following entries:

Set objWMIService = GetObject(ConnectionString) Set colClasses = objWMIService.SubclassesOf()
7. For each objClass in colClasses, add the following entries:

ClassCount = ClassCount + 1 WScript.Echo objClass.Path_.Path
8. Add the following entries:

WScript.Echo WScript.Echo Set ProviderSet = Nothing
80
FINAL
9. Complete the script by adding the following entries:
WScript.Echo computer" WScript.Echo
"Total" & ProviderCount & "providers on local "Total" & ClassCount & "classes on local computer"
WMI Support Limitations in WinPE

The WMI support in WinPE is a subset of the standard WMI installation. Only the WMI classes and providers installed by Wbemoc.inf are available. The WMI functionality in WinPE is limited to only the available WinPE resources. Some WMI operations may fail because the feature queried is not available in WinPE. For example, there is no event log service in WinPE, so the Win32_NTEventLogFile query returns 0 instances. When starting WinPE from read-only media such as a CD-ROM, all writes to the repository are cached in memory rather than to the hard disk drive. When the computer restarts, the changes to the repository are lost. When starting WinPE from read-only media, WBEM logs are not available. If there is a read-write device on the computer, you can modify the following registry key to point to the device:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM\Logging Directory
81
FINAL
Machine Check Architecture (MCA) Events

Almost all Machine Check Architecture (MCA) events are hardware errors, but not every hardware error is reported as an MCA event. For example, a failure in a memory device in system memory would probably be reported as an MCA event, but a component failure on a hard disc drive would probably not be reported to the operating system as an MCA event. The difference between these two events is the hardware mechanism that is used to alert the CPU about the event occurrence.
Types of MCA Events

All MCA events fall within two categories based on the hardware reporting mechanism used. The Intel System Abstraction Layer (SAL) 3.0 Specification defines these categories as CPU errors and platform errors. CPU errors either occur within components of the CPU itself, such as the caches, or that are detected on the CPU front side bus (FSB) during an external transaction. Platform errors are delivered to the CPU through external pins provided for reporting MCA events. Further details on these pins are provided in Section Four of the SAL 3.0 Specification.
For more information about System Abstraction Layer specifications, see: Note: http://www.intel.com/design/Itanium/downloads/245359.htm.
Any hardware error event that does not fall within these two categories is not delivered or processed as an MCA event. The model provides some degree of flexibility; system designers can connect hardware error event signals to the pins provided on the CPU to ensure that the errors are processed as MCA events. However, an MCA event must successfully identify the component that failed or the component that is likely to fail in the future. For peripherals on an I/O bus, such as peripheral connect interface (PCI), there is no standardized direct link from peripheral devices to the system chipset that could be used to raise an MCA event to identify the failing component. However, MCA provides full error handling for the standard peripheral component interconnect (PCI) fatal error types, such as PERR and SERR.
82
FINAL
Severity Categories
MCA events can be further categorized based on the severity of the error. Each error delivered to the operating system falls within one of the following categories: Non-corrected or fatal errors Errors that could lead to non-recoverable data loss or corruption. This type of error will cause the system to be restarted. Examples might be a parity error on the PCI bus or a double-bit Error Checking and Correction (ECC) error in system memory.
Non-corrected or fatal errors are referred to as machine check abort (MCA) events. This term causes confusion with Machine Check Architecture (MCA). In this course, MCA always refers to Machine Check Architecture.
Note:
Corrected errors Errors that can be corrected either by the hardware or by some level of software. The occurrence of a corrected error can indicate instability in the hardware and can be used to predict future fatal errors. The greater the number of sources of corrected errors within the system, the better the quality of error prediction of the system. Examples of this type of error might be a double-bit ECC error in a clean cache block or a single-bit ECC error in system memory.
There are two types of corrected errors: Corrected machine check (CMC) A corrected error that was detected by the CPU. Corrected platform error (CPE) A corrected error that was detected by the platform hardware.
Reporting Mechanisms
Fatal errors and corrected errors use different reporting mechanisms because: Fatal errors require the operating system to resolve a potentially catastrophic hardware problem immediately. Corrected errors do not require immediate operating system response because they pose no serious risk to the integrity of the system.
83
FINAL
Floppy-free Computer Considerations

As legacy-free computer hardware design grows in popularity, more and more systems are shipped without on-board floppy drives. This can present a problem if you are required to install a third-party driver for mass storage because you will not be able to specify the driver in any way. If the system and BIOS support universal serial bus (USB) floppy access during the boot process, you can use a USB floppy to work around this issue. The setup loader searches the A and B drives for a txtsetup.oem file to load mass storage drivers, so the system must also assign either A or B to the drive. If the system does not support the USB floppy at boot, a physical floppy drive will be required to install drivers for the mass storage device. As an alternative, the operating system may be deployed to the computer using SysPrep or RIS.
84
FINAL
Best Practices for Dual Boot Configurations

Dual-boot configurations that include a Windows x64 Edition operating system and an x86 operating system are fully supported by Microsoft. Dual boot systems enable customers to run 16-bit applications in the x86 operating system when needed and also provide support for applications that might not be supported by x64 because the applications 16-bit installer is not supported. Best practices for dual boot include: Always install the 32-bit operating system first This requirement ensures that the proper boot files are written to the root of the drive. The NTLDR version loaded with x64 systems will not allow an older version of NTLDR to overwrite it. If you install Windows x64 Editions first, NTLDR will not be overwritten with the installation of the 32-bit operating system, causing the 32bit version of Windows to not boot. Never install x64 into the same partition as a current 32-bit installation Because the Windows x64 Editions use the same Program Files, Documents and Settings, and other folders as current 32-bit Windows operating systems, these directories may be overwritten with 64-bit versions of .DLL and .EXE files required by the operating system. If this happens, 32-bit applications and services will fail.
You are encouraged to make a full backup of your data in the event that such a problem occurs. If a Windows x64 Edition operating system is inadvertently installed into the same directory as an existing 32-bit operating system, back up as much data as possible and then format and reinstall both operating systems. Attempting to install x64 into the same partition as an x86 operating system generates the following error during text mode:
You chose to install Windows on a partition that contains another operating system. Installing Windows on this partition might cause another operating system to function improperly. CAUTION: Installing multiple operating systems on a single partition is not recommended. To learn more about installing multiple operating systems on a single computer see http://www.microsoft.com/windows/multiboot.asp using Internet Explorer. To continue setup using this partition, press C To select a different partition, press Esc
Choosing to continue past this error message displays the following error:
CAUTION: A \Windows folder already exists that may contain a Windows installation. If you continue, the existing Windows installation will be overwritten.
85
FINAL
All files, subfolders, user accounts, applications, security and desktop settings for that Windows installation will be deleted. The My Documents folder may also be deleted. To use the folder and delete the existing Windows installation in it, press L To use a different folder, press ESC To quit Setup, press F3
Installing an x64 Edition operating system into the same partition as a 32-bit operating system can result in several severe issues, such as: Application incompatibility or instability. Inability to boot the 32-bit operating system. Program Files folder is overwritten with a mixture of 32-bit and 64-bit files. Data loss caused by the overwriting of the Documents and Settings directory.
Users who install an x64 Edition operating system into the same partition as a 32-bit operating system should back up any retrievable data and reinstall their environment in a supported fashion. The general recommendation to avoid installing multiple operating systems on the same partition is particularly applicable to a mix of x86 and x64 environments.
86
FINAL
Removing x64 Operating Systems from a Dual Boot Configuration

Steps required to remove the x64 operating system from a dual boot configuration are similar to those required to remove an x86 operating system from a dual boot configuration. To remove a Windows x64 Edition operating system from a dual boot configuration: 1. Remove the entry for Windows x64 from within the boot.ini file. You can remove the entry manually or use the Startup and Recovery dialog box as shown in Figure 21.
Figure 21: Startup and Recover Dialog Box
2. Click the Edit button to remove entries for the x64 operating system from the [Operating Systems] line. 3. Edit the [default] entry to point to the operating system that you want to make the primary bootable operating system.
87
FINAL
4. Reboot the system to ensure that the computer boots properly. If the computer boots properly, remove the directory where the Windows x64 Edition operating system was installed.
88
FINAL
Transferring Files and Settings

Customers may also require assistance to migrate from 32-bit to 64-bit operating environments because of the lack of an upgrade path to Windows x64 Editions. To retain files, Internet favorites, and other system settings, customers are encouraged to use the File and Settings Transfer Wizard. Enterprise customers can also use the User State Migration Tool (USMT) to transfer system settings. Applications must also be reinstalled on the Windows x64 Edition operating system. To successfully move settings from a 32-bit system to an x64 system: 1. Start the Files and Settings Transfer Wizard within the Windows x64 Editions operating system. As shown in Figure 22, the Wizard prompts you to create a Wizard Disk on the floppy drive for use in collecting files and settings from the 32-bit system.
Figure 22: Creating a Files and Settings Transfer Wizard Disk
Note:
During floppy disk creation, the Wizard copies the migration tool fastwiz.exe and the migwiz.cab file that contains files required for migration to the floppy disk.
2. After you have created the floppy disk, insert the disk into the 32-bit computer and run the migration tool A:\fastwiz.exe.
89
FINAL
3. The migration tool fastwiz.exe extracts the migration files from migwiz.cab and then displays the Files and Settings Transfer Wizard as shown in Figure 23.
Figure 23: Running the Files and Settings Transfer Wizard
4. Click Next to choose the proper computer type, which in this case would be Old Computer (the 32-bit computer). 5. Select a location to store the migrated files. You can store the files on a floppy disk if the files are small enough. Larger file collections can be saved to a network drive or transferred to the local hard disk and burned to a CD. 6. Select the files or settings you would like to migrate. You can also choose to move only specific files and settings by selecting Let me select a custom list of files and settings when I click next (for advanced users). 7. After the files and settings you want to transfer are selected, select Next to begin the transfer. Depending on the amount of data to be transferred and the method of transportation, this process may require considerable time to complete. 8. When the file transfer has completed, run the Files and Settings Transfer Wizard on the x64 computer and select New Computer.
90
FINAL
9. Choose the location where you saved the 32-bit files, and then choose to restore the files. You should see the file transfer begin as shown in Figure 24.
Figure 24: Transferring Files and Settings
10. After the restoration is complete, check for the existence of the files and settings to ensure that the process completed successfully. After the Files and Settings Transfer Wizard portion of data transfer is completed, customers must re-install applications to store application files in the appropriate directories and store registry information in the appropriate registry locations.
91
FINAL
Directory Structure and 32-bit Driver Changes

The following example represents output from a file compare (fc) command performed against 32-bit and 64-bit versions of Windows Server 2003, Enterprise Edition directory structures. This comparison shows many renamed directories as well as some additions and deletions. This example was generated following clean installation of both operating systems using all default options. Directories that were added or deleted are indicated in Bold. The listing does not provide special indication for directories that were appended.
On x64 systems:
***** x64dir.txt [WinntDirectories] 1 = "\"
Compared to x86 systems:

***** X86DIR.TXT [WinntDirectories] 1 = "\" *****
On x64 systems:
***** x64dir.txt 10 = system32\spool\drivers 11 = system32\spool\drivers\x64\3 12 = system32\spool\prtprocs 13 = system32\spool\prtprocs\x64 14 = system32\wins

***** X86DIR.TXT 10 = system32\spool\drivers 11 = system32\spool\drivers\w32x86\3 12 = system32\spool\prtprocs 13 = system32\spool\prtprocs\w32x86 14 = system32\wins *****
On x64 systems:
***** x64dir.txt 17 = system32\drivers\etc 18 = system32\spool\drivers\x64 19 = system32\drivers\disdn

***** X86DIR.TXT
92
FINAL
17 = system32\drivers\etc 18 = system32\spool\drivers\w32x86 19 = system32\drivers\disdn *****
On x64 systems:
***** x64dir.txt 23 = Config 24 = msagent64\intl 25 = Cursors

***** X86DIR.TXT 23 = Config 24 = msagent\intl 25 = Cursors *****
On x64 systems:
***** x64dir.txt 38 = "Connection Wizard" 39 = "Driver Cache\amd64" (addition) 80 = "Driver Cache\i386" 40 = security

***** X86DIR.TXT 38 = "Connection Wizard" 39 = "Driver Cache\i386" 40 = security *****
On x64 systems:
***** x64dir.txt 42 = system32\npp 44 = system32\dllcache

***** X86DIR.TXT 42 = system32\npp 43 = system32\ias (removed) 44 = system32\dllcache *****
On x64 systems:
***** x64dir.txt 51 = msapps\msinfo 52 = msagent64 53 = msagent\chars
93
FINAL

***** X86DIR.TXT 51 = msapps\msinfo 52 = msagent 53 = msagent\chars *****
On x64 systems:
***** x64dir.txt 59 = system32\mui\dispspec 60 = AppPatch\AppPatch64 (addition) 66 = AppPatch 61 = Debug

***** X86DIR.TXT 59 = system32\mui\dispspec 60 = AppPatch 61 = Debug *****
On x64 systems:
***** x64dir.txt 69 = Resources\Themes\Luna\Shell\NormalColor 75 = system32\oobe\images

***** X86DIR.TXT 69 = Resources\Themes\Luna\Shell\NormalColor 70 = system32\oobe\html\ispsgnup (removed) 71 = system32\oobe\html\mouse (removed) 72 = system32\oobe\html\oemcust (removed) 73 = system32\oobe\html\oemhw (removed) 74 = system32\oobe\html\oemreg (removed) 75 = system32\oobe\images *****
On x64 systems:
***** x64dir.txt 76 = system32\oobe\setup 78 = Resources\Themes\Luna\Shell\Metallic

***** X86DIR.TXT 76 = system32\oobe\setup 77 = system32\oobe\sample (removed) 78 = Resources\Themes\Luna\Shell\Metallic *****
94
FINAL
On x64 systems:
***** x64dir.txt 79 = Resources\Themes\Luna\Shell\Homestead 82 = SysWOW64 (addition) 83 = SysWOW64\InstallShield (addition) 84 = SysWOW64\wbem (addition) 85 = SysWOW64\export (addition) 86 = SysWOW64\wbem\AdStatus (addition) 87 = SysWOW64\ias (addition) 88 = msagent (addition) 89 = msagent\intl (addition) 90 = TAPI 93 = SysWOW64\Drivers (addition) 94 = SysWOW64\usmt (addition) 95 = Provisioning\Schemas (addition) 96 = srchasst\x86 (addition) 100 = system32\1025

***** X86DIR.TXT 79 = Resources\Themes\Luna\Shell\Homestead 90 = TAPI 100 = system32\1025 *****
On x64 systems:
***** 112 = 113 = 114 = 115 = 116 = 117 = 118 = 119 = 120 = 121 = 122 = 123 = x64dir.txt system32\inetsrv SysWOW64\1025 (addition) SysWOW64\1028 (addition) SysWOW64\1031 (addition) SysWOW64\1033 (addition) SysWOW64\1037 (addition) SysWOW64\1041 (addition) SysWOW64\1042 (addition) SysWOW64\1054 (addition) SysWOW64\2052 (addition) SysWOW64\3076 (addition) mui

***** X86DIR.TXT 112 = system32\inetsrv 123 = mui *****
On x64 systems:
***** 127 = 128 = 129 = x64dir.txt ime "ime (x86)" (addition) Resources\Themes
95
FINAL

***** X86DIR.TXT 127 = ime 129 = Resources\Themes *****
On x64 systems:
***** 130 = 131 = 132 = x64dir.txt ime "ime (x86)" (addition) ime\imejp

***** X86DIR.TXT 130 = ime 132 = ime\imejp *****
On x64 systems:
***** x64dir.txt

***** X86DIR.TXT 251 = Microsoft.NET\AuthMan (removed) *****
On x64 systems:
***** 255 = 256 = 257 = x64dir.txt system32\wbem\Logs (addition) syswow64\mui (addition) %MUI_PRIMARY_LANG_ID_DIR_SYSWOW64% (addition)

***** X86DIR.TXT *****
96
FINAL
32-bit Driver CAB File Changes

The following example lists driver files included in the driver32.cab file located in the AMD64 folder.
12/02/2004 12/02/2004 12/02/2004 12/02/2004 12/02/2004 12/02/2004 12/02/2004 12/02/2004 12/02/2004 12/02/2004 12/02/2004 12/02/2004 12/02/2004 12/02/2004 10:01 10:01 10:01 10:01 10:01 10:02 10:03 10:03 10:03 10:03 10:02 10:02 10:02 10:03 PM PM PM PM PM PM PM PM PM PM PM PM PM PM 18,432 130,048 61,952 90,624 43,008 57,856 116,736 302,080 88,576 48,640 202,240 135,680 51,200 29,184 wbdaplgin.ax wksproxy.ax wkstvtune.ax wkswdmcap.ax wksxbar.ax wmsdvbnp.ax wp2p.dll wp2pgraph.dll wp2pnetsh.dll wpnrpnsp.dll wpsisdecd.dll wpsisrndr.ax wvfwwdm32.dll wvidcap.ax
97
FINAL
Resources
The following resources provide additional information about tools and techniques discussed in this session: To learn more about creating a bootable ISO image of WinPE, see Creating a Customizable Version of WinPE in the WinPE help file. To learn more about Windows Management Instrumentation (WMI), search http://msdn.microsoft.com for WMI. To learn more about System Abstraction Layer (SAL) 3.0 specifications, see http://www.intel.com/design/Itanium/downloads/245359.htm.
98
FINAL
Summary
Topics discussed in this session include: Installation Considerations Hotfix Installation Driver Support Considerations INF Decoration Changes Within x64 Deployment Options on x64 Editions Using WMI with WinPE MCA Events Floppy-free Computer Considerations Dual Boot Considerations and Best Practices Removing x64 Operating Systems from a Dual Boot x86-x64 Environment Transferring Files from a 32-bit System to an x64 System Directory Structure Changes
99

NH Setup W01 M05 x64

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

NH Setup W01 M05 x64

Transféré par

Droits d'auteur :

Formats disponibles

Setup New Hire Week 1 Module 5

Examining Windows 64-Bit Architecture

Released: September 22, 2010

Conditions and Terms of Use

Copyright and Trademarks

2. Understanding the x64 Architecture ................................................................................................ 21

3. Examining Key Changes.................................................................................................................... 39

4. Installation and Configuration ......................................................................................................... 59

Setup New Hire Week 1 Module 5

Module 5. Examining Windows 64-Bit Architecture

Global Technical Readiness Microsoft Confidential - For Internal Use Only

Examining Windows 64-Bit Architecture 1. Introducing Microsoft Windows x64 Editions

1. Introducing Microsoft Windows x64 Editions

Before You Begin

What You Will Learn

2010 Microsoft Corporation. All rights reserved.

Setup New Hire Week 1 Module 5

Commonly Used Terms

Global Technical Readiness Microsoft Confidential - For Internal Use Only

Examining Windows 64-Bit Architecture 1. Introducing Microsoft Windows x64 Editions

Itanium Architecture Overview

2010 Microsoft Corporation. All rights reserved.

Setup New Hire Week 1 Module 5

Differences Between Itanium and x64 Edition Versions

Global Technical Readiness Microsoft Confidential - For Internal Use Only

Examining Windows 64-Bit Architecture 1. Introducing Microsoft Windows x64 Editions

Currently Supported Processors:

2010 Microsoft Corporation. All rights reserved.

Setup New Hire Week 1 Module 5

Features Included in x64 Editions

Using GPT Drives

Global Technical Readiness Microsoft Confidential - For Internal Use Only

Examining Windows 64-Bit Architecture 1. Introducing Microsoft Windows x64 Editions

Examining Drive Configurations

Figure 1. Using the Disk Management Console to Identify GPT Disks

2010 Microsoft Corporation. All rights reserved.

Setup New Hire Week 1 Module 5

Creating GPT Drives

Global Technical Readiness Microsoft Confidential - For Internal Use Only

Examining Windows 64-Bit Architecture 1. Introducing Microsoft Windows x64 Editions

DEMO: Creating and Identifying GPT Drives

Installation Considerations for GPT Drives

2010 Microsoft Corporation. All rights reserved.

Setup New Hire Week 1 Module 5

12002 MB (7045 MB free) 12002 MB (7045 MB free) 12002 MB (7045 MB free)

128 MB ( 0 MB free) 3000 MB (2982 MB free) 3000 MB (3000 MB free)

GPT disks only support the NTFS file system. Note:

Global Technical Readiness Microsoft Confidential - For Internal Use Only

Examining Windows 64-Bit Architecture 1. Introducing Microsoft Windows x64 Editions

Servicing Considerations for x64 Editions

2010 Microsoft Corporation. All rights reserved.

Setup New Hire Week 1 Module 5

Global Technical Readiness Microsoft Confidential - For Internal Use Only

Examining Windows 64-Bit Architecture 1. Introducing Microsoft Windows x64 Editions

2010 Microsoft Corporation. All rights reserved.

Setup New Hire Week 1 Module 5

2. Understanding the x64 Architecture

Before You Begin

What You Will Learn

Global Technical Readiness Microsoft Confidential - For Internal Use Only

Examining Windows 64-Bit Architecture 2. Understanding the x64 Architecture

Processor Architecture and Memory Management