Professional Documents
Culture Documents
FINAL
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
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
FINAL
FINAL
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
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
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:
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
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.
13
FINAL
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.
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.
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]
17
FINAL
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
21
FINAL
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
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
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
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
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.
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 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
32
FINAL
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
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.
Global Technical Readiness Microsoft Confidential - For Internal Use Only
33
FINAL
34
FINAL
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.
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
39
FINAL
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.
40
FINAL
The following directories are currently exempted from redirection: %windir%\system32\spool %windir%\system32\catroot %windir%\system32\catroot2 %windir%\system32\drivers\etc
Note:
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
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.
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:
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.
Note:
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
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
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
64 GB / 128 GB
1 - 32
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
Global Technical Readiness Microsoft Confidential - For Internal Use Only
47
FINAL
32-bit 64-bit
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
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.
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.
Operating System
Undecorated
FINAL
Operating System Undecorated Decorated for x86 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.
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.
Global Technical Readiness Microsoft Confidential - For Internal Use Only
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
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.
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.
54
FINAL
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
59
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.
FINAL
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
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
Note:
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
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
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.
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.
Note:
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
Global Technical Readiness Microsoft Confidential - For Internal Use Only
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.
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.
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:
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.
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.
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
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.
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:
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:
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:
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.
78
FINAL
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.
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
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"
81
FINAL
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
84
FINAL
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
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
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
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
On x64 systems:
***** x64dir.txt 17 = system32\drivers\etc 18 = system32\spool\drivers\x64 19 = system32\drivers\disdn
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
On x64 systems:
***** x64dir.txt 38 = "Connection Wizard" 39 = "Driver Cache\amd64" (addition) 80 = "Driver Cache\i386" 40 = security
On x64 systems:
***** x64dir.txt 42 = system32\npp 44 = system32\dllcache
On x64 systems:
***** x64dir.txt 51 = msapps\msinfo 52 = msagent64 53 = msagent\chars
Global Technical Readiness Microsoft Confidential - For Internal Use Only
93
FINAL
On x64 systems:
***** x64dir.txt 59 = system32\mui\dispspec 60 = AppPatch\AppPatch64 (addition) 66 = AppPatch 61 = Debug
On x64 systems:
***** x64dir.txt 69 = Resources\Themes\Luna\Shell\NormalColor 75 = system32\oobe\images
On x64 systems:
***** x64dir.txt 76 = system32\oobe\setup 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
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
On x64 systems:
***** 127 = 128 = 129 = x64dir.txt ime "ime (x86)" (addition) Resources\Themes
95
FINAL
On x64 systems:
***** 130 = 131 = 132 = x64dir.txt ime "ime (x86)" (addition) ime\imejp
On x64 systems:
***** x64dir.txt
On x64 systems:
***** 255 = 256 = 257 = x64dir.txt system32\wbem\Logs (addition) syswow64\mui (addition) %MUI_PRIMARY_LANG_ID_DIR_SYSWOW64% (addition)
96
FINAL
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