Overview of Windows Hardware Certification
Windows Certification Program
Hardware Certification Policies and Processes
January 7, 2014
Abstract
This paper provides information about the Windows Hardware Certification Program.
It contains high-level guidelines on certification testing and product submission policies, and useful business process requirements. This document has been updated to reflect new processes and policies for the launch of Windows 8.1
Document History
Date
January 7, 2014
Change
Submission fees removed. Updated Touch Device
Resubmission instructions. Addition of Graphic Adapter Test
Optimization Procedure.
November 22, 2013 Added links to certification newsletter and certification blog.
July 3, 2013 Updated for Windows 8.1, Server 2012 R2, and the revised
HCK for Windows 8.1. Added contingency policy and simplified Windows 8 testing. New fees for submissions are documented.
November 13, 2012 Added Windows RT connected devices, specialized PC, updated details for multifunction device testing and docking stations.
October 26, 2012 Updated testing fees for Windows 8 and Windows
Server 2012.
May 10, 2012
February 28, 2012
Added information on the policy for using previously certified motherboards in client systems.
Added information on Signature-only policies, UEFI requirements, and server testing requirements.
Additional edits for style and clarity.
First publication
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 2
Disclaimer: This document is provided "as-is". Information and views expressed in this document, including
URL and other Internet website references, may change without notice. Some information relates to prereleased product, which may be substantially modified being commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here. You bear the risk of using it.
This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.
© 2014 Microsoft. All rights reserved.
DirectX, Microsoft, MSDN, Windows, Windows Server, and Windows Vista are trademarks of the Microsoft group of companies. All other trademarks are property of their respective owners.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 3
Contents
How do I know what requirements my product needs to meet? ............................. 8
What if my product type is not automatically discovered? ....................................... 8
Determining when to consider a group of devices as a separate family ............ 21
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 4
Windows RT connected device certification and testing......................................... 28
Testing exception for network media devices and routers ................................. 29
Touch Device Resubmission and Multi-source Subcomponents ............................. 31
Systems and the use of Signature-only components .............................................. 34
Using previously certified motherboards in client systems ..................................... 35
System family testing and updates that require a new submission ........................ 37
Using Distributed Testing for System Family Testing .......................................... 38
Up-level and down-level certification policies for Windows Server 2012 and
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 5
Introduction
Welcome to the Windows Certification Program for Windows 8.1. This document updates earlier versions to reflect the changes in the program brought about by
Windows 8.1, Windows Server 2012 R2 and the Windows Hardware Certification Kit for Windows 8.1.
This document contains the business policies to prepare products for Windows 8.1 and Windows Server 2012 R2 for use with x86/x64-based systems and successfully certify those products. The policies for certifying devices for Windows RT are included. The policies and processes for testing and submitting Windows RT systems are covered in a separate document.
For clarification, contact sysdev@microsoft.com
with any questions.
Overview of Windows Hardware Certification
The Windows Certification Program is the primary channel that we use to communicate to the partner community the core expectations that Windows places on devices, kernel-affecting software, and systems so that those products can successfully and seamlessly integrate into Windows. This communication starts with the core tenets and user scenarios that drove Windows design. Those design principles translate into a set of features that cover fundamentals, connectivity, and device-specific features. These design features are codified as discrete requirements which define what Windows expects from the various components and connected devices. A device designed to meet the requirements will be reliable, stable, efficient in power and performance, and provide a great Windows experience.
The program is unique in the industry in terms of the detail and engineering tools that can freely provide to build, test, secure, and maintain products for success in the
Windows environment. No other program provides access to in the field telemetry to facilitate end-user support and quality assurance, nor as powerful a method to deliver software, driver and certain firmware updates to end-users to correct identified problems or allow new features to be embraced.
Partners can self-assess how their products comply with certification requirements by using the tests in the Windows Hardware Certification Kit (HCK). The current version of the Windows HCK is named the Windows HCK for Windows 8.1. The Windows HCK for Windows 8.1 supports testing all actively certified versions of Windows and contains significant enhancements to encourage efficient testing practices, such as early and focused testing, distributed testing and merged multifunction device fundamental testing. Not all requirements are testable in an automated fashion, and automated testing can't fully assure absolute compliance with the requirements, so we continue to analyze the end-user experience and improve the tools over time.
Certification is a public statement of confidence from us that the tested device, filter driver, or system works well with Windows. Certification benefits include:
Signing the device drivers.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 6
Publishing the product as certified in various catalogs and the compatibility center.
Collecting and pre-analyzing telemetry on your product in the field to improve your quality assurance efforts.
Providing a free and extremely effective distribution channel for driver updates.
Providing eligibility for various marketing incentives and a logo license.
The following processes and policies describe how the program moves from a collection of requirements and tests to certification of a product. These policies can have an impact on a product's eligibility for certification and the efficiency of your efforts. Use them in planning for testing cycles and resources.
The Windows Certification Program continuously re-evaluates the requirements and the test environment, with major revisions timed to Windows releases. This policy and process guide reflects the latest requirements and testing philosophy. We reserve the right to revise these policies as needed to improve the program. Revisions in the policies described here will be announced in the certification newsletter or in the certification blog , and changes will be listed in the Document History section of this document.
The Policy FAQ on MSDN may address questions regarding these policies. For any additional questions that are not covered in the FAQ, contact sysdev@microsoft.com
.
Questions on policy are also taken in the forum located at http://social.msdn.microsoft.com/Forums/en-US/whck .
General certification concepts, policies, and processes
How requirements are defined and tested
Some key terms describe how we test the Windows scenarios that certification is validating.
A feature is a Windows capability that is exposed or enhanced by a device or a kernelmode driver. Features fit into these classifications:
Fundamental features that are common to any device or driver in the environment.
Connectivity features that are necessary for a particular bus and protocol to work successfully.
Critical features that are necessary for a particular product to interoperate with Windows.
Optional features that enhance the experience that the device provides.
Features use a descriptive CamelCase name, like Device.Graphics.WDDM13,
System.Client.BluetoothController.Base, or Filter.Driver.Network.LWF.
A requirement is the written document that specifies what a device must do to qualify for Windows hardware certification. See Windows 8 Hardware Certification
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 7
Requirements in the Windows Dev Center. Within the namespace, requirements are descendants of features. For example, Device.Imaging.Scanner.Base.RawFileFormat is a requirement for the feature Device.Imaging.Scanner.Base.
The Windows Certification Program uses the Windows HCK to assess compliance with the requirements. The Windows HCK uses a unique method to determine which tests are necessary to run. The Windows HCK identifies the features of the product that is being tested and generates a set of tests for the test harness to schedule. For specific guidance on how to use the Windows HCK, see Windows Hardware Certification Stepby-Step Guide . This document includes policies for testing practices. The current version of the Windows HCK is HCK for Windows 8.1.
A product type is a collection of features that are associated with a particular device, filter, or system in common use with Windows. Product types are important for identifying a category of product for catalogs, compatibility lists, and the dev nodes and inner workings of Windows. Most partners who are engaged in the certification program are actively seeking to certify a particular product that matches a product type.
Turning a positive test result into certification
Anyone can download and use the requirements and the Windows HCK. We encourage you to design your product to meet the certification requirements and then test compliance with the requirements throughout the product cycle. However, to fully participate in the certification program and have the product certified, you must register with the Windows Certification Program through the membership process that is described at the Hardware and Desktop dashboard in the Windows
Dev Center.
After you register with the program and the product has completed testing, create a submission package and submit it for certification at Hardware and Desktop dashboard .
Product Types
The process for hardware certification has changed. In the earlier kit, Windows Logo
Kit 1.6, you selected a category to test and assumed that that category contained the right set of tests that exercised all of the device features that interoperate with
Windows. The Windows HCK implements feature-based testing. The test harness detects all of the features of the device that interoperate with Windows and schedules testing for all implemented features. The certification process evaluates all of the exposed features of the device, rather than only a subset of features.
This new approach has a definite advantage when the device being tested does not fit neatly into a defined category or exposes multiple functions. For example, a device may connect in many different ways. Each method represents a testable feature.
These connectivity features don't contribute to the definition of product types, but are expected to be tested as an exposed feature.
Tests are grouped into product types rather than categories, which provide certified product with a label that is appropriate for cataloging.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 8
When a device is tested, the kit identifies any product types that the device is eligible to claim in the catalog. If more than one product type matches the features that a device exposes, you may choose what product type best describes the device.
Testing optional features and functionality
Definitions of product types contain only the minimum feature set that is necessary to describe those product types. Windows is designed to support beyond the basics in many scenarios, and many defined features are optional. The Windows HCK tests any known features that your product exposes to Windows. For a product to be certified, it must pass all the Windows HCK tests. The tests validate the required and optional features of the product.
How do I know what requirements my product needs to meet?
All Products will expose a suite of features that can be categorized into 5 basic groupings. These features map to requirements and tests. The five groups are:
1.
Basic features expected of any device, filter or system (the fundamental features)
2.
The connectivity features exposed for the type of connectivity the device uses.
3.
The features that define the basics of a Product Type
4.
The optional features that are associated with a feature area. If your device or system exposes an optional feature the device must successfully comply with all of the associated requirements.
5.
Additional features that are related to secondary functions added to the product. For example, removable storage is commonly found on mobile broadband USB-connected units.
For your convenience, a product type matrix is located at http://download.microsoft.com/download/2/3/6/23662F33-71E8-43C1-8547-
5DE49B0374AB/windows-hck-product-type-matrix.zip
. This file can help identify all of the features, requirements and tests your submission will need to comply with for certification.
What if my product type is not automatically discovered?
Occasionally the gatherer will not detect all of the features your device supports and therefore the product type options exposed in the kit for certification does not include the certification product type you are after. In this case, from the selection tab in the HCK, right click to see the list of all features and manually add the missing features. This process will improve over time as the detection becomes more sophisticated.
“Other” products and conditional certification
Some devices introduce features for which Windows has no specific design scenario.
In previous programs, a product that does not map to a product type was called
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 9
Unclassified and was tested with a limited set of tests which assured the driver installed correctly but little else. As a platform, we embrace innovation, but we retain the reliability and performance of Windows by testing whatever features these innovative devices expose to the operating system. These unclassified devices that do not match a Product Type are now designated “Device-Other” or in some cases a more specific classification like “Storage Device-Other” to reflect certain additional features in key areas were exposed. The Other classification allows for signing of the drivers and distribution on Windows Update, but the device does not receive the complete benefits of a certified product.
If your device does not match any product type definition no product types will appear in the Windows HCK. On submission, however, the option “Device –Other” will be visible.
The limitations of “Other” products are:
They aren't certified for Windows because they don't match recognized product types that are designed for Windows scenarios.
They aren't mentioned in certified product listings or catalogs.
They can't use the Windows logo artwork.
To avoid confusion with certified products, “Other” products can't use the same product names as certified products.
A certified system can't replace expected functionality normally provided by a component of a defined product type with an “Other” product.
Despite these limitations, “Other” devices do receive important benefits:
The product's driver receives a Microsoft digital signature and is distributable on Windows Update.
The product can take advantage of metadata services.
Microsoft telemetry services identify a “Other” product in data sets, and that data becomes available to the submitter.
General certification testing policies
General testing guidance
All testing for certification uses the Windows HCK. The harness and tests receive updates at major releases of operating systems and service packs. Generally certification begins at the Release Preview of the forthcoming new Windows and use the Windows HCK released at that time will be used. Typically when the RTM version of the operating system is released the Windows HCK will also be updated. Each time the harness is updated, a transition window of 90 days or more is provided for the orderly migration of testing from the previous kit.
Each device submission must include test logs and the corresponding device drivers.
Devices that use in-box drivers (drivers that are included with Windows) must be tested for certification, but no in-box drivers are included in the submission package.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 10
Each system submissions must include test logs. The certification specifically applies to the hardware firmware and/or BIOS that was tested. To maintain the certification, the product must retest if the hardware, firmware, or BIOS changes, with certain minor text-only exceptions.
Testing all features and functionality
Any product that is tested and submitted for certification must:
Meet all applicable requirements for device fundamentals, including any
Windows Driver Foundation (WDF) requirements.
Meet all device connectivity requirements for the connectivity type or types that the device uses. Devices that use more than one type of connectivity bus must test successfully for all the applicable connectivity buses.
Pass any tests that apply to any features that are attributed to the device while under test. The Windows HCK detects any feature that Windows is designed to handle in a special manner. This testing assures that the device behaves as Windows expects from any device that exhibits these features.
This helps assure reliability, stability, and compatibility.
This includes products whose exposed features don't match the definition of any product type. For a feature that is detected on a product, the feature must pass testing, if the product will be submitted.
Seeking Windows HCK support
To obtain help with the Windows HCK, open a support case with CSS. They will provide technical support.
Customers who have a Premier support contract can use their Partner Technical
Manager (PTM) to open support incidents for high-priority handling.
For customers who don't have a Premier support contract, professional support options, including telephone numbers and pricing information, are available at
Microsoft Support .
For more information, see Windows Hardware Certification on MSDN.
Correcting false test failures with errata
Occasionally, test bugs cause failures that are encountered during certification, rather than product failures. The Windows HCK can filter out false failures by using errata filters. These filters find false failures in the test logs and scrub them to a passing state. The errata filters receive regular maintenance. Download errata filters regularly to your test environment to detect any current issues with the Windows HCK. The details on how to download and apply filters is found at http://msdn.microsoft.com/en-US/windows/hardware/hh852367.If a potential false failure is detected and isn't filtered by the current errata, open a service request with
Microsoft Customer Service and Support (CSS). If the root cause of the issue is a test error, an errata filter allows bypassing the problem until a later update of the
Windows HCK.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 11
Errata can't filter some test failures and may appear as a failure on automated review. Where possible, an informational filter known as an auto-triage filter identifies these issues. Informational filters don't reverse detected failures but instruct the tester to correct the test environment, or to contact CSS for further help to determine whether the failure is legitimate or an ambiguous test result. If you encounter such an issue, confirm the status with CSS and submit even though the logs still contain an apparent error. Such failures are manually reversed. For details about how to properly document the failure for a manual review, contact CSS or sysdev@microsoft.com
.
Contingencies
In certain cases, a product cannot meet the published requirements or pass certain certification tests. Mitigating circumstances may surround the product’s failure where the partner may appeal to Microsoft to review the Product’s failure with the objective that the product may still receive certification. In the case of devices with drivers perhaps the device remains uncertified but we would allow signing of the driver. These exception requests are called Contingencies and their outcome is determined by a review board. Contingency requests are considered in the context of the customer promise provided by certification and the failure’s impact on the end-user experience.
A contingency request is made using a standardized form which documents the specific failures, customer impact, business impact, and proposed mitigations. If approved by Microsoft, an online legal agreement documents the terms and conditions surrounding the approval of the contingency as agreed to by Microsoft and the partner.
Contingencies are rare compared to overall submissions, but an important process for providing flexibility to the interpretation of the requirements. Incoming contingency requests are reviewed first by the certification team and feature owners to understand the merits of the request and assign a severity rating to the request (or rejected outright). For failures that are assessed to have minimal end user impact, a decision may be concluded quickly. However, if the request represents a significant departure from the requirements the discussion is broadened to many groups and the discussion takes considerably longer for a decision to be reached. A complex contingency review could take 4 to 6 weeks with considerable communication for additional details, out of band testing and research. Approval should not be assumed even when similar contingencies have been granted to your company in the past since the readiness of the eco system and end user expectations evolve over time.
Where possible the request should include the actual test logs to document the issue.
This greatly facilitates review and internal discussion and the ability to actually create a filter to remove the failure on submission, should the request be approved.
However, it is a good practice to inquire about a decision early if the design is known to conflict with the requirements even if the device cannot yet be tested, so you do not invest time and effort into designs or build products that prove to be unacceptable by the standards.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 12
The contingency program has considerable flexibility in disposing of a case. Virtually all will require a timeline to bring the product into compliance. In more significant cases, contingencies may require additional steps such as consumer disclosure of the product’s limitations, audit of shipping product, heightened telemetry review of the product’s performance, a defined SLA for response to detected issues, or other mitigation measures.
Approved Contingencies are not covered under Non-Disclosure Agreement (NDA) as a practical matter since the filters used for passing a contingent submission are the same as the filters used for errata and are downloadable by all partners. Microsoft reserves the right to publish information regarding the affected hardware products. If the device would be used as a component in a system, Microsoft expects the contingency will be disclosed to OEMs.
To request a contingency send email to the sysdev@microsoft.com
alias or other contacts you are provided to request the appropriate forms and instructions. Failure to follow those instructions fully and completely will delay in the evaluation of the request as the triage team will be coming back to you to gather the information before further processing.
Merging test results into a single submission or project
The Windows HCK for Windows 8.1 brings some important new efficiencies which allow testing in a project to be distributed over a group of identical systems.
However there are some situations where testing will need to occur in different projects. Some partners may want to split testing across projects, controllers, or even physically separated labs. The Windows HCK allows for merging test results from separate projects under certain conditions.
A typical situation is one lab that focuses on testing earlier versions of Windows while another tests Windows 8.1, yet the partner wants to make a single submission for all of the operating systems and architectures. The Windows HCK environment allows for completed projects that tested different platforms and operating systems for the same system, filter, or device to be merged into a single submission package.
To combine the projects for a submission, create a submission package under the
“Package” tab and select the “merge package” option. You will be allowed to include a previously completed Project file (.hckx) as part of this package. Note that whatever is added cannot be changed. For instance the tests cannot be rerun or any missing tests completed.
In addition to combining completed .hckx files per operating system and the architecture, it's possible to test portions of a single-product submission across different projects (even from different controllers) and merge the test results into a single submission package. Such "deep merged projects" allow testing of components that require expensive setups to run in a special lab. They also allow teams that are responsible for different subcomponents of a single product to be responsible for their testing of their feature.
The rules for deep-merged project testing are:
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 13
The products under test must be identifiable as the same product—same PnP
IDs, container IDs, driver binaries, and firmware.
The deep-merged features must be for the same operating system and architecture.
The entire set of features identified under a dev node must be run together in the same project. Features associated with the same dev node can't be tested in different projects and then merged.
All tests for any feature must be run in the same project on the same controller.
Because system testing doesn't target a specific dev node, it's not possible to break a system submission across multiple projects and deep merge the results.
Submission requirements
Legal agreements
Participation in the Windows Certification Program requires a company to have signed an effective Logo License Agreement and Windows Certification Program
Testing Agreement. All certification submission activity requires these agreements on file. All legal agreements that are related to the Windows Certification Program are signed at the Hardware and Desktop dashboard in the Windows Dev Center.
Essential agreements
Windows Certification Program Testing Agreement. This agreement includes language that is related to testing procedures, testing policies, intellectual property rights, support requirements, audit policies, payment policies, indemnification, warranty, liabilities, confidentiality, term and termination, metadata, and digital rights management (DRM) clauses. Signing this agreement is required for participation in the program.
Windows Logo License Agreement. This agreement includes specifications for logo artwork usage, license grants and restrictions, indemnification clauses, disclaimer of warranty, and limitation of liability statements. This agreement is required to submit any product for Windows Certification or driver signing.
New versions of the Windows Certification Program Testing Agreement and Windows
Logo License Agreement will be posted for signature before Windows 8 submissions begin.
Optional agreements
These agreements control access to additional services that are available to participants in the certification programs or if the company is submitting in areas that have additional legal restrictions placed on them.
Windows Error Reporting Agreement. This agreement provides access to the telemetry data that is available on the Hardware and Desktop dashboard in the
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 14
Windows Dev Center. The agreement defines the restrictions on acceptable use of the data.
Test Sign Driver Agreement. This agreement allows a company to sign drivers that are under development by using a special Microsoft certificate. The agreement defines the restrictions on acceptable use.
Digital Rights Management Agreement. With this agreement, Microsoft can sign with the Protected Environment (PE) attribute drivers that are involved in the transfer and display of digitally protected media.
To accept the legal agreements, establish a Windows Certification account and designate a representative from the company to accept legal agreements on the company's behalf. Users who have the "Sign Master Legal Agreements" permission role can sign legal agreements for an organization.
If you have any questions about the legal agreements, contact sysdev@microsoft.com
.
Symbol files
We strongly recommend that partners submit the symbol files for their drivers, including those that don't match a defined product type. The symbol files help in the crash analysis and improve telemetry and feedback. Symbols are particularly helpful for Signature-only drivers, where we are unclear what the function of the device may be. The absence of symbol files can result in incomplete or wrong analysis, causing the wrong driver to be accused for a crash. It's acceptable to submit public symbols that don't detail the driver's functioning but still allow bucketing of crash failures bucketing and meaningful telemetry for partner analysis. The more detailed the provided symbols are, the better the analysis can be and the more accurate information the telemetry services may provide to you.
Listing products
A benefit of certifying products is that they're searchable in a variety of listing catalogs. This is useful for consumers and for enterprise verification of certification status. All certification-qualified submissions that match a defined product type are provided to the catalogs on the announcement date that the submitting company has entered.
If the submitter provides no announcement date, the product appears in the catalog two weeks after submission. Providing a date far into the future is an effective way to avoid a catalog listing but still keep the products on the certified list used for legal reference.
After the product is in the market and the partner-selected announcement date has passed, a listed product remains listed. Products that don't qualify for product types as defined by the Windows Certification Program are not eligible to receive a product listing.
Certification-qualified products are currently listed in the following catalogs:
• Windows Compatibility Center
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 15
• Windows Server Catalog
• Hardware Compatibility List
Product naming
Product naming is extremely important for tracking what products are certified.
Naming is key for consumer education, use of the certification logos on products and in advertising, and legal tracking.
Naming restrictions
The primary product name of a device or system that is given at submission must uniquely identify one specific device or system. If your company produces several distinctly different products under a marketing name, use the most distinct product name for the purposes of identifying a submitted product. After a submission has passed testing, you can use a product management tool to add marketing names. Any marketing names become published to the catalogs. They may be subject to audit by us. Marketing names appear in responses to inquiries of appropriate use of certification, such as from customs agencies and bib verification since certification is frequently a basic bid criteria with enterprise purchasers. For these reasons among others, we require that the product names that are listed in our product catalogs be detailed and accurate.
Product name details
A company may submit products only for itself and may not submit products on behalf of a third party.
For example, an independent testing lab that was contracted to test products for an original equipment manufacturer (OEM) may not submit such products on behalf of the OEM. The product submission package is submitted using an account under the OEM's administration, and the OEM must accept any or all agreements that apply to that product.
A single product name is assigned during the initiation of the submission.
After submission approval, additional marketing names may be added through the Product Listing Wizard, if all names meet the allowable change requirements that are posted for the product type.
The product name of a device or system must uniquely identify one specific device or system and must not be a generic name.
For example, "Laser Printer" can't be used as the product name of a laser printer.
However, "Laser printer model 5003", "Laserprint 2893", and "QuickLine 2" are acceptable names.
If a series name is included in the product name, the product name must also include a model name or number to uniquely identify that individual device or system. This requirement prevents confusion with other products in the
Windows catalogs.
For example, "Laserprint series" can't be used as the product name of a laser printer. However, "Laserprint series model 5003" and "Laserprint 2893" are acceptable names.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 16
The product name can include only the marketed product name, model number, and/or version number.
For example, a keyboard that is submitted with the product name "Quick-key" is acceptable. However, a submission that includes multiple product names such as
"Quick-key/Quick-key mobile, Quick-key 5000" isn't allowed. The additional names must be entered through the Product Listing Wizard after the submission for the product name has been approved.
The product name can't include any marketing slogans or tag lines.
The product name can't include any Microsoft trademarks.
Post-certification requirements
Certification and support obligation lifetime
With certification comes a commitment to the end user of product support for the reasonable lifetime of the product. The Windows Certification Program provides services to make this commitment possible through access to field telemetry and the ability to certify driver fixes and deliver them to end users. This policy clarifies the expected lifetime and support levels for certified products.
The Windows Certification Program aligns with the Windows release and support schedules. Our commitment to supporting products ties to the milestones for end of sales, end of mainstream support, and end of extended support of the operating system. This information is available on the Windows lifecycle fact sheet .
This overall product schedule defines three phases for the certification program.
Phase
Release to
Manufacturing to end of retail sales of operating system
To end of
Mainstream Support
Program supports
Systems and devices that are certifiable for the operating system
Time frame
System certification retires when the operating system is no longer sold preinstalled.
To end of Extended
Support
Devices that are certifiable for the operating system
Devices that are signable, distributable
Device certification retires at least
5 years from general availability, or 2 years into the life of the next operating system.
At least 5 years from general availability, or 2 years into the life of the second successor version.
System certification ends after the operating system is no longer available for OEM pre-installation, but device certification continues into the expected usable lifetime of that operating system.
An important part of the Windows experience is the assurance that an investment in a product has a meaningful lifetime. End users expect that their purchases will continue to work if they upgrade to a new operating system. Each release of the operating system works with devices that are designed to the standards of the previous release of the operating system, at least in a deprecated fashion. Products that are submitted to the Windows Certification Program are expected to support the
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 17 next operating system. The device may not meet increased standards and functionality of the new operating system, but at a minimum, the device must work in the new operating system with functionality that is equivalent to the functionality that was demonstrated in the previous operating system.
You may test previously certified drivers in the new operating system and make those drivers available on Windows Update. In some cases, we may ask partners to update drivers that were previously certified for a previous operating system.
Extended support is typically a commitment that companies make to enterprise buyers. We don't commit to continuing a full testing program to cover devices under extended support, but it does provide a signing process and a fundamental program so that the best possible drivers remain distributed on Windows Update.
Audits
We periodically audit certified systems and devices to ensure that the requirements and tests are having the intended impact on quality of the Windows experience and to plan for future improvements in requirements and testing. These audits are not intended to be punitive. The nature and focus of the audits vary over time as we explore areas of the certification program that can be improved.
Audit selection and product procurement
Any device (any hardware ID) that is included in a device or system submission, reseller submission, or marketing name submission can be selected for an audit. In some circumstances, we purchase an audited product at retail. For other audits, we may ask the partner to provide the product, at the partner's expense, including all shipping charges.
We reserve the right to specify the exact product name or hardware ID of the product that is submitted for audit. We return partner-provided audited hardware, if the company requests it. We assume no liability for returned hardware that was reconfigured or damaged during testing or shipping.
If we request a particular product, you must provide the product configured in retail packaging within 30 days, following the direction provided by the Windows
Certification Program. Any special instructions required to configure the device or system for certification should also be included with the audit hardware.
Response to observed audit failures
Occasionally, we may find in audit a significant issue that places a product out of compliance with the goals of the certification program. If the observed issue is significantly outside expected performance (for example, reliability, security, missing critical experience), we notify partners about the audit results, describe the required fixes to bring the product back into compliance, and set the required timeline for implementing the required updates. If we and the partner can't agree to terms on the requested changes, we reserve the right to remove the certified status of the product. The noncompliant product then drops from our catalogs. The Windows logo must be removed from the product and all packaging and promotional materials associated with that product.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 18
Submissions types that don't require complete testing
In some cases, complete testing isn't necessary.
Reseller submissions
The Reseller Submission Policy allows companies that purchase a certified product from a manufacturer to resell as their own and receive a listing in the Microsoft catalogs and Hardware Compatibility List. Resellers repackage and relabel the purchased device or system with the right to display the logo. Resellers must have sign a Logo License Agreement in order to claim certification rights to the resold product.
Reseller submissions don't require retesting. A reseller submission retains a dependency on the parent submission. If the parent submission fails an audit, the reseller submission also fails.
Products that are submitted as a reseller submission have the following restrictions:
The reselling company can't change the hardware or software when relabeling or repackaging the product, except for branding or splash-screen changes to identify the product under the new company name.
The distribution rights for the original driver remain with the original submitter.
If a reseller wants to control distribution for its product, take the following steps:
1.
Revise the PnP ID of the product to include the subvendor ID.
2.
Submit a Driver Update Submission that revises the information (.inf) file to reflect the new PnP ID.
If a reseller wants to change the driver binary for a device, a new initial device submission must be made (with full testing).
All reseller submissions are subject to audit.
For a peripheral device (connected device) whose primary function is outside the interaction with the PC and whose functionality is evaluated by the
Windows HCK, changes that don't affect the interaction between the device and the PC or affect the applicable requirements are not considered grounds for a resubmission.
For more information:
See Manage Hardware Logo Submission in Dashboard Help .
Refer to Driver Update Acceptable (DUA) and audit policies as they relate to this policy.
Refer to Device Family Testing policies as they relate to this policy.
Driver update acceptable
Occasionally, a certified device requires that its driver be modified in ways that don't change the binaries and interoperability of the device with a system. In these cases, you may submit a DUA package.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 19
Conditions where a DUA is acceptable
For an already approved driver submission, changes to driver packages that add, remove, or modify files that don't interoperate with or otherwise affect driver functionality or reliability are allowed via a DUA submission. A DUA submission may include only changes in file types: .txt, .htm, .rtf, .chm, .hlp, .inf, .icm, .jpg, .bmp, .cpl,
.pdf, .mht, or txtsetup.oem. No changes are allowed for the driver binaries (such as
.sys and .dll. You may add new hardware IDs in the INF file as part of these updates, provided that they meet the family policies.
Conditions for a DUA
Retesting isn't required for a DUA submission. The Hardware Dashboard performs a
WinDiff file comparison with the original to ensure that no binaries have changed.
Submissions for device driver maintenance
Microsoft recognizes the need to maintain devices and improve driver quality for devices already certified and in the marketplace. Maintenance submissions are allowed so drivers may be tested and submitted for recertification after new logo requirements are implemented for specific features and required for certifying for certain product types. The device is resubmitted including the failures resulting from new tests in the certification since originally submitted.
In a maintenance submission, the original certification submission ID must be referenced in the submission readme file. Any test assertions that fail under the new kit will be reviewed to assess whether the original bar was met. It is the responsibility of the company submitting to identify the new failures in the individual tests that are new and were not there previously. Our expectation is that partners will ensure that there have been no regressions after updating the product. This should be documented using the standard readme.doc file that is included with the submission.
Maintenance submissions are not a method to recertify for a new major Windows release (client or server), such as Windows 8 to Windows 8.1. A product must meet the certification requirements for the new operating system in order to obtain a certification and use the Windows logo artwork. Note: a similar maintenance recertification is available for system submissions.
Maintenance submissions must comply with the following restrictions:
No new PnP IDs can be added to the INF file.
The driver can't be used with new products.
Don't add new product names to the catalog.
Acceptable device changes without resubmitting
The Windows Certification Program takes into consideration that not all device/firmware changes affect the interoperability of the device with Windows.
There are guidelines for when a retest and resubmission are necessary.
Silicon chipset size reductions (die shrinks) are allowed, provided that the device ID or subsystem device IDs are unchanged, no functionality is added or modified, and the
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 20 drivers are unchanged. If the die shrink affects other certification requirements, such as S3 resume time, the device requires a full retest and resubmission.
Changes that require resubmission include:
Changes in device components, firmware, or BIOS, with exceptions as noted in "System Family Testing and Updates Requiring a New Submission" later in this paper.
Changes to touch device components.
Changes in supported operating systems or I/O interfaces (also known as buses) not found in the original submission.
Changes to multifunction devices.
Simplified submissions for Windows 8
In many device areas for Windows 8.1, the device requirements are identical to
Windows 8 or possibly a superset where if a device can pass for Windows 8.1 the device would pass for Windows 8. To simplify your testing efforts we are allowing a simplified testing regimen for the following Product Types. This is primarily designed to allow drivers to be signed for Windows 8 without full retesting.
Product Types where a Certified Windows 8.1 devices/drivers can be resubmitted for 8.0 (details below)
Distribution Scan Management Enabled Devices
Enterprise WSD Multi-Function Printer
Graphics Tablet
LAN CS
LAN
Multi-Function Printer
Pen Digitizer
Precision Touchpad
Printer
Scanner
SDIO Controller
Signature Tablet
Smart Cards
Smartcard Reader
Storage Array
Storage Controller (Client)
Storage Spaces Adapter (Client)
Storage Spaces Drive
Storage Spaces Enclosure
Touch
Touch Monitor
USB Hub
WSD Multi-Function
WSD Printer
WSD Scanner
In any of the Product type areas listed, a certified Windows 8.1 driver may receive a
Windows 8 signature without complete retesting by proving the INF is well formed for Windows 8 .
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 21
A.
Using the HCK for Windows 8.1, create a Windows 8.1 project, and run the full certification suite of tests.
B.
Create a Windows 8 project and only run the Device.DevFund INF test.
C.
Package the results of the projects for submission uploading, using the portal packaging tools.
D.
Reference errata ID 2656 “Windows 8.1 to Windows 8 driver certification downgrade special” in the README folder.
The submission will be processed in the following manner:
A.
Confirm the Windows 8.1 test results.
B.
Confirm the Devfund INF test is passing for Windows 8.
C.
Confirm using the same binary is used in both projects.
Testing policies for devices
Device family testing
The Windows Certification Program requires that each family of devices be tested and submitted to Microsoft, even if the driver is identical for each submission. If your
INF file contains devices that are considered different device families but you don't intend to test them, remove the extra devices from the INF file.
Definition of family
A device product family is a set of devices that expose the same functionality or a subset of functionality and would interoperate with Windows in exactly the same manner. A member of the device family that contains the full set of all the features must be the "tested representative" for the family. All devices that are a subset of the most fully featured products must meet all certification requirements for their functionality.
Determining when to consider a group of devices as a separate family
Evaluate each device that the driver supports. If any of the following conditions apply, create a new family:
If a device uses a different device class, Peripheral Component Interconnect
(PCI) class and subclass, or vendor ID (VID).
If a device uses different driver binaries or uses a separate INF file.
If a device has different firmware.
If a device supports different bus protocols. If multiple protocols are supported, such as SCSI, Internet SCSI (iSCSI), or Fibre Channel, these protocols must be tested separately and are considered separate families.
If a device supports different media or drive types.
If a device supports multiple protocols, media, and drive types, each combination must be tested separately and are considered separate families.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 22
There are some exceptions to these rules. The following devices have additional characteristics to classify families.
South Bridge SATA and ATA/ATAPI controller families
Controllers that are integrated into a South Bridge chipset must support the same base logic. If the driver supports an add-in controller, the add-in must be tested as a separate family device.
RAID controller, iSCSI adapter, and Fibre Channel adapter families
Controllers that have identical core BIOS code and ASIC firmware are tested as a single family. String changes to the BIOS code are allowed between family members.
If the BIOS code or firmware is updated, another family submission is required.
RAID system and RAID JBOD families
The number of controller modules within the same family may differ.
Controller hardware and firmware must be the same for a particular family.
If the controller hardware or firmware is virtual (consists of only software), any major revision of this software for added functionality (such as bus speed) requires a new family group.
Non-multipath or non-Microsoft Multipath I/O (MPIO) drivers: A complete RAID system test must be completed against each RAID system device that is included in the INF file.
Third-party multipath and Microsoft MPIO driver implementations: A scaled test procedure is available to test multiple families. For more information, see the corresponding section of the multipath test procedure. This scaled test procedure does not grant base qualification or certification to these additional subsystems.
GPU families
Graphics processing units (GPUs) that don't support the same major Microsoft
DirectX revisions are in different GPU families.
Here are some DirectX revision examples:
GPU A supports DirectX 10 and GPU B supports DirectX 10.1 = same GPU family.
GPU A supports DirectX 9 and GPU B supports DirectX 10 = not the same GPU family.
GPU A supports DirectX 10 and GPU B supports DirectX 11 = not the same
GPU family.
GPUs that are not manufactured by the same company are part of different
GPU families. For example, GPU from Vendor A and GPU from Vendor B (any
DirectX revisions) = not the same GPU family.
Mobile broadband device families
If a mobile broadband device supports multimode operation (for example,
GSM and CDMA), the mobile broadband device must be tested and submitted in all supported modes.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 23
Any firmware changes that affect the mobile broadband data path and control path functionality that are defined in the Windows mobile broadband driver model require a resubmission.
Firmware changes in a mobile broadband device that don't affect the data path and control path also require a resubmission, except in the following cases:
Firmware changes to support different frequency bands for different geographies and operators
Firmware changes to support different VID or product ID (PID) for mobile operator or OEM customization
Firmware changes to add OEM-specific module authentication
INF file changes in a mobile broadband driver to update the VID or PID for mobile operator or OEM customization are in the same device family and don't require resubmission.
Devices that have a different generation of chipset are considered a member of a different family and require resubmission.
Devices that have a chipset from a different manufacturer are considered a member of a different family and require resubmission.
For a multifunction mobile broadband device (for example, a mobile broadband device that also includes GPS functionality), the impact of a firmware change to the other functions of the device (in this example, GPS) on the device family is governed by the guidelines of the certification program for that device class.
Windows 7 touch families
In the case of Windows Touch digitizers that differ only in screen size, this policy is clarified in the following way.
Note: the following clarification applies to only differences in the dimensions of the screen size of the devices and only for Windows 7 submissions. Any changes to drivers, firmware, controller/optical/sensors, or bus connections require resubmission of the device according to standard procedures.
Manufacturers of Windows Touch digitizers don't need to resubmit devices that differ only in screen size if the differences fall into an allowable range that has been defined by previous submissions of the same device. The allowable range for a particular device is defined when:
At least three successful submissions have been approved for that device at different screen sizes.
Of the three successful submissions, the size of the midsized screen falls into the middle third of the distance between the smallest and largest size screens.
The new device does not add a different power capability (for example, DC) that isn't present in the three devices, which define the range.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 24
Screen size is measured as the diagonal dimension of the touchable area of the screen, in millimeters, to two decimal places. Submissions that make up a range may be submitted in any order.
For example, a partner makes three successful submissions of the same device, with same power configuration, at screen sizes of 600 mm, 500 mm, and 560 mm. These three submissions define an allowable range for that device of 500 mm to 600 mm.
(For the midsized device, any size between 533.33 mm and 566.67 mm is considered valid as the midpoint of this allowable range. The middle third is defined as one-third of the difference between the smallest and largest size [100 mm / 3 = 33.33 mm]. The
33.33 mm falls in the middle band, with 16.67 mm on either side of the midpoint.)
After an allowable range is defined, any new devices that are produced within the allowable range are not required to be resubmitted for certification.
Devices that have a screen size outside that of the allowable range, or that add new power capabilities such as DC battery power, must be submitted in accordance with standard submission procedures.
Any submission of the same device at a different screen size that fails the Windows
Touch verification tests does not invalidate certification for the sizes that were previously submitted. Failing the Windows Touch verification tests simply means that the experience at that screen size is inappropriate for the purposes of defining or extending the allowable submission range for the device.
Portable device families
Devices that are submitted for portable devices product types require hardware certification testing at the product family level.
Any licensee or reseller of a portable device product family can take advantage of submissions that were made by the original submitter by completing a reseller submission. A reseller submission is necessary to legally transfer the certification rights to the licensee.
The definition of the portable devices product family consists of the following areas:
Software requirements: Product family uses the same operating system and firmware.
Operating system may include a service pack (point upgrade) from the original submission.
OEMs that add extra functionality on the interaction with the PC are required to make a new submission.
Firmware must be evaluated to provide an acceptable experience with the device operating system.
Common components: The family of devices must support the same core components that outline the experience with Windows, such as:
Codecs
Transports
Protocol
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 25
Additional supported features are acceptable unless they affect the overall kit results for the product type.
Minimum hardware specifications: A baseline specification is required to belong to the product family.
Chipsets: Processor capacity can't be lower than that in the original submission specification.
Memory: Capacity that is available to the system must exceed the original submission.
We exclusively define the list of product families. We reserve the right to modify the list of product families at any time without prior notice.
Network media device families
Devices submitted for the Digital Media Renderer (DMR) product family require hardware certification testing at the product family level. Successful passing of hardware certification tests enable certification of the other members of the product family.
We exclusively define the product families by using the following characteristics:
Operating system
Firmware
Minimum hardware specifications
If a product family is developed by a third-party OEM and resold to other manufacturers, then the product certification applies to all devices that are released under the same hardware design, operating system, and firmware that were released under a reseller agreement.
Changes to firmware require a new submission for the parent device using the updated firmware.
Significant changes to hardware that may affect the certification test results also require a new submission.
Software-based network media devices can be grouped as a family of products. The following requirements define a software product family:
Software DMRs must pass the same tests as hardware DMRs. The implementer must install the software DMR in its typical platform. The DMR is then connected to the PCs that drive the certification tests. Each test results in a pass/fail outcome. A DMR that passes all tests can apply for
Windows certification.
Software DMRs apply for certification for a specific platform. The following parameters define a platform:
Parameter
Operating
Options 1
Windows 7, Windows 8, Windows RT
1 Implementers can enter other options if they are not listed here.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 26 system
CPU base
Android Gingerbread, Android Honeycomb, Android Ice
Cream Sandwich
Mac OS X Snow Leopard, Mac OS X Lion iOS version 4, iOS version 5
Intel x86, Intel x64, ARM, Apple A4/A5
Any change in platform parameters requires recertification. For example, a software DMR that runs in Windows 7 must be recertified for Windows 8.
Additional notes, clarifications, and processes
Although it's possible to test multifunction devices by using the family rules described previously, be aware that the resulting certification might cause some confusion in the catalog and marketplace. The highest set of features is associated with the submission, so a catalog listing where a particular sought-after feature isn't included in all devices in the family could be confusing.
For example, in a multifunction family submission, if the highest-functioning device used several connectivity pathways, but some of the subset family members did not include all of the connectivity pathways, the catalog listing might be confusing.
There's currently no way for the certification program to handle this listing issue.
Device drivers often support more than one device, such as a printer driver that supports 10 different models of printers, or a display driver that supports 25 different
PnP IDs. To assure quality, we recommend that vendors test every device that a particular driver supports.
We recognize that in a particular device category, there are cases where testing a model that is the most fully featured, or one that is physically and electrically identical to another model, offers no increase in test coverage. In these cases, conducting an additional test pass for certification would not expose any additional hardware or driver flaws.
In an effort to simplify and reduce the amount of testing that is required to achieve a certification on every hardware/driver combination, the following rules apply to your device testing coverage plan. Devices that are considered equal to each other are a family of devices. A particular driver may have 100 unique PnP IDs in the INF file, but after you apply these device-testing policies, you may find that only 10 devices must be tested to achieve full test coverage for your device/driver combinations.
Multifunction devices
Some devices contain multiple features that are associated with more than one unique product type. Multifunction printers, for example, often include a scanner, fax, and removable storage. Radio devices may support multiple frequencies and protocols, which expose to Windows as seemingly unrelated features.
A multifunction device presents to the Windows HCK by its Container ID, which identifies the collection of devices bound together in the same plastic, same chip set, or same card. The Windows HCK probes each PnPID in the collection for the features it exposes. The entire collection must pass in order for the multifunction device to be certified. It's acceptable for some of the devices in the collection to offer unique
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 27 functionality that does not match a product type (Signature-only product as described previously). A multifunction device, which includes these Signature-only products, is certified if matches at least one product type and passes testing of all exposed features.
As with any product tested in the Windows HCK, all features detected on the device must pass in order for the product to receive certification. There are some special testing cases in which certain devnodes can be deselected if they match the criteria that follow.
If for some reason the use of a ContainerID isn't appropriate, each functional unit and connectivity type in the multifunction device must be tested separately and the logs combined and submitted as a single submission. For a multifunction device that works with multiple drivers, all drivers must be installed on the test machine prior to testing the entire device. This requirement ensures that the installation/uninstallation of one of the drivers of a multifunction device doesn't impair or interfere with the operation of the other drivers or functionality of the device.
Devices may include a bus port that enumerates no functional units and is for maintenance only. If multiple bus ports exist, each must have identical functionality.
It isn't acceptable for any bus port to offer only a subset of supported functional endpoints.
Special cases for multifunction devices
The general rule for all Windows HCK testing is that any exposed features must be tested in their entirety for the device to be certified. However, with some common multifunction devices, there's an exception is made for the child nodes of USB composite devices. In these situations, you may deselect certain tests because the device fundamental testing against the parent node exercises the USB child nodes.
Rules for deselecting certain Device Fundamental tests:
1.
These exceptions are allowed only for multifunction devices that contain printing, storage, or mobile broadband product types as part of the multifunctionality. All other multifunction devices must be tested in their entirety.
2.
The parent node USB Composite Device DevFund tests are run in their entirety.
3.
Any child USB composite nodes that don't contain any feature sets other than the Device Fundamental tests may be deselected and not tested. If the subnode contains additional features, none of the features may be deselected from it. All features in that subnode must be tested.
4.
For multifunction devices with an internal USB hub, you may not deselect any
USB root hub devnodes with child nodes that expose features that run additional DevFund tests.
For clarification regarding these rules, contact sysdev@microsoft.com
and include a screenshot of the nodes or the full name of the node.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 28
The Windows Hardware Certification Program reserves the right to expand or contract the areas covered in the "Special Cases" section as more devices are identified or user experience issues are detected. The Windows Hardware
Certification Program reserves the right to eliminate the "Special Cases" clause of this policy if evidence of impact to user experience is related due to the application of the criteria specified in the "Special Cases" section.
Testing devices with multiple connectivity
Test a multiple connectivity device by connecting the device to a client through all available pathways that the device supports. After a device is identified as the testing target, the device's multiple connectivity are detected and treated as features, minimizing the number of tests that must be run.
Switched-mode devices
Some devices—cameras, for example —switch modes on the device controls, establishing a different communication with Windows for each mode. The Windows
HCK can't detect these different modes automatically and doesn't automatically test all features of the multifunction device. These devices require manual reconfiguration to completely test the functionality. We recommend that you treat each mode as a separate project and merge multiple projects into a single submission package.
Network Media devices may contain a single device that communicates with the system, but that one device may contain multiple product types, such as both
Network Media Display and Render. After the Windows HCK identifies the target, these functions are enumerated as part of the gatherer activity, and all of the features are exposed for testing. In some cases a Network Media device may have certain functions that are only exposed if the device experiences a mode change. A tester with knowledge of the device should recognize the inability of the controller to detect this feature and manually reset the device, testing these additional features as separate projects and merging the multiple projects into a single submission package.
Windows RT connected device certification and testing
Windows RT uses class drivers and in-box drivers exclusively, departing from a common driver added scenario on the x64 or x86 architectures. Connected devices on Windows RT are tested and certified using only the in-box or class driver.
A device cannot be certified only for Windows RT and not Windows 8 as well. The
Windows RT certification is always in addition to the certification the device has undertaken for Windows 8.
Windows RT occurs with the device connected to a Windows RT system running as a client in the Windows HCK environment (subject to the exceptions noted below).
Connected devices are certified for Windows RT if the device passes all relevant certification tests with the Windows RT in-box or class driver, passed Windows 8 certification on X64, and meets the additional requirements found in the Logo
Licensing Agreement (LLA). The LLA includes important details for how certain connected devices may display the Windows RT Certification Logo and additional information that must be disclosed on packaging for multifunction printers that
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 29 display the Windows RT Certification Logo. The Windows RT testing exceptions follow.
Testing exception for network media devices and routers
Network media devices and routers interoperate with Windows using network protocols, not architecture-specific drivers. Network media devices (NMD) and routers can be certified for Windows RT when they pass Windows HCK tests using an x86/x64 client system. An NMD or router does not need to be retested in a
Windows RT environment to display the Windows RT logo. Testing for routers is available only in the x86 environment and testing in the x86 environment is sufficient for x64 certification. Similarly, a NMD need only be tested on x64 or x86 to qualify for certification for all three platforms (x86, x64, and RT). See the LLA for additional information regarding the appropriate use of the certification logo on connected devices that are certified for Windows RT.
Para-virtualization drivers
Para-virtualization drivers are device drivers in a virtual machine instance of the
Windows operating system that represent hardware and functionality similar to, but not necessarily identical with, the underlying physical hardware that the system virtualization software layer uses.
For example, the physical network interface adapter that is installed in the system can be either presented or abstracted to the virtual instances of Windows. The paravirtualization driver emulates a network adapter, but it's not necessarily the same network adapter as the physical device.
The Windows Certification Program qualifies device and driver combinations according to the Windows Hardware Certification Requirements and the relevant tests. The Hardware Dashboard accepts para-virtualization driver submissions by using the current testing guidelines. These drivers are tested, submitted, signed, granted certification, or displayed in the relevant catalog through existing device driver procedures. Specifically:
The submitted para-virtualization driver must emulate the same functionality that is required of physical devices and their associated drivers. This includes installation, Advanced Configuration and Power Interface (ACPI), PnP, and other functionality, as described in the respective Windows Hardware
Certification Requirements.
A submission of a para-virtualization driver may occur only for the version of the Windows Server operating system that is used for testing as a virtual instance. In addition, a submission of a para-virtualization driver may occur only for the platform version of the Windows Server operating system that is used for testing as a virtual instance—specifically, the x86, x64, or Itanium processor platforms.
The para-virtualization driver must be tested in accordance with the test requirements that are relevant to the Windows operating system version for which the para-virtualization driver is being submitted. For example, server storage and networking drivers must be tested on a system that has a minimum of 4 processors and 6 gigabytes (GB) of memory installed. The
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 30 submitted storage or networking para-virtualization driver must be tested in a virtual machine instance of Windows that has 4 processors and 6 GB of
RAM represented, if the virtualization product supports those capabilities. In testing storage and networking para-virtualization drivers, if the virtualization product can't support a Windows virtual instance of 4 processors and 6 GB of
RAM, the testing should occur with the maximum processor count that is supported by the virtualization product for a Windows Server virtual instance, and with the maximum amount of RAM that is supported by the virtualization product for a Windows Server virtual instance, not to exceed 6
GB of RAM.
Other device category requirements for the minimum number of processors and the minimum amount of memory required for testing of that device category apply, as detailed in the documentation for the test that is appropriate for that version of the Windows Server operating system.
The submitted para-virtualization driver must pass all the tests that are defined and required for the device category that the para-virtualization driver represents to a virtual instance of Windows, appropriate to that version of Windows.
The submitted para-virtualization driver that meets all the requirements and passes all the tests that are defined and required for the device category that the para-virtualization driver represents to a virtual instance of Windows will be granted certification.
If the Windows HCK exposes a feature, the feature must be tested and pass to receive a signature. In the earlier Windows Logo Program, it was possible to receive a signature if the device could not pass the full requirements of a category. In the current Windows Certification Program, all exposed feature must pass testing.
No submitted para-virtualization drivers may use the universal/Signatureonly category for a submission if the Windows HCK exposes a feature or if a
Windows Certification Program device category exists for the class of device and driver that the para-virtualization represents to a virtual instance of the
Windows operating system. If the Windows Certification Program determines that there's no suitable device category for the - driver, the universal/Signature-only category tests may be used for testing and submission. Vendors of para-virtualization drivers that the vendors believe should use the universal/Signature-only category must communicate with the
Windows Certification Program and confirm that the Windows Certification
Program agrees with their assertion prior to testing and submission.
The submitted para-virtualization driver that meets all the requirements and passes all the tests that are defined and required for the universal/Signatureonly category will receive a Signature-only, because there's no certification for universal/Signature-only devices or drivers.
If an issue is encountered during testing of the para-virtualization driver, that issue must be resolved before a test submission occurs. Resolution can occur in the following ways: by correcting the issue; by referencing an errata ID,
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 31 incident ID, or contingency ID number; or by following the process that is outlined in the Hardware Certification Program Policy for Issue Resolution.
All other Windows Certification Program policies apply to para-virtualization drivers, including policies regarding required retests, resubmissions, product naming, reseller, audit, grant of certification, and distribution.
The Windows Certification Program will cease accepting submissions of paravirtualization drivers for a specific version of Windows on the same date that submissions are no longer accepted for physical devices.
Touch device testing
Successful touch devices depend on a high degree of integration between many materials. Although the Windows operating system interoperates with the controller, a good controller may still provide a bad user experience if it's paired with the other components incorrectly. For this reason, touch hardware must be submitted, because it will be paired for shipping as a touch device.
The touch device consists of the key components integrated together, which allows for physical user input and interactions to be interpreted and communicated to the system via a bus. All components must be integrated together as a device that is targeted at a specific environment or system, to help ensure that touch quality does not degrade after it is integrated into a system.
The components that define a touch device are not bound to a specific touch technology and may include (but are not limited to):
Controller, including all touch device firmware, configuration software, integrated circuits, and board design.
Conductor layout and pattern.
Glass and/or film configuration, including digitizer, display and cover glass stack, glass/film thickness, bonding architecture, and surface treatment.
Display characteristics, including screen size, aspect ratio, and resolution.
Image sensor positions (locations and height) and reflector material.
Transducers or other methods of sensor detection.
Communication bus (USB or I 2 C)
Touch devices must be pre-calibrated and must not require any additional calibration before usage.
All touch devices in a system must be separately addressable and independent of one another. Each touch device must be individually tested and submitted for certification.
Touch Device Resubmission and Multi-source Subcomponents
Any changes to touch device components require a full retesting and submission of the touch device for recertification. If identical subcomponents are sourced from different manufactures, recertification must occur to ensure touch reliability and performance is maintained. The same PID and THQA may be utilized when identical subcomponents are utilized in and existing touch device.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 32
A touch module is defined as the combination of a unique touch controller IC and touch sensor. Each distinct touch module must have a unique PID that is exposed to the host. Multiple systems may use the same touch module with differing LCD panels, however it is highly recommended that each touch module and LCD panel pairing be independently certified. Changes in bus connectivity (USB/I2C) for a touch module shall not require a PID change as the module itself is materially identical, however it is highly recommended that a module be independently certified with each connectivity option.”
Graphic Adapters Test Optimization Procedure
To encourage a high quality hardware ecosystem for Windows 8.1, a set of test optimizations are being introduced to help re-balance logo testing and allow partners to invest more in Windows 8.1.
This procedure becomes effective immediately and is only applicable for Graphic adapter product type on client OS SKU’s.
The following grid outlines the testing requirements of this procedure.
Client OS/Arch Certification Log Requirements for Windows 8.1
Windows 8.1 client x86
Windows 8.1 client x64
Reduced WHCK logs *
Complete WHCK logs
Windows 8 client x86
Windows 8 client x64
Reduced WHCK logs *
Reduced WHCK logs * if the same GPU is targeted for logo for
Windows 8.1 client, else Complete WHCK logs
Windows 7 client x86 Reduced WHCK logs *
Windows 7 client x64 Complete WHCK logs
*Reduced Testing is required to ensure that the necessary logs are included for the drivers to be signed for PE and involves the partner joining one client and running the included tests.
Procedure Applies Description
Tests Included
Applicable Product Type
Test Environment
Requirement
1.
Device Driver INF Verification Test (Certification)
2.
COPP - Protocol Test
3.
OPM - Protocol Test
Full graphic adapter product types
WHCK Release with Windows 8.1
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 33
Log requirement for
Windows 8.1 with previous
OS submission
Log requirement for Win 8.1 full-set for x64 and reduced log set for x86 stands true if log submission requirement met for either Win7 x86/x64 or Win8 x86/x64.
Submission Requirements:
Listing errata 1274 in the readme
The 64-bit and 32-bit drivers must be submitted together for this optimization to apply. o Since both the 64-bit and 32-bit drivers are Logo certified, both will be entered into the LPL
This procedure does not apply for below condition, and a complete WHCK log set is
required for both x86 and x64:
Procedure DOES NOT Apply Description
OS Architecture
Applicable Product Type
Test Environment
Requirement
OPT-Out
Windows RT architecture
DisplayOnly or RenderOnly graphic adapter product types
If testing for a single OS only
Any device may choose to conduct full Logo testing and will continue to receive a Logo certification
Microsoft Reserved Right:
It is expected that partners will continue to thoroughly test the Windows drivers and will ensure high quality of drivers. Microsoft reserves the right to terminate this
Optimization Procedure at any time without prior notice.
Testing policies for client systems
Certified components
Certified systems must use certified components. Component-level testing reduces the need to repeat the same testing for the system certification. Component features require retesting on the system level only when there's a possibility that integration issues may be exposed in the context of a completed system. Some Windows
Hardware Certification Requirements may exceed system requirements, and systems must meet all of the certification requirements to obtain a certification.
Digital signature policy for systems
The Microsoft digital signature on drivers helps ensure reliability and compatibility with Windows. The preinstalled image that is shipped on certified systems must include device drivers that are signed for the shipped operating system or use in-box
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 34 drivers. All components in a system must meet the definition of a defined product type to be included in a system, unless a product type does not exist.
For example, if the system ships with Windows 8, all drivers on the system must be signed for Windows 8 or use in-box Windows 8 drivers. Similarly, if the system ships with Windows 7 and is shipping Windows 7 preinstalled, all drivers that are shipped on the system must be signed for Windows 7.
The drivers may be signed for multiple versions of Windows.
Systems and the use of Signature-only components
A certified system may use a Signature-only component only if the Signature-only component serves a unique function beyond the functionality that Windows natively supports. If a defined product type that an end user would expect to find on a certified system exists, the use of a Signature-only component that does not include all of the features expected of the component makes the system ineligible for certification. This rule applies for all Windows client and server operating systems.
Contact sysdev@microsoft.com
with specific questions.
System form-factor definitions
Certain Windows scenarios apply to particular form factors, and the features and requirements for those scenarios are required only for those form factors. The formfactor restrictions are specified in the requirements. The Windows 8 form-factor definitions are as follows:
Tablet
Convertible
Desktop
All-in-one
Laptop
A tablet form factor defines a stand-alone device that combines the PC, display, and rechargeable power source in a single chassis.
A tablet does not include a permanently attached keyboard and pointing device but connects to a port replicator, keyboard, and/or clamshell dock.
A convertible form factor defines a stand-alone device that combines the PC, display, and rechargeable power source with a mechanically attached keyboard and pointing device in a single chassis. A convertible optionally configures as a tablet, with the attached input devices hidden, leaving the display as the only input mechanism.
A desktop system is a uniprocessor or multiprocessor system that requires AC power for continuous operation. A desktop system does not include attached peripheral devices such as mice, monitors, keyboards, or printers.
An all-in-one is a uniprocessor or multiprocessor system that has a permanently attached integrated display. All-in-ones typically include integrated components that are based on mobile hardware designs.
A laptop is a uniprocessor or multiprocessor system that can be physically carried, has integrated display and input devices, and
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 35 has a battery that can provide continuous operation when it's not plugged in.
Windows 8 uses a simple form-factor breakdown of the system. Tablets and convertibles share requirements enhancing the mobile and touch-oriented scenarios.
The requirements for the other form factors—desktop, laptop, and all-in-one—share the other common feature-based requirements. If these less mobile and touchoriented form factors expose these additional features, they're expected to meet the requirements as defined.
The Windows 7 system requirements also break down per form factor. The
Windows 7 form-factor definitions are as follows:
Desktop
All-in-one
A uniprocessor or multiprocessor system that requires AC power for continuous operation. A desktop system does not include attached peripheral devices such as mice, monitors, keyboards, or printers.
A uniprocessor or multiprocessor system that incorporate a permanently attached integrated display. All-in-ones typically include integrated components that are based on mobile hardware designs.
Mobile
A uniprocessor or multiprocessor system that can be physically carried, has integrated display and input devices, and has a battery that can provide continuous operation when it's not plugged in.
Ultra mobile
A mobile system that has a 10.2-inch or smaller screen size.
Using previously certified motherboards in client systems
OEMs may use a previously certified motherboard to certify client systems for
Windows 7 or Windows 8 without running the "Fidelity Test (System, Manual)" and
"Class Driver Fidelity Test (System, Manual" tests in the Windows HCK. Partners who choose to use a certified motherboard for Windows 7 or Windows 8 must meet all of the client system requirements for the version of Windows for which they are certifying for. The version of Windows that the system is being certified for must match the version of Windows that the motherboard was certified for. For example, if the system is being certified for Windows 8, then the motherboard must, at a minimum, be certified for Windows 8. The certified motherboard used for a client system submission must be listed on the Windows Certified Products List, which indicates that the motherboard satisfied the Fidelity Test and Class Driver Fidelity
Test when it was certified. The BIOS version must match the one used for the motherboard submission, subject to the exceptions listed in the system family testing and updates policy that require a new submission.
When you make your system submission, include a Readme.doc file that references manual errata ID 738, the product name of the motherboard, and the submission ID.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 36
The product name and submission ID must exactly match the listing in the Windows
Certified Products List .
Specialized PCs
A Specialized PC (SPC) is a system, either Client or Server, that has been designed specifically for an enterprise vertical market or a niche use case scenario which has an explicit design need to bypass or remove features required by certification. A certification review board will review the requests. If the board agrees the certification failures are necessary to meet the unique user scenarios for which the system was designed, the specialized PC may still be certified, provided there is adequate disclosure of the ways the system departs from the certification standards and it is clear what the end user impacts will be. A specialized PC is expected to meet all other certification requirements except those explicitly required to meet the use case and disclosed. The certification process validates that the system passes all certification requirements with the exception of those reviewed, approved for this special case, and disclosed.
Examples of SPC would be a ruggedized system with resistive touch screens, a technology that currently cannot meet the 5 touch minimum. Other examples are systems sold into highly regulated medical environments needing sealed surfaces and signal screening, or systems sold into specialty applications such as ATMs and kiosks.
Examples of removals at bid request would be a certified system where the webcam was removed for security reasons, or networking removed and replaced by a proprietary secure communication channel.
Specialized PCs require a formal request documenting the specific feature areas which have been requested for removal or bypass as a part of the certification process. This program cannot be used as a bypass for failing features in a system designed for general use. For a system to use the designation of “Specialized PC” and use the certification logo, the OEM must submit a special review request using a form available through the Sysdev@microsoft.com alias. Should the request be approved a set of conditions are placed on the certification including:
1.
The system is sold only through acceptable enterprise channels. The system may not be sold through consumer channels.
2.
The system is sold only with the Professional SKU, or appropriate Server SKU.
3.
The OEM must disclose the results of the certification testing including conspicuous disclosure of any limitations in a system’s Windows features or functionality as compared to a system that passes all certification requirements.
4.
As a part of OEM disclosure, an OEM must make applicable disclosures which have been designated through the Specialized PC approval process in a prominent and conspicuous manner to customers prior to purchase of the system. This may include a warning on the system directly, and additional disclosures in marketing literature, conspicuous placement on the OEM website, product purchase pages, support pages, and other relevant locations which are easily discoverable by a user prior to purchase of the system.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 37
5.
The OEM will be responsible for the support burden that may come from the loss of functionality, holding Microsoft harmless.
SPC submissions are always marked for manual review and fail if the failures in the submission do not match with those specifically defined in the contingency.
The following hypothetical Specialized PC disclaimer is provided as an example:
This device has been certified for Windows 8 as a Specialized PC (SPC). The
SPC certification program allows for the certification of commercial devices designed with industry specific features that conflict with the standard
Windows 8 certification requirements. As a result, certain features or functionality of Windows 8 may not work as expected. For complete details, including information about features which are not in compliance with the standard Windows 8 certification requirements go to <link to OEM website>.
For more information, see Specialized PCs on the Windows Hardware Dev
Center.
Testing a docking station designed for the system
A docking station is any peripheral device which is designed to add functionality to a mobile system when it is at a more permanent location. Typically, docking stations add additional external ports and even functionality internal to the station, which may allow keyboard, mice, additional storage, a second monitor, other handy peripherals and a power connection to all be added to the system in a single connection.
By their very nature, docking stations add multiple potential points of failure to a system, since all of these additional devices are added and removed in a single action.
If an OEM creates a docking station for a certified system or system family, whether the docking station is sold with the system or separately, the system must pass all relevant testing both in and out of the docking station. During the testing a representative load of certified attached devices should populate the docking station.
On successful testing of the system with the docking station, the docking station is certified as a multi-function peripheral.
Should the docking station not be certified, the system itself can lose its certified status since we cannot assure that the system handles easily expected surprise removal and sleep removal scenarios. During Windows HCK testing, the system remains docked and connected to AC power unless otherwise noted by a specific test in the Windows HCK. A test in the Windows HCK may ask the tester to disconnect the
AC power from the wall or for the end user to undock the system to ensure that the system is meeting certification requirements in both undocked and docked situations.
System family testing and updates that require a new submission
To make system certification simpler by using the Windows HCK, we define a system family as follows:
Same major BIOS version.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 38
Same motherboard manufacturer and model. The motherboard in the same systems within a family must have the same VID and PID.
Same CPU family, which is defined as having the same manufacturer and being PIN compatible with the socket on the system.
It's acceptable to test systems that have either the same or different range of memory (RAM), different storage capacity, or different CPU speeds, provided that the
CPUs meet the family definition described previously.
The system form factor must be the same for all systems within a system family.
Swapping devices on a system can have an impact on the stability, reliability, and performance of the system. Certain changes require you to test the system, including:
Swapping of touch devices.
Sensors.
GPUs that span different families.
For instructions on how to set up a system family for the Windows HCK, see the
Windows HCK documentation.
Testing GPUs across different GPU families
If you're swapping a GPU with one from a different GPU family, you can either run another system submission or add the system to the family of systems that is being tested.
A GPU family has the following requirements:
GPUs that are manufactured by two different independent hardware vendors
(IHVs) are in different GPU families.
GPUs that don't support the same major DirectX revisions are in different
GPU families.
For example:
GPU A supports DirectX 10 and GPU B supports DirectX 10.1 = same
GPU family.
GPU A supports DirectX 9 and GPU B supports DirectX 10 = not the same GPU family.
GPU A supports DirectX 10 and GPU B supports DirectX 11 = not the same GPU family.
Using Distributed Testing for System Family Testing
The Windows HCK has added the ability to create a system project with more than one system as a target. In this case the testing is distributed across the available systems greatly reducing the testing period required. Although originally designed for use with identical systems, this does allows the test pool to contain representatives with the acceptable changes described above for family systems. The graphics tests will run on each system that you put into your product instance as an alternative method to complete the GPU testing described above. This technique
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 39 avoids the need to run separate projects for each of the graphics variations used with the system. The rest of the systems tests are distributed over the target pool saving time.
Distributed testing is not appropriate for all tests. The kit itself will limit what tests can be distributed. If more targets are in the pool, the non-distributable tests will be run against every identified target.
The following rules must be followed when enabling distributed testing:
The motherboard must be the same for all the systems.
The CPU must be from the same IHV and PIN compatible
All systems use the same UEFI Firmware
The feature set must be the same
It is acceptable to swap GPU’s even if they span multiple device families
It is acceptable to have different swappable components (hard drives, memory, etc.)
Touch device
If you have a different touch device, the touch tests must run against that system.
You can include the separate system in the family machine pool.
Sensors
If you swap sensors, that system must be retested. Sensor integration is a critical aspect of system design and can significantly change the end-user experience. If multiple sensor combinations are anticipated, it's acceptable to add them to a system family machine pool so that they're tested in the initial system submission.
UEFI requirements for systems and devices
UEFI configuration for system certification
Windows operating systems can be 32-bit or 64-bit, but not both simultaneously.
UEFI can be 32-bit or 64-bit, but not both simultaneously. The architecture version of
UEFI must match the architecture version of the operating system. For example, 32bit UEFI (UEFI32) can only boot a 32-bit operating system; 64-bit UEFI (UEFI64) can only boot a 64-bit operating system.
Windows 8 and later certification requires that systems implement UEFI native boot as the firmware boot mode and Secure Boot as the default out-of-box configuration.
A system chassis must meet the following requirements:
If it ships with a 32-bit OS, it must be certified for UEFI32 and Windows x86.
If it ships with a 64-bit OS, it must be certified for UEFI64 and Windows x64.
If it ships with both 32-bit and 64-bit configurations, it must be certified for both configurations.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 40
If it's capable of both 32-bit and 64-bit support but only ships in one of those configurations, it must be certified in the configuration it ships in. Compliance with this requirement is verified by audits.
If it ships to an enterprise with Windows 7 installed, it must be certified for both Windows 7 with CSM and with Windows 8 x64 with UEFI64 or
Windows 8.1 x64 with UEFI64 . Compliance with this requirement is verified by audits.
The following table summarizes the acceptable system configurations:
Operating system CPU type
32-bit ARM capable
32-bit
Firmware type Boot mode
UEFI32 x86 and/or x64 capable UEFI32
Native UEFI
Native UEFI
64-bit x86 and/or x64 capable UEFI64 Native UEFI
The primary expected configuration for Windows 8 systems is 64-bit with UEFI64 firmware.
UEFI client system required for device testing
Windows 8 or Windows 8.1 device certification requires that a device is tested for client (not server) on a UEFI mode system. If the device testing takes place on a single client system, that system must be UEFI-enabled. However, if a distributed testing environment is set up using more than one test computer in the machine pool, not all have to be running UEFI.
Test environments must meet the following requirements:
At least one client system used for device testing must have UEFI mode enabled in a multisystem distributed test setup.
At least one client system used in each device family must have UEFI mode enabled in a multisystem distributed test project using multiple device families.
UEFI and Server systems
Windows Server 2012 R2 and later supports but does not require UEFI. When certifying Servers following the following rules regarding UEFI.
1.
For systems that support Class 3 UEFI implementations, vendors certify and submit them as UEFI platforms.
2.
For systems that support Class 2 UEFI implementations (UEFI+CSM), we encourage the vendors to certify and submit as UEFI platforms. For
Windows Server 2012 R2, we no longer require the Class 2 UEFI systems to certify and submit twice, once for legacy BIOS mode and the other for UEFI mode.
3.
For systems that support legacy BIOS implementations, vendors certify and submit them as they are.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 41
Testing policies for server system
Up-level and down-level certification policies for Windows Server 2012 and Windows Server 2012 R2
Re-Certification is required for previously certified Windows Server 2012 systems to obtain the Windows Server 2012 R2 logo.
Systems successfully certified against Windows Server 2012 R2 will earn “Down-
Level” hardware certification status for Windows Server 2012.
Run Server tests on physical hardware
Windows Server system testing must take place with the operating system directly controlling the system hardware resources.
Hypervisor or host-based virtualization solutions can't be submitted for the Windows system certification. These solutions must be tested and submitted according to the requirements of the Server Virtualization Validation Program. For more information, see the Windows Server catalog .
Rules that control server system testing and retesting
A Windows Server–based system is tested at the fastest (preferred) or maximum configuration of the components of the system, and must be retested whenever a significant change occurs in one of the fundamental components of the system.
Those fundamental components are the processors, memory, chipset, BIOS or UEFI, and I/O.
Some changes may be made to a server system without triggering a new submission.
New device driver combinations (such as PCI adapters and hard disk drives) can be substituted for device driver combinations that were included in the original system at any time, without a system resubmission.
The following changes are considered significant changes and require the modified server system to be retested and resubmitted with a new system name and model number.
Processor
Change in architecture or CPU manufacturer.
Change in number of processor sockets.
Change in processor model.
Change in processor speed. If the only change is clock speed, the retested system may use the previous submitted name.
Note: Test the configuration of processor cores and sockets that allows the highest clock speeds of the processor or processors in the system while populating all sockets.
Memory
Change in maximum supported RAM
January 7, 2014
© 2014 Microsoft. All rights reserved.
Ошибка! Используйте вкладку "Главная" для применения Title к тексту, который должен здесь
отображаться. - 42
Architecture changes to the memory (for example, the maximum supported clock to access memory or the pin outs to that memory change from DDR2 to
DDR3)
Note: Test memory at the highest memory clock speed that is supported on the largest memory capacity configuration of the server that supports that maximum memory clock speed, regardless of the number of memory channels or DIMM slots.
Chipset
Northbridge or Southbridge change
Processor integrated component change
Architecture changes to the chipset (for example, the pin outs to that chipset change)
BIOS or UEFI
Changes to ACPI, PnP, or power management functionality. Minor BIOS changes, such as fixes to timing issues or changes to the splash screen (the screen that appears during system startup) don't require resubmission.
I/O backplane or external chassis
OEMs that want to submit systems that have multiple I/O backplane options are not required to make submissions for each option. One submission is required—specifically, the "maximum" configuration possible for the system, preferably a "hybrid" if available. Other options can be submitted as marketing names if required. All other relevant requirements must be met.
System board
Any physical changes to the motherboard of the test system, such as new traces or on-motherboard components that are not devices separately tested, examples; NIC on motherboard, HBA on motherboard, graphics chip on motherboard, etc.
Closing comments
We are extremely pleased to share the feature-based requirements, Windows HCK, and the Hardware and Desktop dashboard on the Windows Dev Center. Together, these represent a significant investment we've made in the ecosystem, and they can help you build great products.
For any questions about the content of this document, contact sysdev@microsoft.com
.
January 7, 2014
© 2014 Microsoft. All rights reserved.
