- Entaonline.com
advertisement
Windows 7 and Windows Server 2008 R2
Application Quality Cookbook:
A Developer's Guide to Application Compatibility,
Reliability, and Performance
Version 1.7
March 20, 2010
This document familiarizes Application
Developers with how to verify the compatibility
of their applications with the new operating
system and provides an overview of the few
known application compatibility issues in
Windows 7 and Windows Server 2008 R2. It also
points out differences in performance, reliability,
and usability, and provides links to detailed
white papers and other developer guidance.
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Table of Contents
Introduction ............................................................................................................................................................................... 5
Compatibility ............................................................................................................................................................................. 7
General Compatibility ............................................................................................................................... 7
Operating System Versioning................................................................................................................ 9
Removal of Windows Mail .................................................................................................................. 11
Removal of Windows Movie Maker.................................................................................................... 13
NLS Sorting Changes ........................................................................................................................... 14
Internet Explorer 8 - User Agent String............................................................................................... 17
Additional Windows Resource Protection on Registry Keys ............................................................... 19
Removal of Microsoft Agent ............................................................................................................... 21
AppInit_DLLs in Windows 7 and Windows Server 2008 R2 ................................................................ 22
Removal of Windows Registry Reflection ........................................................................................... 24
Removal of WPDUSB.SYS Driver for Windows Portable Devices........................................................ 26
Microsoft Message Queuing (MSMQ) - SHA-2 Is the Default Hash Algorithm ................................... 28
Windows Server 2008 R2 Compatibility ................................................................................................. 31
File Replication Service (FRS) Is Deprecated in Windows Server 2008 R2.......................................... 32
Microsoft Message Queuing (MSMQ) - Removal of Windows 2000 Client Support Service ............. 33
New Low-Level Binaries ...................................................................................................................... 34
Removal of UDDI Services from Server OS ......................................................................................... 35
64-Bit Only .......................................................................................................................................... 37
WoW64 Is Now an Optional Feature for Server Core ......................................................................... 39
Subset of .NET 2.0 Now on Server Core .............................................................................................. 40
.NET 3.0 and 3.5 Now on Server Core ................................................................................................. 41
New Features and Enhancements .................................................................................................................................. 42
File Library Replaces Document Folder............................................................................................... 43
User Interface - High DPI Awareness .................................................................................................. 45
Fault Tolerant Heap ............................................................................................................................ 47
Internet Explorer 8 - Data Execution Protection/NX .......................................................................... 48
User Interface - User Account Control Dialog Updates ...................................................................... 50
ChooseFont() Win32 Common Dialog ................................................................................................ 51
Application Manifest ........................................................................................................................... 53
Server Hyper-V .................................................................................................................................... 56
Microsoft Message Queuing (MSMQ) - Improved Queue Handling................................................... 58
Remote Desktop Services ................................................................................................................... 59
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 3 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Tools, Best Practices, and Guidance ............................................................................................................................... 61
Application Compatibility Toolkit (ACT) 5.5 ........................................................................................ 62
Compatibility Administrator ............................................................................................................... 63
Standard User Analyzer (SUA) Tool and Standard User Analyzer Wizard (SUA Wizard) .................... 64
Application Verifier ............................................................................................................................. 66
Best Practices for On/Off Performance .............................................................................................. 70
Preventing Memory Leaks in Windows Applications.......................................................................... 72
Preventing Hangs in Windows Applications ....................................................................................... 75
Deployment Image Servicing and Management (DISM)..................................................................... 83
Windows Troubleshooting .................................................................................................................. 84
Windows Error Reporting Problem Steps Recorder ........................................................................... 85
Best Practices for Energy Efficiency .................................................................................................... 86
Best Practices for Minimizing Unresponsive Services......................................................................... 89
Windows 7 Client Software Logo Program ......................................................................................... 90
Windows Server 2008 R2 Logo Program for Software ....................................................................... 92
Page 4 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Introduction
Windows® 7 and Windows Server® 2008 R2 introduce the latest operating system technology and
software development platform for use by application developers and enterprises worldwide. As part of
further enhancing the security, reliability, performance, and user experience of Windows, Microsoft has
introduced many new features, improved existing features, and removed others.
While Windows 7 and Windows Server 2008 R2 are highly compatible with most of their respective
applications written for Windows XP, Windows Server 2003, Windows Vista®, Windows Server 2008,
Windows Server 2008 R2 and their service packs, some compatibility breaks are inevitable due to
innovations, security tightening, and increased reliability. Overall, the compatibility of Windows 7 and
Windows Server 2008 R2 with existing applications is high.
This document builds on the concepts embodied in the Windows Vista and Windows Server 2008
Application Compatibility Cookbook (http://msdn.microsoft.com/en-us/library/bb757005.aspx). Like it,
this document provides you with the means to become familiar with how to verify the compatibility of
your applications with the new operating system and provides an overview of the few known
application incompatibility issues in Windows 7 and Windows Server 2008 R2. More than that, it also
points out differences in performance, reliability, and usability, and provides links to detailed white
papers and other developer guidance.
In addition, Microsoft is investing in several new and enhanced features and tools to enable you to build
higher quality applications and to troubleshoot when applications do not function properly on
Windows 7 and Windows Server 2008 R2. Included among these tools are instructions for how to qualify
your client and server applications for participating in the Windows Logo Program.
This Cookbook contains more than three dozen topics divided into three major sections:
Compatibility (both General and Server-specific)
New Features and Enhancements
Tools, Best Practices, and Guidance
We invite you to check out these topics to learn how to optimize your application to take advantage of
what Windows 7 has to offer
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 5 of 93
Compatibility
This section of the document describes those changes in the operating system that you should pay
special attention to due to the potential impacts on existing applications and how new applications
should be designed. Compatibility contains two subsections: General Compatibility and Windows
Server 2008 R2 Compatibility.
General Compatibility
General Compatibility contains topics that could have impacts on clients or on both clients and servers.
Below is the list of topics covered in this section:
Operating System Versioning
Removal of Windows Mail
Removal of Windows Movie Maker
NLS Sorting Changes
Internet Explorer 8 - User Agent String
Additional Windows Resource Protection on Registry Keys
Removal of Microsoft Agent
AppInit_DLLs in Windows 7 and Windows Server 2008 R2
Removal of Windows Registry Reflection
Removal of WPDUSB.SYS Driver for Windows Portable Devices
Microsoft Message Queuing (MSMQ) - SHA-2 Is the Default Hash Algorithm
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 7 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Page 8 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Operating System Versioning
Affected Platforms
Clients - Windows 7
Servers - Windows Server 2008 R2
Feature Impact
Severity - High
Frequency - High
Description
The internal version number for Windows 7 and Windows Server 2008 R2 is 6.1. The GetVersion
function will now return this version number to applications when queried. This is especially important
for AntiVirus, backup, utility applications, and copy protection.
Manifestation of Impact
The manifestation of this change is application-specific. This means that any application that specifically
checks for the operating system version will get a higher version number, which can lead to one or more
of the following situations:
Installers might be unable to install the application, and applications might be unable to start
Applications might become unstable or crash
Applications might generate error messages, but continue to function properly
Mitigation
Most applications will function properly on Windows 7 and Windows Server 2008 R2 because the
application compatibility in Windows 7 and Windows Server 2008 R2 is very high. However, Windows 7
and Windows Server 2008 R2 include a Compatibility View for installers and applications that check for
operating system version.
To enable the compatibility view, users can right-click the shortcut or the executable file, and then apply
the Windows XP SP2 or Windows Vista Compatibility View from the Compatibility tab. In most cases, this
should enable the application to operate properly without the need for any changes to the application.
IT Professionals can also apply any of the applicable VersionLie compatibility fixes, by using the
Compatibility Administrator tool, which installs with the Application Compatibility Toolkit (ACT). For
example, if an application fails to function because it is checking for, but not finding, the Windows XP®
with Service Pack 2 (SP2) version information, the WinXPSP2VersionLie can be applied to return the
proper version number information to the application, regardless of the actual operating system version
that is running on the computer. The available VersionLie compatibility fixes are:
Win95VersionLie
Win2000SP2VersionLie
VistaRTMVersionLie
Win98VersionLie
Win2000SP3VersionLie
VistaSP1VersionLie
WinNT4SP5VersionLie
WinXPVersionLie
VistaSP2VersionLie
Win2000VersionLie
WinXPSP1VersionLie
Win2K3RTMVersionLie
Win2000SP1VersionLie
WinXPSP2VersionLie
Win2K3SP1VersionLie
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 9 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Solution
Generally, applications should not perform operating system version checks. If an application needs a
specific feature, it is preferable to try to find the feature, and fail only if the needed feature is missing. At
a minimum, applications should always accept version numbers greater than or equal to the lowest
supported version of the operating system. Exceptions should occur only if there is a specific legal,
business, or system-component requirement.
Links to Other Resources
Application Compatibility Toolkit Download:
http://www.microsoft.com/downloads/details.aspx?FamilyId=24DA89E9-B581-47B0-B45E492DD6DA2971
Known Compatibility Fixes, Compatibility Modes, and AppHelp Messages:
http://technet.microsoft.com/en-us/library/cc765984.aspx
Page 10 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Removal of Windows Mail
Affected Platforms
Clients - Windows 7
Servers - Windows Server 2008 R2
Feature Impact
Severity - High
Frequency - High
Description
Microsoft is deprecating the Windows Mail utility and disabling the API CoStartOutlookExpress. The
other mail APIs have been marked as deprecated and are slated for removal in a later Windows version.
However, the publicly documented APIs that are not marked as deprecated or obsolete will continue to
function in Windows 7. Binaries will remain on the users' systems and will continue to be accessible via
the APIs, specifically in the cases mentioned above. In addition, the users' e-mail (.eml) and news (.nws)
files will remain on the system.
Manifestation of Impact
Removal of Windows Mail results in the following:
All entry points to Windows Mail and Contacts (for example, Start Menu, user-created Shortcuts,
Start -> Run, etc.) are removed or disabled. Some of these are removed completely, others will
fail when trying to launch.
All DLLs ship in the box
Publicly documented APIs continue to work as they did in Windows Vista
Any APIs that attempt to launch the main browser UI have been modified to create a silent
failure. The function will return success, but will not show the UI to the user. APIs that call other
dialog boxes (for example, the Spooler or the Accounts dialog) continue to show that UI
Protocol (mailto, ldap, news, snews, nntp) handlers will not be associated with Windows Mail or
Contacts. When attempting to launch these, customers will see an error dialog pointing them to
the location where they can set these associations to another program.
File associations (.eml, .nws, .contact, .group, .wab, .p7c, .vfc) are broken or disabled. When
attempting to open a file with these extensions, customers will get a dialog box offering them
other apps that are installed that they can use and point them to a Web page that offers
solutions.
Any user files (for example, contact files or messages) remain on the system in the upgrade
scenario
The Contacts folder is hidden by default so customers will not see it
APIs are marked as deprecated in MSDN
The file preview function is removed
Shell hooks in the right click menu are removed
The file search function is removed
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 11 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Mitigation
Users should install Windows Live Mail or any other mail product that is able to read .eml and .nws files.
Solution
Detect if there is a default mail handler installed. If not, advise user to install Windows Live Mail or any
other product that is able to read .eml and .nws files.
Do not design code that calls the Windows Mail UI API, since it will not work. You must find other ways
to access the .eml and .nws files. In addition, as soon as is feasible, discontinue your reliance on all other
Windows Mail APIs.
Compatibility, Performance, Reliability, and Usability Testing
Exercise your application in a Windows 7 environment to ensure that the application does not try to
call the UI API.
Alternatively, you can run the Application Compatibility Toolkit (ACT) using the Windows
Compatibility Evaluator (WCE) to locate any potential issues due to the deprecation of this
functionality.
Links to Other Resources
Application Compatibility Toolkit Download:
http://www.microsoft.com/downloads/details.aspx?FamilyId=24DA89E9-B581-47B0-B45E492DD6DA2971
Page 12 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Removal of Windows Movie Maker
Affected Platforms
Clients - Windows 7
Servers - Windows Server 2008 R2
Feature Impact
Severity - High
Frequency - Medium
Description
Microsoft is deprecating and removing the Windows Movie Maker utility. This includes:
All entry points to Windows Movie Maker (for example, Start Menu, Start > Run)
All binaries that were used by Windows Movie Maker (everything that was in
%ProgramFiles%\Movie Maker)
However, a user's Movie Maker project files will remain on the system and be accessible to other
applications that support this file format.
Manifestation
Remove of Windows Movie Maker results in the following:
Any attempt to launch Windows Movie Maker with its command line arguments will fail
Any plug-ins that were installed to enable new transforms and animations will remain installed
but will not be exposed to the end user
Solution
To have such functionality in the future, a user will need to install a similar application from Microsoft or
another software provider.
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 13 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
NLS Sorting Changes
Affected Platforms
Clients - Windows XP | Windows Vista | Windows 7
Servers - Windows Server 2003 | Windows Server 2008 | Windows Server 2008 R2
Feature Impact
Severity - High
Frequency - Low (Few apps impacted, but if impacted, always broken)
Description
The National Language Support (NLS) functions help applications support the different language- and
locale-specific needs of users around the world. New Windows versions almost invariably include NLS
changes. This change affects collation and sorting, and therefore applications that have persistent
indexes.
A collation table has two numbers that identify its version (revision): the defined version and the NLS
version. Both versions are DWORD values, composed of a major version and a minor version. The first
byte of a value is reserved, the next two bytes represent the major version, and the last byte represents
the minor version. In hexadecimal terms, the pattern is 0xRRMMMMmm, where R equals Reserved, M
equals major, and m equals minor. For example, a major version of 3 with a minor version of 4 is
represented as 0x304.
For a major version, one or more code points change so that the application must re-index all data for
comparisons to be valid. For a minor version, nothing moves, but code points are added. For this type of
version, the application only has to re-index strings with previously unsortable values.
In summary, here is what the version numbers mean in relation to the data changes in the locale-specific
exception tables and default tables:
NLSVersion Major – Changed code points in the 'exception,' or locale-specific tables
NLSVersion Minor – Added new code points in the 'exception,' or locale-specific tables
DefinedVersion Major – Changed code points in the default table
DefinedVersion Minor – Added new code points in the default table
Sorting version numbers for released versions:
Operating System
Release
Version (0xRRMMMMmm)
Windows XP
RTM/SP1/SP2/SP3/…
N/A - no GetNLSVersion() API
Windows Server 2003
RTM/SP1
0x00 0000 01
Windows Vista
RTM/SP1
0x00 0405 00
Windows Server 2008
RTM
0x00 0501 00 / 0x00 5001 00
Windows 7
Beta
0x00060000
Page 14 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Manifestation
Applications (such as databases) with persistent indexes that do not check the NLS version and re-index
upon version change will fail to sort correctly or may fail to provide requested results.
In the case of user interfaces, lists (for example, alphabetical, numeric, alphanumeric, symbols, etc.) may
sort incorrectly.
Solution
Your application can call either GetNLSVersionEx (Windows Vista or later) or GetNLSVersion (prior to
Windows Vista) to retrieve both the defined version and the NLS version for a collation table.
GetNLSVersionEx:
Retrieves information about the current version of a specified NLS capability for a locale specified
by name
This function allows an application such as Active Directory to determine whether an NLS change
affects the locale used for a particular index table. If it does not, there is no need to re-index the
table. For more information, see Handling Locale and Language Information.
This function supports custom locales. If lpLocaleName specifies a supplemental locale, the data
retrieved is the correct data for the collation order associated with that supplemental locale.
Note: Versions of Windows prior to Windows Vista do not support GetNLSVersionEx.
GetNLSVersion (use for applications running on versions of Windows prior to Windows Vista):
Retrieves information about the current version of a specified NLS capability for a locale specified
by identifier
This function allows an application such as Active Directory to determine if an NLS change affects
the locale identifier used for a particular index table. If it does not, there is no need to re-index
the table. For more information, see Handling Locale and Language Information.
Note: This function retrieves information only about a locale specified by identifier. The
GetNLSVersionEx function supports additional locales, features, and RFC 4646 names. However,
versions of Windows prior to Windows Vista do not support GetNLSVersionEx.
Applications meant to run only on Windows Vista and later should use GetNLSVersionEx in
preference to this function. GetNLSVersionEx provides good support for supplemental locales.
Compatibility Test
Steps to tell if a collation version changed (that is, you need to re-index):
Use GetNLSVersionEx() to retrieve an NLSVERSIONINFOEX structure when doing the original
indexing of your data.
Store the following properties with your index to identify the version:
NLSVERSIONINFOEX.dwNLSVersion and NLSVERSIONINFOEX.dwDefinedVersion – These two
properties together specify the version of the sorting table you are using.
NLSVERSIONINFOEX.dwEffectiveId - This specifies the effective locale of your sort. A custom locale
will point to an in-box locale's sort.
When using the index use GetNlsVersionEx() to discover the version of your data.
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 15 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
If any of the three properties has changed, the sorting data you are using could return different
results and any indexing you have may fail to find records.
If you KNOW that your data doesn't contain invalid Unicode code points (that is, all of your
strings returned TRUE from a call to IsNLSDefinedString()), then you may consider them the same
if ONLY the low byte of dwNLSVersion and dwDefinedVersion changed (the minor versions
described above).
Links to Other Resources
Working with collation: http://msdn.microsoft.com/en-us/library/ms776402(VS.85).aspx
GetNLSVersionEx: http://msdn.microsoft.com/en-us/library/ms776366(VS.85).aspx
GetNLSVersion: http://msdn.microsoft.com/en-us/library/ms776287(VS.85).aspx
How to tell if the collation version changed:
http://blogs.msdn.com/shawnste/archive/2007/06/01/how-to-tell-if-the-collation-versionchanged.aspx
Handling Locale and Language Information: http://msdn.microsoft.com/enus/library/ms776274(VS.85).aspx
Page 16 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Internet Explorer 8 - User Agent String
Affected Platforms
Clients - Windows XP | Windows Vista | Windows 7
Servers - Windows Server 2003 | Windows Server 2008 | Windows Server 2008 R2
Feature Impact
Severity - Medium
Frequency - High
Description
The User Agent String is the Internet Explorer identifier that provides data about its version and other
attributes to Web servers. Many Web applications rely on, and piggyback on, the Internet Explorer User
Agent String. A change in the User Agent String impacts those applications that do so and that depend
on an earlier version number. The User Agent string now includes the string 'Trident/4.0' in order to
allow differentiation between the Internet Explorer 7 User Agent String and the Internet Explorer 8 User
Agent string when running in Internet Explorer 7 Compatibility View. See Understanding User Agent
Strings for details.
Manifestation of Impact
There are two impacted areas:
Web pages that explicitly check the User Agent String and do not support the Internet Explorer 8
User Agent String may not run properly. In the majority of cases, this means the pages will be
block users from the content they are attempting to access or display incorrect or malformed
content.
Applications that host Trident (see Hosting and Reuse) will default to Internet Explorer 7 using
the Web Optional Component, but will not have access to Internet Explorer 8 features.
Solution
Ensure that your applications properly handle the new 'MSIE 8.0' version in the User Agent String.
You may also opt in to the Internet Explorer 7 Compatibility View for those applications based on
Internet Explorer 7. This can be done with meta tags. See the discussion in Understanding User Agent
Strings for details.
Compatibility, Performance, Reliability, and Usability Testing
Run your applications and Web pages in an Internet Explorer 8 environment on Windows Vista or
Windows XP to ensure that they behave in the desired manner.
Alternatively, you can run the Internet Explorer Compatibility Test Tool (IECTT) provided with the
Application Compatibility Toolkit (ACT) to locate any potential issues due to security feature
updates.
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 17 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Links to Other Resources
Understanding User Agent Strings: http://msdn.microsoft.com/enus/library/ms537503(VS.85).aspx
The Internet Explorer 8 User-Agent String: http://blogs.msdn.com/ie/archive/2008/02/21/theinternet-explorer-8-user-agent-string.aspx
User-Agent String and Version Vector:
http://code.msdn.microsoft.com/ie8whitepapers/Release/ProjectReleases.aspx?ReleaseId=531
Hosting and Reuse: http://msdn.microsoft.com/en-us/library/aa752038(VS.85).aspx
Application Compatibility Toolkit Download:
http://www.microsoft.com/downloads/details.aspx?FamilyId=24DA89E9-B581-47B0-B45E492DD6DA2971
Known Internet Explorer Security Feature Issues: http://technet.microsoft.com/enus/library/cc722079.aspx
Page 18 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Additional Windows Resource Protection on Registry Keys
Platform
Clients - Windows 7
Servers - Windows Server 2008 R2
Feature Impact
Severity - Medium
Frequency - Low
Description
Additional system resources have added Windows Resource Protection (WRP) settings in Windows 7,
making them read-only settings. The vast majority of resources that received added protection are
system COM server keys, although some features have added targeted resource protection. Microsoft
changed these resources in order to protect the system and other applications from breaking each other
and to provide a consistent, stable platform upon which applications can reliably run. In the past,
applications could provide custom files and use the unprotected COM registration to change the system.
In the case of older applications, this can downgrade system runtimes or change the interface upon
which other applications needed to work properly. In the worst case, such installations could cause
system failure or degradation over time. To provide a better experience and a more stable application
platform, we locked down these registrations so that only Microsoft updates could change system
components.
Since most resources changed are COM keys used by the system, this change will not affect the majority
of applications. While we expect most applications to have a better experience on Windows 7 as a result
of these changes, a small subset of applications may be negatively affected. The system's application
compatibility layers will automatically resolve setup problems by always telling the application that it
succeeded in changing a setting, even if it failed due to it being a protected resource. This prevents
application setups from breaking but may cause problems if the setting needed to be changed in order
for the application to function properly.
Manifestation
Applications may have modified these settings prior to Windows 7. Upon installing on Windows 7,
applications may find certain features no longer work because the settings did not reflect what the
application expected.
There are two scenarios in which applications may encounter problems related to this added protection:
Applications that may have been using the now-protected settings as a data store or as a rare or
unintended extensibility point
In rare cases, the detection mechanism used to identify application setups may not recognize a
particular setup and so the application compatibility mitigation layer may not be applied
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 19 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Mitigation
The primary means of mitigation is the system's application compatibility layer, which is automatically
applied to application setups when detected. You can also manually apply it to any application using the
compatibility tab in the application's properties.
This layer resolves the problem by intercepting registry operations. In the case where the application
was attempting to modify a read-only (WRP) setting, the layer always returns success, even though the
setting was not really changed. For most applications, this will cause no problems. However, there is a
possibility that the application needed that setting changed in order to function properly, which is the
first scenario described above.
Solution
For the two scenarios identified above:
If the application requires the key to be writable in order to function or use the data store, there
is no solution other than changing the application so that it no longer writes to that location.
If the compatibility layer was not applied to a setup, the setup failure should be detected and
offered to be applied and re-run. Applications can also run in compatibility mode, in which case
the mitigation layer is always applied.
Compatibility Tests
How to detect if an application had WRP mitigation applied to it:
Windows Installer is aware of WRP; it automatically and silently ignores attempts to write or
modify a protected resource. If the application was installed with Windows Installer and logging
was enabled, then a warning will be logged for each registry key write operation that was
ignored due to its being a WRP-protected resource.
The WRP API incorporates SfCIsKeyProtected, which can query if a registry key is WRP-protected
on the current system. See the WRP entry in MSDN in the links below for additional information
on using this API.
Links to Other Resources
WRP Developer Reference: http://msdn.microsoft.com/en-us/library/cc185681(VS.85).aspx
Page 20 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Removal of Microsoft Agent
Platform
Clients - Windows 7
Servers - Windows Server 2008 R2
Feature Impact
Severity - Medium
Frequency - Low
Description
Microsoft has decided to discontinue development of Microsoft Agent technologies. Beginning with
Windows 7, Microsoft Agent will not be included or supported in future versions of the Microsoft
Windows operating system. We encourage Microsoft Agent application developers and redistributors to
evaluate their activities in light of this decision.
Manifestation
Microsoft will not offer new licenses or renewals
Microsoft will not update the Microsoft Agent components, including:
o The "msagent.exe" runtime and libraries
o The characters Merlin, Genie, Peedy, and Robbo
o The Agent Character Editor
o All related Microsoft Agent software, tools, and documentation
Windows 7 and later versions will not support development of Microsoft Agent applications or
characters
Mitigation of Impact
Developers can still use the following resources for previous versions of Windows:
Microsoft Agent Core Components (for use only on Microsoft Windows 95, Windows 98 and
Windows NT 4.0) - http://www.microsoft.com/downloads/details.aspx?familyid=E11BF7127862-45BA-826D-44AE3A11836F
Merlin Character File - http://www.microsoft.com/downloads/details.aspx?FamilyID=fee1dadd2f23-41d0-8a81-2affd74c0aa5
Peedy Character File - http://www.microsoft.com/downloads/details.aspx?FamilyID=bd3c465579e4-4791-ab9d-abc7bbd133ef
Genie Character File - http://www.microsoft.com/downloads/details.aspx?FamilyID=da86ba4ebc2d-4c1d-b5a0-3183fe206414
Robby Character File - http://www.microsoft.com/downloads/details.aspx?FamilyID=fa36d1d5d828-494a-ad0a-7b571db5bd2e
Links to Other Resources
Microsoft Agent Resources: http://go.microsoft.com/fwlink/?LinkId=140671
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 21 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
AppInit_DLLs in Windows 7 and Windows Server 2008 R2
Platform
Clients - Windows 7
Servers - Windows Server 2008 R2
Feature Impact
Severity - Low
Frequency - Low
Description
AppInit_DLLs is a mechanism that allows an arbitrary list of DLLs to be loaded into each user mode
process on the system. Microsoft is modifying the AppInit DLLs facility in Windows 7 and Windows
Server 2008 R2 to add a new code-signing requirement. This will help improve the system reliability and
performance, as well as improve visibility into the origin of software.
Configuration
Values stored under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
\Windows key in the registry determine the behavior of the AppInit_DLLs infrastructure. The table below
describes these registry values:
Value
Description
Sample Values
LoadAppInit_DLLs
(REG_DWORD)
Globally enables or disables
AppInit_DLLs.
0x0 – AppInit_DLLs are disabled.
0x1 – AppInit_DLLs are enabled.
AppInit_DLLs
(REG_SZ)
Space or comma delimited list of DLLs
to load. The complete path to the DLL
should be specified using Short Names.
C:\
PROGRA~1\WID288~1\MICROS~1.DLL
RequireSignedAppInit_DLLs
(REG_DWORD)
Only load code-signed DLLs.
0x0 – Load any DLLs.
0x1 – Load only code-signed DLLs.
Windows 7
All DLLs that are loaded by the AppInit_DLLs infrastructure should be code-signed. In the interests of
application compatibility, the Windows 7 Operating System will load all AppInit DLLs. However, Microsoft
recommends that all application developers code-sign their DLLs to help improve the reliability of
Windows and prepare for code-signing enforcement in future versions of Windows. The
RequireSignedAppInit_DLLs registry key controls this behavior and its value on Windows 7 is set to 0 by
default.
Windows Server 2008 R2
All DLLs that are loaded by the AppInit_DLLs infrastructure must be code-signed. The
RequireSignedAppInit_DLLs registry key controls this behavior and its value on Windows Server 2008 R2
is set to 1 by default.
Page 22 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Links to Other Resources
Additional Information: http://www.microsoft.com/whdc/driver/install/AppInit-Win7.mspx
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 23 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Removal of Windows Registry Reflection
Platform
Clients - Windows 7
Servers - Windows Server 2008 R2
Feature Impact
Severity - Low
Frequency - Low
Description
The registry reflection process copies registry keys and values between two registry views to keep them
in synch. In previous 64-bit installations of Windows, the process reflected a subset of the redirected
registry keys between the 32-bit and 64-bit views. However, the implementation of this caused some
inconsistencies in the state of the registry. (For details on Registry Reflection, please refer to the
corresponding MSDN article in the Links to Other Resources section below.)
Starting with Windows 7, we have removed registry reflection completely and merged the keys that used
to be reflected:
HKEY_LOCAL_MACHINE\Software\Classes
HKEY_LOCAL_MACHINE\Software\Microsoft\COM3
HKEY_LOCAL_MACHINE\Software\Microsoft\EventSystem
HKEY_LOCAL_MACHINE\Software\Microsoft\Ole
HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc
HKEY_USERS\*\Software\Classes
HKEY_USERS\*_Classes
Effectively, this provides the same reflection behavior, since changes to these keys are immediately
available for both 32-bit and 64-bit applications.
The keys that were reflected conditionally remain split:
HKEY_LOCAL_MACHINE\Software\Classes\CLSID
HKEY_LOCAL_MACHINE\Software\Classes\Interface
HKEY_USERS\*\Software\Classes\CLSID
HKEY_USERS\*\Software\Classes\Interface
HKEY_USERS\*_Classes\CLSID
HKEY_USERS\*_Classes\Interface
They are used to keep the data that should not be shared between 32-bit and 64-bit applications.
Windows 7 Manifestation
CLSID and Interface keys from the list above are not reflected anymore while they are still redirected.
While this is the desired behavior in most of cases, it is possible that applications could take a
dependency on their reflected behavior in Vista.
Page 24 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
The functions allowing applications to control reflection (RegDisableReflectionKey and
RegEnableReflectionKey) are no-ops in Windows 7.
Mitigation of Impact
COM is the major consumer of registry reflection. COM and other consumers were updated to
accommodate this change. This change does not affect applications that use standard COM APIs.
Solution
Apply one of the following options if you are relying on registry reflection to synchronize 32bit and 64bit
views:
Create keys in both views explicitly during installation
Move the keys out of the scope of reflected keys
Check both views of the registry when querying for a reflected key
Note: KEY_WOW64_32KEY and KEY_WOW64_64KEY flags cannot be combined
Apply one of the following options if you are relying on RegDisableReflectionKey functions to disable
registry reflection:
Create keys in both views explicitly during installation
Move the keys out of the scope of reflected keys
Use platform-specific subkeys (like x86, amd64 and ia64) to separate bitness-specific data
Links to Other Resources
Registry Reflection article - http://msdn.microsoft.com/en-us/library/aa384235(VS.85).aspx
Redirected keys list within Registry Redirector article - http://msdn.microsoft.com/enus/library/aa384232(VS.85).aspx
Best Practices for Wow64 http://www.microsoft.com/whdc/system/platform/64bit/WoW64_bestprac.mspx
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 25 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Removal of WPDUSB.SYS Driver for Windows Portable Devices
Affected Platforms
Clients - Windows 7
Servers - Windows Server 2008 R2
Feature Impact
Severity - Low
Frequency - Low
Description
Microsoft has replaced the kernel mode component of the Windows Vista USB driver stack
(WPDUSB.SYS) for Windows Portable Devices (WPD) with the generic WINUSB.SYS driver.
Communication with the original WPDUSB.SYS driver was via private I/O Control (IOCTL) codes; we have
also removed support of these.
Any consumer of these IOCTL codes would have been responsible for proper interpretation and
implementation of the Media Transfer Protocol (MTP). Windows Vista did not support use of these
IOCTL codes by third-party applications.
Manifestation of Impact
Any application that depended on the availability of these private IOCTL codes would no longer have
access to USB-connected MTP devices.
Mitigation
Users of an application that depends on the private IOCTL codes must use a different application (or an
updated version of the application) to access the USB-connected MTP device.
Solution
Applications should use the Windows Portable Devices (WPD) API to find and interact with any WPD
Device. Although a significant percentage of WPD devices implement MTP for communication with the
PC, WPD is not limited to just MTP devices. In addition, where direct access to the device via the private
IOCTLs would have limited the application to communication with only USB-connected devices, use of
the WPD API expands the list of connectivity options to other communication protocols (for example,
Wi-Fi). In the rare cases when the application must be MTP-aware, the WPD API provides a pass-through
mechanism for raw MTP commands.
Leveraging Feature Capabilities
The WPD API is supported in Windows XP (via the Windows Format SDK), Windows Vista and
Windows 7. The Windows 7 implementation of WPD adds support for MTP over Bluetooth.
Page 26 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Links to Other Resources
Windows Portable Devices: http://msdn.microsoft.com/en-us/library/ms740786(VS.85).aspx
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 27 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Microsoft Message Queuing (MSMQ) - SHA-2 Is the Default Hash Algorithm
Affected Platforms
Clients - Windows XP | Windows Vista | Windows 7
Servers - Windows Server 2003 | Windows Server 2008 | Windows Server 2008 R2
Feature Impact
Severity - Low
Frequency - Low
Description
In Windows 7, MSMQ uses SHA-2 as the default when signing an outgoing message. Additionally, SHA-2
signatures are required for all incoming messages. You can enable support for a lower encryption
algorithm through an administrator-accessible registry key.
Manifestation of Impact
MSMQ in Windows 2003 or below will not accept signed messages originating from MSMQ in
Windows 7.
MSMQ in Windows 7 will not accept signed messages originating from Windows 2008 or below.
Mitigation
Users should consider upgrading to Windows 7 to leverage the stronger signing algorithm.
To enable seamless signed message exchange between Windows 7 and any down-level operating
system, the Administrator must add appropriate exceptions on the MSMQ machines.
Page 28 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 29 of 93
Windows Server 2008 R2 Compatibility
This section contains topics specific to Windows Server 2008 R2. Below is the list of topics covered in this
section:
File Replication Service (FRS) Is Deprecated in Windows Server 2008 R2
Microsoft Message Queuing (MSMQ) - Removal of Windows 2000 Client Support Service
New Low-Level Binaries
Removal of UDDI Services from Server OS
64-Bit Only
WoW64 Is Now an Optional Feature for Server Core
Subset of .NET 2.0 Now on Server Core
.NET 3.0 and 3.5 Now on Server Core
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 31 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
File Replication Service (FRS) Is Deprecated in Windows Server 2008 R2
Platform
Servers - Windows Server 2008 R2
Feature Impact
Severity - High
Frequency - High
Description
In Windows Server 2008 R2, File Replication Service (FRS) cannot be used for replicating Distributed File
System (DFS) folders or custom (non-SYSVOL) data. A Windows Server 2008 R2 domain controller can
still use FRS to replicate the contents of the SYSVOL share in a domain that uses FRS for replicating the
SYSVOL share between domain controllers. However, Windows Server 2008 R2 servers cannot use FRS to
replicate the contents of any replica set apart from the SYSVOL share. The DFS Replication service is a
replacement for FRS and can be used to replicate the contents of the SYSVOL share, DFS folders as well
as other custom (non-SYSVOL) data. Migrate all non-SYSVOL FRS replica sets to DFS Replication. We also
highly recommend that you migrate replication of the SYSVOL share from FRS to DFS Replication because
DFS Replication is more robust, scalable and has better replication performance than FRS.
Manifestation
FRS replication of custom data will break irreversibly upon in-place upgrade. The only way to recover
from this situation would be to reinstall an older operating system on the server and reinitialize FRS
replication. Servers that have been upgraded to Windows Server 2008 R2 are not allowed to participate
in existing FRS replication groups.
Mitigation of Impact
To prevent issues that might occur as a result of these changes, migrate custom FRS replication sets to
DFS Replication. The DFS Replication service has many benefits over FRS, including improved
management tools, higher performance, and delegated management.
Links to Other Resources
FRS Overview: http://technet.microsoft.com/en-us/library/cc754297.aspx
Distributed File System Replication: Frequently Asked Questions:
http://technet.microsoft.com/en-us/library/cc773238(WS.10).aspx#BKMK_035)
SYSVOL Replication Migration Guide: FRS to DFS Replication: http://technet.microsoft.com/enus/library/dd640019(WS.10).aspx
Page 32 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Microsoft Message Queuing (MSMQ) - Removal of Windows 2000 Client Support
Service
Platform
Servers - Windows Server 2008 R2
Feature Impact
Severity - High
Frequency - Low
Description
The Windows 2000 Client Support Service is an optional component of the Message Queuing Server that
you can install on a Windows 2003 or Windows 2008 domain controller machine. This service allows
Windows 2000 clients to operate in a domain-integrated mode with any Message Queuing server
installed on Windows 2003/2008 machines. MSMQ Clients operating on Windows XP upwards do not
need this service.
Manifestation of Impact
This change impacts Windows 2000 when interoperating in a Windows 7 domain where all domain
controllers are Windows Server 2008 R2. If a customer upgrades to the Windows 7 domain, the existing
MSMQ applications on any Windows 2000 machines in the domain will not be able to operate in a
domain-integrated mode unless these clients upgrade to a higher Windows version.
Mitigation
Users who have Windows 2000 Client machines on a Windows 7 domain can configure a Windows
2003/2008 domain controller in the domain and install the MSMQ Windows 2000 Client Support Service
on this domain controller.
Leveraging Feature Capabilities
Users who have Windows 2000 Client machines running MSMQ should upgrade to a higher Windows
version in order to take advantage of the Active Directory-based implementation of the MSMQ Server.
Compatibility, Performance, Reliability, and Usability Testing
Users who have Windows 2000 Client machines running MSMQ on a Windows 7 domain with one or
more down-level domain controllers should verify that their applications are functional on this mixed
domain.
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 33 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
New Low-Level Binaries
Affected Platforms
Clients - Windows 7
Servers - Windows Server 2008 R2
Feature Impact
Severity - Medium
Frequency - High
Description
To improve internal engineering efficiencies and improve foundations for future work, we have
relocated some functionality to new low-level binaries. This refactoring will make it possible for future
installs of Windows to provide subsets of functionality to reduce surface area (disk and memory
requirements, servicing, and attack surface).
Manifestation of Impact
As an example of functionality that we moved to low-level binaries, kernelbase.dll gets functionality
from kernel32.dll and advapi32.dll. This means that the existing binary now forwards calls down to the
new binary rather than handling them directly; the forwarding can be static (the export table shows the
redirection), or runtime (the dll has a stub routine that calls down to the new binary). This will affect
low-level applications such as security and backup applications that are dependent upon internal APIs
and offsets.
Solution
The only impact is to code that makes assumptions when attempting to look at the kernel32.dll or the
advapi32.dll export table in memory, such as an anti-virus application might do.
Use published APIs and not the details of their implementation. This is just one example of implementing
around a detail of implementation for an API.
Page 34 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Removal of UDDI Services from Server OS
Affected Platform
Servers - Windows Server 2008 R2
Feature Impact
Severity - Medium
Frequency - Low
Description
Microsoft has removed the UDDI (Universal Description, Discovery, and Integration) Services server role
from Windows Server 2008 R2. Future releases of UDDI Services will be part of the Microsoft BizTalk
product. This product realignment and consolidation positions Microsoft to better serve the servicesoriented architecture (SOA) market.
The first post-Windows Server 2008 release of UDDI Services will be UDDI v3.0 standards compliant. It
will ship as part of the BizTalk Server 2009 release. To meet our commitment to provide a satisfactory
user experience, we will offer a UDDI Services v3 installation package for Windows Server 2008 R2.
Manifestation
The presence of previous versions of UDDI Services components on the system blocks an upgrade to
Windows Server 2008 R2.
Mitigation of Impact
Users who have deployed a UDDI Services site from Windows Server 2003 or Windows Server 2008 can
choose not to upgrade the servers running the UDDI Services to Windows Server 2008 R2. They can also
move the UDDI Services to dedicated Windows Server 2003 or Windows Server 2008 boxes if they have
to upgrade the current UDDI Services boxes.
Solution
The recommended solution is to deploy UDDI Services v3.0 from BizTalk Server 2009 onto a Windows
Server 2008 R2 machine, and then to migrate the old site to the new site. UDDI Services v3.0 provides
backward compatibility with UDDI Services 2.0, so any applications that are using UDDI Services will be
unaffected.
To do this, follow these steps:
1. Set up a new UDDI Services v3.0 site on a machine already loaded with Windows Server 2008 R2.
(Note: In a distributed setup, a UDDI v3.0 site can consist of more than one Windows
Server 2008 R2 machines.)
2. Use the UDDI data migration tool to migrate the data from the old UDDI Services database to the
new database.
3. Back up the old UDDI Services database to ensure rollback capability.
4. Uninstall the old UDDI Services software and then upgrade those boxes to Windows Server 2008
R2.
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 35 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Links to Other Resources
Microsoft UDDI Services Web site: http://go.microsoft.com/fwlink/?LinkID=129130
UDDI specifications: http://uddi.xml.org/specification
UDDI Services v3.0 download for Windows Server 2008 R2:
http://go.microsoft.com/fwlink/?LinkID=137770
Page 36 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
64-Bit Only
Affected Platforms
Servers - Windows Server 2008 R2
Feature Impact
Severity - Low
Frequency - High
Description
Windows Server 2008 R2 ships with a 64-bit SKU only; no 32-bit SKU is available for the server version of
the operating system. However, a 32-bit SKU continues to be available for the Windows 7 client.
Manifestation of Impact
This will impact three areas:
32-bit drivers
32-bit plug-ins
16-bit executables
Solution for 32-bit Drivers
Recompile 32-bit drivers as signed 64-bit drivers.
Solution for 32-bit Plug-ins
WoW64, an x86 emulator, allows 32-bit Windows-based applications to run seamlessly on 64-bit
Windows. WoW64 is now an optional feature that you must install if it is necessary to run 32-bit code.
The system isolates 32-bit applications from 64-bit applications, which includes preventing file and
registry collisions. It supports console, GUI, and service applications. The system provides
interoperability across the 32/64 boundary for scenarios such as cut and paste and COM. However, 32bit processes cannot load 64-bit DLLs, and 64-bit processes cannot load 32-bit DLLs. We commonly see
this in shell plug-ins written for Windows Explorer.
A 32-bit application can detect whether it is running under WOW64 by calling the IsWow64Process
function. The application can obtain additional information about the processor by using the
GetNativeSystemInfo function
Note that 64-bit Windows does not support running 16-bit Windows-based applications. The primary
reason is that handles have 32 significant bits on 64-bit Windows. Therefore, handles cannot be
truncated and passed to 16-bit applications without loss of data. Attempts to launch 16-bit applications
fail with the following error: ERROR_BAD_EXE_FORMAT.
Solution for 16-bit Executables
64-bit Windows recognizes a limited number of specific 16-bit installer programs and substitutes a
ported 32-bit version. The list of substitutions is stored in the registry under the following key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\NtVdm64
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 37 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
There is built-in support for several installer engines, including InstallShield 5.x installers.
Note that the 64-bit Windows Installer can seamlessly install 32-bit MSI-based applications on 64-bit
Windows.
Links to Other Resources
Running 32-bit Applications: http://msdn.microsoft.com/en-us/library/aa384249(VS.85).aspx
Performance and Memory Consumption: http://msdn.microsoft.com/enus/library/aa384219(VS.85).aspx
WoW64 Implementation Details: http://msdn.microsoft.com/enus/library/aa384274(VS.85).aspx
Registry Redirector: http://msdn.microsoft.com/en-us/library/aa384232(VS.85).aspx
File System Redirector: http://msdn.microsoft.com/en-us/library/aa384187(VS.85).aspx
Memory Management: http://msdn.microsoft.com/en-us/library/aa384209(VS.85).aspx
Processor Affinity: http://msdn.microsoft.com/en-us/library/aa384228(VS.85).aspx
Interprocess Communication: http://msdn.microsoft.com/en-us/library/aa384203(VS.85).aspx
Application Installation: http://msdn.microsoft.com/en-us/library/aa384143(VS.85).aspx
Debugging WoW64: http://msdn.microsoft.com/en-us/library/aa384163(VS.85).aspx
Is WoW64 Process Running: http://msdn.microsoft.com/en-us/library/ms684139(VS.85).aspx
Get Native System Info: http://msdn.microsoft.com/en-us/library/ms724340(VS.85).aspx
Page 38 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
WoW64 Is Now an Optional Feature for Server Core
Platform
Servers - Windows Server 2008 R2
Feature Impact
Severity - Low
Frequency - Low
Description
The Server Core installation option for Windows Server 2008 R2 allows you to uninstall WoW64.
WoW64 is now an optional feature that you can uninstall if it is not necessary to run 32-bit code.
In addition, the Active Directory and Active Directory Lightweight Directory Services roles require
WoW64 in order to run in Windows Server 2008 R2.
Manifestation of Impact
If you uninstall WoW64, Administrators running 32-bit code on Server Core will receive an error
message that the application cannot be executed. If Administrators attempt to run Active Directory and
Active Directory Lightweight Directory Services, they will receive an error message.
Mitigation
Install WoW64.
Solution
The preferred solution is to provide a 64-bit version of the code to enable it to run on Server Core
without needing WoW64.
At a minimum, provide user documentation noting that to run 32-bit code they must install WoW64.
Compatibility, Performance, Reliability, and Usability Testing
Verify that all code used is 64-bit.
Links to Other Resources
WoW64 Implementation Details: http://msdn.microsoft.com/enus/library/aa384274(VS.85).aspx
Debugging WoW64: http://msdn.microsoft.com/en-us/library/aa384163(VS.85).aspx
Server Core: http://msdn.microsoft.com/en-us/library/ms723891(VS.85).aspx
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 39 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Subset of .NET 2.0 Now on Server Core
Platform
Servers - Windows Server 2008 R2
Feature Impact
Severity - Low
Frequency - Low
Description
The Server Core installation option for Windows Server 2008 R2 now includes a subset of the .Net
Framework 2.0. The subset is the functionality in .NET 2.0 that aligns with the functionality in Server
Core; no binaries were added to the Server Core base to allow any portion of .NET 2.0 to function.
There was no .NET support in the Server Core installation option for Windows Server 2008.
Manifestation of Impact
This allows some .NET 2.0 based-applications to run on Server Core in Windows Server 2008 R2.
Testing
Verify that the .NET classes your code uses is included in Server Core. Also test any applications that run
this code on Server Core.
Links to Other Resources
Server Core: http://msdn.microsoft.com/en-us/library/ms723891(VS.85).aspx
Server Core Blog: http://blogs.technet.com/server_core/archive/2008/11/25/net-2-0-andserver-core-in-windows-server-2008-r2.aspx
See also the Server Core section of the Windows Server 2008 R2 SDK when it becomes available
Page 40 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
.NET 3.0 and 3.5 Now on Server Core
Platform
Server - Windows Server 2008 R2
Feature Impact
Severity - Low
Frequency - Low
Brief Description
The Server Core installation option for Windows Server 2008 R2 now includes a subset of the .NET
Framework 3.0 and 3.5, specifically WCF, WF, and LINQ.
There was no .NET support in the Server Core installation option for Windows Server 2008.
Manifestation of Impact
This allows some WCF and WF based applications as well as applications that use LINQ to run on Server
Core in Windows Server 2008 R2.
Testing
Test applications that incorporate WCF, WF, and LINQ code on Server Core.
Links to Other Resources
Server Core: http://msdn.microsoft.com/en-us/library/ms723891(VS.85).aspx
See the Server Core sections of the Windows 7 2008 R2 Step-by-Step Guides when they become
available
See the Server Core section of the Windows Server 2008 R2 SDK when it becomes available
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 41 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
New Features and Enhancements
Windows 7 and Windows Server 2008 R2 include many enhancements to improve both the users' and
the developers' experience. A few of them, however, have impacts that developers need to be aware of
regarding their existing and new products. Below is the list of new features and enhancements:
File Library Replaces Document Folder
User Interface - High DPI Awareness
Fault Tolerant Heap
Internet Explorer 8 - Data Execution Protection/NX
User Interface - User Account Control Dialog Updates
ChooseFont() Win32 Common Dialog
Application Manifest
Server Hyper-V
Microsoft Message Queuing (MSMQ) - Improved Queue Handling
Remote Desktop Services
Page 42 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
File Library Replaces Document Folder
Affected Platforms
Clients - Windows 7
Servers - Windows Server 2008 R2
Feature Impact
Severity - Medium
Frequency - High
Description
Libraries provide a centralized folder-like experience for file storage, search, and access across multiple
locations, both local and remote.
The default locations used by common file dialogs (for example, Open, and Save) have been changed
from the Document Folder to the Documents Library. The User Interface is unchanged, but the user will
now be able to view, browse, and search the Library using various arrangement views. Files are saved
into the Library default save location unless the user changes the default save location or chooses a
different folder.
Developers could create their own libraries or add locations to existing libraries using the IShellLibrary
interface. Users can find libraries by using the Known Folder system (for example,
FOLDERID_DocumentsLibrary).
Manifestation of Impact
The Library is itself a file, and not a folder. Therefore, path manipulations could result errors due to the
attempt by the application to concatenate files to files.
Solution
When using IFileDialog, you must use GetResult method in conjunction with the shell APIs instead of
manipulating the folder path directly.
Leveraging Feature Capabilities
If you want to create your own libraries or add locations to existing libraries, you must use IShellLibrary
API. Libraries are themselves Shell Folders so you can enumerate them just like any other Shell Folder.
Compatibility, Performance, Reliability, and Usability Testing
Using the common file dialog will ensure that users can save directly to their libraries.
Links to Other Resources
Windows Libraries: http://msdn.microsoft.com/en-us/library/dd758096(VS.85).aspx
Keeping in sync with a library: http://msdn.microsoft.com/enus/library/dd758094(VS.85).aspx#library_keeping_in_sync
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 43 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Page 44 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
User Interface - High DPI Awareness
Affected Platforms
Clients - Windows XP | Windows Vista | Windows 7
Feature Impact
Severity - Medium
Frequency - Medium
Description
The goal is to encourage end users to set their displays to native resolution and use DPI rather than
screen resolution to change the size of displayed text and images. Windows 7 can auto-detect and
configure a default DPI on clean installs on machines configured by their OEMs using DPI settings. There
are tools you can use to help design applications that are high-dpi aware in order to ensure the most
readable results.
We have added two new High DPI features to Windows 7:
Per-user DPI setting (previously per machine)
Change DPI without rebooting (logoff/logon is still required)
Manifestation of Impact
Applications that do not handle the high DPI case are likely to exhibit visual artifacts, including:
Clipping of UI or text by other UI elements
Inconsistent font sizes
Off-screen UIs
Blurring of text or UI
Broken drag and drop or other inputs
Rendering of full screen DX applications partially off screen
Solution
To make your applications DPI-aware:
Step 1: Do a high-level functional test pass, including install and uninstall at the following settings:
Setting
1024x768 @ 120 DPI (125% scaling)
[Note: If your app requires 1024x768,
then do this test at 1280x960]
1600x1200 @ 144 DPI (150% scaling)
1600x1200 @ 144 DPI with DPI
Virtualization disabled.
Revised: March 20, 2010
What to look for
This is an effective resolution of ~800x600, so look for UI clipped
off the screen or layout issues. Also look for pixilated bitmaps and
icons.
Blurry UI. Verify that all mouse operations work, especially dragand-drop operations. Also, verify full-screen modes work properly.
Often buttons and UI will not scale in relation to larger text and
there will be significant text clipping. Look for layout issues in
general and pixilated bitmaps and icons.
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 45 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Step 2: Write down all the issues found, including location, screen resolution, and DPI settings, as
well as how the application behaves in the other DPI/Resolution configurations for completeness
Step 3: Check each issue against the Common DPI Coding Issues
Step 4: Assess the cost of making the application fully DPI aware
Step 5: Make a list of the High DPI assets required (for example, buttons, icons)
Step 6: Work through and fix the list of DPI issues found in Step 1
Step 7: Integrate the new assets from Step 5
Step 8: Declare your application DPI Aware
Compatibility, Performance, Reliability, and Usability Testing
Re-run the DPI Awareness assessment and verify the issues are fixed.
Links to Other Resources
Writing DPI-Aware Win32 Applications white paper:
http://go.microsoft.com/fwlink/?LinkID=129586 for the PDF version or
http://go.microsoft.com/fwlink/?LinkID=129588 for the Windows XPS version or
http://msdn.microsoft.com/en-us/library/dd464646(VS.85).aspx for the MSDN online version
Contact for technical questions: disup@microsoft.com
Page 46 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Fault Tolerant Heap
Affected Platforms
Clients - Windows 7
Feature Impact
Severity - Medium
Frequency - Low
Description
The Fault Tolerant Heap (FTH) is a subsystem of Windows 7 responsible for monitoring application
crashes and autonomously applying mitigations to prevent future crashes on a per application basis. For
the vast majority of users, FTH will function with no need for intervention or change on their part.
However, in some cases, application developers and software testers may need to override the default
behavior of this system.
Solution
Viewing Fault Tolerant Heap activity
Fault Tolerant Heap logs information when the service starts, stops, or starts mitigating problems for a
new application. To view this information, follow these steps:
1. Click on the start menu
2. Right-click Computer and choose Manage
3. Click Event Viewer > Applications and Services Logs > Microsoft > Windows > Fault-TolerantHeap
4. View FTH Events
The service stop and start events contain no additional data. The FTH Enabled event contains the Process
ID (PID), the process image name, and the process instance start time.
Disabling Fault Tolerant Heap
Caution Serious problems may occur if you modify the registry incorrectly by using Registry Editor or by
using another method. These problems may require you to reinstall the operating system. Microsoft
cannot guarantee that these problems can be solved. Modify the registry at your own risk.
To disable Fault Tolerant Heap entirely on a system, set the REG_DWORD value
HKLM\Software\Microsoft\FTH\Enabled to 0.
After changing this value, restart the system. FTH will no longer activate for new applications.
Resetting the list of applications tracked by FTH
Fault Tolerant heap is self-managing and will autonomously stop applying in the case that mitigations are
not effective for a given application. However, if you need to reset the list of applications for which FTH
is mitigating problems (for example, if you are testing an application and need to reproduce a crash that
FTH is mitigating), you can run the following command from an elevated command prompt:
Rundll32.exe fthsvc.dll,FthSysprepSpecialize
Caution Running this command will clear all FTH applications, so applications that are currently
functioning properly may begin to crash again after running this command.
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 47 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Internet Explorer 8 - Data Execution Protection/NX
Platform
Clients - Windows XP | Windows Vista | Windows 7
Servers - Windows Server 2003 | Windows Server 2008 | Windows Server 2008 R2
Internet Explorer 8 will enable DEP/NX protection when run on an operating system with the latest
service pack. Windows XP SP3, Windows Server 2003 SP3, Windows Vista SP1, and Windows
Server 2008 all have DEP/NX enabled by default in Internet Explorer 8.
Feature Impact
Severity - Medium
Frequency - Low
Typically, any application that runs in Internet Explorer and is not compatible with DEP/NX will crash on
startup and will not function. Internet Explorer may crash on startup if add-ons not compatible with
DEP/NX are installed.
Description
DEP/NX is a security feature that helps mitigate memory-related vulnerabilities. As of Internet Explorer
8, all Internet Explorer processes enable the DEP/NX feature by default.
Manifestation of Impact
The Windows Kernel monitors a program's execution. If the Kernel detects an attempt to run code from
a memory page that is not marked executable, the Kernel halts execution of the program, resulting in a
"crash." This is a security measure to help ensure that memory-related vulnerabilities (for example,
buffer overflows) in the application cannot be exploited in order to execute arbitrary code.
End-user Mitigation
Install a later version of the add-on or framework that is DEP/NX compatible.
Run IE elevated as Administrator and then disable DEP/NX using the checkbox on the Internet
Options / Advanced tab labeled "Enable memory protection to help mitigate online attacks."
Developer Solution
Compile applications using latest versions of frameworks (for example, ATL) that are DEP
compatible.
Leveraging Feature Capabilities
Use the /NXCOMPAT linker option to indicate DEP/NX compatibility
Opt your code into other available defenses like stack defense (/GS), safe exception handling
(/SafeSEH), and ASLR (/DynamicBase)
Page 48 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Compatibility, Performance, Reliability, and Usability Testing
Test your code with DEP/NX enabled using latest released Internet Explorer version on Windows
Vista SP1 or later.
Test with Internet Explorer 7 on Windows Vista after enabling the DEP/NX option. To enable
DEP/NX for Internet Explorer 7: Run Internet Explorer as an administrator, then set the
appropriate checkbox in the Tools > Internet Options > Advanced tab
Run the Internet Explorer Compatibility Test Tool (IECTT), provided with the Application
Compatibility Toolkit (ACT) to locate any potential issues due to the DEP/NX changes.
Links to Other Resources
Internet Explorer 8 Security Part I: DEP/NX Memory Protection:
http://blogs.msdn.com/ie/archive/2008/04/08/ie8-security-part-I_3A00_-dep-nx-memoryprotection.aspx
Data Execution Prevention: http://msdn2.microsoft.com/en-us/library/aa366553.aspx
New NX APIs added to Windows Vista SP1, Windows XP SP3 and Windows Server 2008 R2:
http://blogs.msdn.com/michael_howard/archive/2008/01/29/new-nx-apis-added-to-windowsvista-sp1-windows-xp-sp3-and-windows-server-2008.aspx
Application Compatibility Toolkit Download:
http://www.microsoft.com/downloads/details.aspx?FamilyId=24DA89E9-B581-47B0-B45E492DD6DA2971
Known Internet Explorer Security Feature Issues: http://technet.microsoft.com/enus/library/cc722079.aspx
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 49 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
User Interface - User Account Control Dialog Updates
Affected Platforms
Clients - Windows 7
Servers - Windows Server 2008 R2
Feature Impact
Severity - Low
Frequency - Medium
Description
In Windows 7, we have standardized the UAC dialog box choices. Previously, users had to select from
multiple options, for example, "Continue," "Cancel," etc. Now all dialog boxes give users a simple "Yes"
or "No." The dialog layout now also clearly shows the program name, publisher, and origin.
Leveraging Feature Capabilities
The application development requirements in Windows 7 for UAC compatibility are the same as in
Windows Vista. Windows Vista-compatible applications will interact with UAC in Windows 7 without any
modifications. See the User Account Control topics in the Windows Vista Application Compatibility
Cookbook for information about how to make Windows XP applications work correctly on Windows 7.
While the UAC improvements for Windows 7 will impact the user's experience, they will not impact the
application interface. However, if there is any help content linked to the UAC dialogs, you may need to
update the screenshots.
Links to Other Resources
Windows Vista Application Compatibility Cookbook: http://msdn.microsoft.com/enus/library/bb757005.aspx
Application Compatibility Toolkit Download:
http://www.microsoft.com/downloads/details.aspx?FamilyId=24DA89E9-B581-47B0-B45E492DD6DA2971
Standard User Analyzer: http://technet.microsoft.com/en-us/library/cc766021.aspx
Page 50 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
ChooseFont() Win32 Common Dialog
Affected Platforms
Clients - Windows 7
Servers - Windows Server 2008 R2
Feature Impact
Severity - Low
Frequency - Medium
Description
Windows 7 includes several updates to the ChooseFont() Win32 common dialog. These fall into two
categories:
Visual refresh of the dialog
Support for new show/hide fonts feature
The dialog refresh updates the standard template to bring the dialog more in line with other dialog
layouts in Windows. It introduces WYSIWYG to the font display lists to help users choose fonts. It also
includes a link to the Fonts CPL to provide easy access for users wishing to customize their font lists.
Show/hide fonts is a new Windows 7 platform feature whereby fonts not appropriate for the current
user's language settings (input methods) are not presented by default in font selection lists. Users may
customize the fonts that they wish to appear in the Fonts CPL or may disable this feature.
Manifestation of Impact
Dialog visual refresh
We have introduced two new templates in Windows 7 (one for applications that load version 6 or later
of comctl32.dll and another for applications loading earlier versions).
For application compatibility reasons, these new templates will only be loaded for applications
that do not hook the ChooseFont message queue. Applications that hook the message queue will
continue to see the old dialog layout.
Applications that provide their own templates will continue to be able to use them.
Applications that do not get the new templates will see no dialog layout changes from Windows Vista.
They should however still get the new WYSIWYG font preview.
Show/hide fonts
For all versions of ChooseFont, the dialog will use the current user's show/hide font settings to
determine the font list to display. This will result in the display of fewer font lists in most instances.
End-user Mitigation
Show/Hide Fonts: To disable font hiding, users should go to the Font Settings page in the Fonts CPL
and deselect the "Hide fonts based on language settings" checkbox.
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 51 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Developer Mitigation
Visual refresh: Applications developers who provide their own templates may want to refresh
this to be in line with the appropriate new Windows 7 template. The new templates are available
in the Font.dlg template file.
Note: The new published template contains an additional SysLink control that provides a
shortcut that allows users to launch the Fonts CPL to display more fonts. The link control
requires version 6 of the Windows common control library (comctl32.dll). Developers should
provide a manifest or directive that specifies the use of version 6 of the DLL if available. Where
an application uses an earlier version of the common control library, use the "PUSHBUTTON"
control type instead.
Show/Hide Fonts: Developers may disable this feature by providing an additional flag
(CF_INACTIVEFONTS) in the flags member of the CHOOSEFONT structure. Setting this flag causes
all installed fonts to display in the font list.
Show/Hide Fonts: Applications that provide ChooseFont help content may wish to add content
to explain why the font list is reduced and direct users to the Fonts CPL to customize their font
lists.
Compatibility, Performance, Reliability, and Usability Testing
Developers whose applications hook the ChooseFont message queue to customize the dialog should
verify that their applications retain all existing functionality.
Applications that heavily trim the font list using flags should ensure that the font list presented remains
acceptable.
Page 52 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Application Manifest
Affected Platforms
Clients - Windows 7
Servers - Windows Server 2008 R2
Feature Impact
Severity - Low
Frequency - Low
Description
Windows 7 introduces a new section in the application manifest called "Compatibility." This section helps
Windows determine the versions of Windows that an application was designed to target, and enables
Windows to provide the behavior that the application expects based on the version of Windows that the
application targeted.
The Compatibility section allows Windows to provide new behavior to new developer-created software
while maintaining the compatibility for existing software. This section also helps Windows deliver greater
compatibility in future versions of Windows as well. For example, an application declaring support only
for Windows 7 in the Compatibility section will continue to receive Windows 7 behavior in future version
of Windows.
Manifestation of Change
Applications without a Compatibility section in their manifest will receive Windows Vista behavior by
default on Windows 7 and future Windows versions. Note that Windows XP and Windows Vista ignore
this manifest section and it has no impact on them.
The following Windows components provide divergent behavior based on the Compatibility section in
Windows 7:
RPC Default Thread Pool
Windows 7: To improve scalability and reduce thread counts, RPC switched to the NT thread
pool (default pool). For Windows Vista, RPC used a private thread pool.
o For binaries compiled for Win7 the default pool is used
o If I_RpcMgmtEnableDedicatedThreadPool is called before any RPC API is called, the
private thread pool is used (Vista behavior)
o If I_RpcMgmtEnableDedicatedThreadPool is called after an RPC call, the default pool is
used, I_RpcMgmtEnableDedicatedThreadPool returns the error 1764, and the requested
operation is not supported
Windows Vista (default): For binaries compiled for Windows Vista and below, the private pool is
used.
DirectDraw Lock
Windows 7: Applications manifested for Windows 7 cannot call Lock API in DDRAW to lock the
primary Desktop video buffer. Doing so will result in error, and NULL pointer for the primary will
be returned. This behavior is enforced even if Desktop Window Manager Composition is not
turned on. Windows 7 compatible applications must not lock the primary video buffer to render.
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 53 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Windows Vista (default): Applications will be able to acquire a lock on the primary video buffer
as legacy applications depend on this behavior. Running the application turns off Desktop
Window Manager.
DirectDraw Bit Block Transfer (Blt) to Primary without Clipping Window
Windows 7: Applications manifested for Windows 7 are prevented from performing Blt's to the
primary Desktop video buffer without a clipping window. Doing so will result in error and the Blt
area will not be rendered. Windows enforces this behavior even if you do not turn on Desktop
Window Manager Composition. Windows 7 compatible applications must Blt to a clipping
window.
Windows Vista (default): Applications must be able to Blt to the primary without a clipping
window as legacy applications depend on this behavior. Running this application turns off the
Desktop Window Manager.
GetOverlappedResult API
Windows 7: Resolves a race condition where a multi-threaded app using GetOverlappedResult
can return without resetting the event in the overlapped structure, causing the next call to this
function to return prematurely.
Windows Vista (default): Provides the behavior with the race condition that applications may
have a dependency on. Applications wishing to avoid this race prior to the Windows 7 behavior
should wait on the overlapped event and when signaled, call GetOverlappedResult with bWait
== FALSE.
Program Compatibility Assistant (PCA)
Windows 7: Applications with Compatibility section will not get the PCA mitigation.
Windows Vista (default): Applications that fail to install properly or crash during runtime under
some specific circumstances will get the PCA mitigation. For more details, see the reference
section.
Leveraging Feature Capabilities
Update the application manifest with the latest Compatibility information for operating system support.
The section describes the additions to the manifest:
Name Space: Compatibility.v1 (xmlns="urn:schemas-microsoft-com:compatibility.v1">)
Section Name: Compatibility (new section)
SupportedOS: GUID of supported operating system - The GUIDs that map to the supported
operating systems are:
{e2011457-1546-43c5-a5fe-008deee3d3f0} for Windows Vista: This is the default
value for the switchback context.
{35138b9a-5d96-4fbd-8e2d-a2440225f93a} for Windows 7: Applications that set this
value in the application manifest get the Windows 7 behavior.
Microsoft will generate and post GUIDs for future Windows versions as needed.
Page 54 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
An XML example of an updated manifest:
Note: The attribute and tag names in the application manifest are case sensitive.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!—- The ID below indicates application support for Windows Vista -->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
<!—- The ID below indicates application support for Windows 7 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
</application>
</compatibility>
</assembly>
The value of adding GUIDs for both operating systems in the above example is to provide downlevel
support. Applications that support both platforms would not need separate manifests for each platform.
Compatibility, Performance, Reliability, and Usability Testing
Test the application with the new compatibility section and SupportedOS ID ={35138b9a-5d964fbd-8e2d-a2440225f93a} to ensure that the application works properly using the latest
Windows 7 behaviors
Test the application with the new compatibility section and SupportedOS ID ={e2011457-154643c5-a5fe-008deee3d3f0} (or without this section entirely) to ensure that the application works
properly using the Windows Vista behaviors on Windows 7
Known Issue
Context Mismatch
An application runs in a Windows Vista context instead of in a Windows 7 context on a computer that is
running an x64 edition of either Windows 7 or Windows Server 2008 R2.
Solution
Patches are available to correct this for all supported x64-based versions of Windows 7 and Windows
Server 2008 R2, as well as for all supported IA-64-based versions of Windows Server 2008 R2. Go to the
Microsoft Support page at http://support.microsoft.com/kb/978637 for additional details and to
download the correct version for your system.
Links to Other Resources
QueryActCtxW Function: http://msdn.microsoft.com/en-us/library/aa375704(VS.85).aspx
UAC manifest: http://msdn.microsoft.com/en-us/library/bb756929.aspx
Application manifests for Windows applications: http://msdn.microsoft.com/enus/library/aa374191(VS.85).aspx
Desktop Window Manager (DWM): http://msdn.microsoft.com/en-us/library/aa969540.aspx
Context Mismatch Patch: http://support.microsoft.com/kb/978637
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 55 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Server Hyper-V
Affected Platforms
Clients – Windows XP | Windows Vista | Windows 7
Servers – Windows Server 2008 | Windows Server 2008 R2
Feature Impact
Severity – Low
Frequency – Low
Description
Server virtualization enables multiple operating systems to run on a single physical machine as virtual
machines (VMs), allowing you to consolidate workloads of underutilized server machines onto a smaller
number of fully utilized machines. Windows 7 includes several enhancements to the Windows
Server 2008 version:
Live Migration: In Windows Server 2008, we had Quick Migration. With Live Migration, we
improved migration speed and storage flexibility.
Logical Processor Support: We increased logical host processors from 16LP to 64LP.
Storage Hot Add: Now you can add additional VHD or Pass-through disks to a running virtual
machine without turning off the virtual machine.
New Hardware Support: We have added support for the technologies included in new
processors and network cards coming to market, including Second Level Translation (SLAT), TCP
Offload (Chimney), and VMdQ.
Terminal Services virtualization (TSv): We centralized desktop solution for Hyper-V.
Manifestations of Impact
Live Migration: You may need to change the way you have architected your storage systems in
order to fully leverage this technology. Though these changes may not be required, you may
choose to implement them in order to fully leverage the benefits. You may need a management
application to orchestrate Live Migration.
Logical Processor Support: This feature will have no impact on customers or ISVs when migrating
from Windows Server 2008 to Windows Server 2008 R2.
Storage Hot Add: This feature will have no impact to customers or ISVs when migrating from
Windows Server 2008 to Windows Server 2008 R2. Management applications that configure the
settings of a virtual machine may require updating in order to manage this new feature.
New Hardware Support: These features apply only to new hardware that is being introduced to
the market. Because it will not have build-in support for these features, it is not likely that a
physical server that is being migrated from Window Server 2008 to Windows Server 2008 R2 will
be impacted. If these features are available on the server that is being migrated, no direct
changes are anticipated.
Page 56 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Terminal Services virtualization: This feature will have no impact to customers or ISVs when
migrating from Windows Server 2008 to Windows Server 2008 R2. Applications that leverage
Terminal Services (TS) may be impacted. This feature directly integrates with TS and therefore
applications that configure TS may require updating in order to manage this new feature.
Mitigation
Live Migration: Provide prescriptive Guidance to end users with best practices and
recommendations for storage system design. You must inform the end user about the options
and recommendations.
Leveraging Capabilities:
Live Migration: This feature enables the Dynamic IT environment. Virtualization Management
Application Developers must modify their application to leverage this new feature. Microsoft will
make WMI interfaces publically available to allow a developer to integrate applications with this
feature.
Terminal Services virtualization: This feature enables a new virtualization scenario. Applications
that leverage Terminal Services (TS) may be impacted. This feature directly integrates with TS
and therefore applications that configure TS may require updating in order to manage this new
feature.
Links to Other Resources
WMI management interfaces for Hyper-V v1 are available at http://msdn2.microsoft.com/enus/library/cc136992(VS.85).aspx. While most of this content will apply to v2 of Hyper-V, an updated
version with v2-specific information should be available closer to the Windows 7 launch.
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 57 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Microsoft Message Queuing (MSMQ) - Improved Queue Handling
Platform
Clients – Windows 7
Servers – Windows Server 2008 R2
Feature Impact
Severity – Low
Frequency – Low
Description
MSMQ Service does not put a hard limit on the number of queues that can be created on a system.
However, the performance of the system is impacted when a large number of queues is created.
Specifically, when there are more than a few thousand queues, the start-up time of the MSMQ Service
increases exponentially resulting in a visible impact.
Microsoft has optimized the MSMQ Service start-up in Windows 7 to reduce the look-up overhead for
loading the queues into memory. This optimization has led to a dramatic improvement of the start-up
time of the MSMQ Service even when several thousand queues are created in the system.
Manifestation of Impact
This performance improvement does not impact the functionality of any existing application.
Leveraging the Changed Feature
Application developers using MSMQ on Windows 7 can now architect their solutions without limiting
the number of queues. Note that the number of queues still affects overall performance of the MSMQ
Server, but the performance impact is now on a linear rather than exponential scale.
Compatibility, Performance, Reliability, and Usability Tests
If you use a large number of queues, simulate the production environment on a test bed, monitor
performance, and analyze the service start-up time and the message throughput with a large number of
queues and messages present in the test system.
Page 58 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Remote Desktop Services
Affected Platforms
Servers - Windows Server 2008 | Windows Server 2008 R2
Feature Impact
Severity - Low
Frequency - Low
Description
Remote Desktop Services (formerly known as Terminal Services) allows multiple concurrent users to
access Windows Server in order to provide application and data hosting services using Microsoft
"Presentation Virtualization" technology.
While most 32-bit and 64-bit applications run as is on Windows Remote Desktop Services, several others
do not perform as expected due to the difference in the platform (multi-user environment, concurrent
access by multiple users, etc.).
For further information regarding application quality, please read the whitepaper on Application
Readiness for Terminal Services. Visit the Terminal Services product page and the TS TechNet Web sites
learn more about Desktop Remote Services. To learn more about developing applications for Desktop
Remote Services, review the TS Programming Guidelines.
Manifestations of Impacts and Their Mitigations
Three changes in Windows 7 affect applications on Remote Desktop Services:
Windows Server 2008 R2 is 64-bit only
Per-session IP Virtualization
MSI-based deployments – User-specific keys
64-bit Only Windows Server 2008 R2
Applications written for 32-bit server will run in WoW mode and not natively on the Windows
Server 2008 R2 or, hence, on Remote Desktop Services. See the Windows 7 64-Bit Only topic for details.
Mitigations for 64-bit only Windows Server 2008 R2
Most applications written for 32-bit will continue to work as normal in WoW mode. Any new applications
written for Windows 7 Remote Desktop Services should be developed and tested for deployment on 64bit platforms.
IP Virtualization
Remote Desktop IP Virtualization allows the user to assign IP addresses to remote desktop connections
on a per-session or per-program basis:
If you assign IP addresses on a per-session basis, all of the applications will use the session IP
address.
If you assign IP addresses on a per-program basis, only the specified applications will use the
session IP address and the remaining applications in the session will not be affected.
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 59 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
If you assign IP addresses for multiple programs, they will share a session IP address.
If you have more than one network adapter on the computer, you must also choose one of them
for Remote Desktop IP Virtualization.
Mitigations for IP Virtualization
Some programs require a unique IP address for each instance of the application. Prior to Windows
Server 2008 R2, every session on a remote desktop server shared the same IP address, resulting in
compatibility issues for these applications. Remote Desktop IP Virtualization allows these applications to
run on a Remote Desktop Server.
MSI-based Deployments
Microsoft Installer RDS Compatibility is a new feature included with Remote Desktop Services in
Windows Server 2008 R2. With Remote Desktop Services in Windows Server 2008 R2, per-user
application installations are queued by the Remote Desktop Server and then handled by the Microsoft
Installer.
In Windows Server 2008 R2, you can install a program on the Remote Desktop Server just as you would
install the program on a local desktop. Ensure, however, that you install the program for all users and
install all components of the program locally on the Remote Desktop Server.
Mitigations for MSI-based Deployments
Prior to the Windows Server 2008 R2 version of Remote Desktop Services, Windows supported only one
Windows Installer installation at a time. For applications that required per-user configurations, such as
Microsoft Office Word, an administrator needed to pre-install the application, and application
developers needed to test these applications on both the remote desktop client and the Remote
Desktop Session Host. Windows Installer RDS Compatibility feature allows identifying and installing
missing per-user configurations for multiple users simultaneously and makes the application installation
experience on Remote Desktop Server similar to that on a local desktop.
Links to Other Resources
Terminal Services Programming Guidelines: http://msdn.microsoft.com/enus/library/aa383490(VS.85).aspx
Terminal Services at TechNet: http://technet.microsoft.com/en-us/ts/default.aspx
Terminal Services product homepage:
http://www.microsoft.com/windowsserver2008/en/us/ts-product-home.aspx
Application Readiness for Terminal Services whitepaper:
https://connect.microsoft.com/tsappcompat/content/content.aspx?ContentID=10015
Page 60 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Tools, Best Practices, and Guidance
This section contains aids for Application Developers who want to either confirm the continued
compatibility of their existing applications or ensure optimal quality and compatibility for new
applications they are designing. Descriptions of the following tools, best practices, and guidance are
included in this section:
Application Compatibility Toolkit (ACT) 5.5
Compatibility Administrator
Standard User Analyzer (SUA) Tool and Standard User Analyzer Wizard (SUA Wizard)
Application Verifier
Best Practices for On/Off Performance
Preventing Memory Leaks in Windows Applications
Preventing Hangs in Windows Applications
Deployment Image Servicing and Management (DISM)
Windows Troubleshooting
Windows Error Reporting Problem Steps Recorder
Best Practices for Energy Efficiency
Best Practices for Minimizing Unresponsive Services
Windows 7 Client Software Logo Program
Windows Server 2008 R2 Logo Program for Software
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 61 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Application Compatibility Toolkit (ACT) 5.5
Affected Platforms
Clients: Windows XP | Windows Vista | Windows 7
Servers: Windows Server 2003 | Windows Server 2008 | Windows Server 2008 R2
Description
The Microsoft Application Compatibility Toolkit (ACT) 5.5 is a lifecycle management tool that assists in
identifying and managing your overall application portfolio, reducing the cost and time involved in
resolving application compatibility issues, and helping you quickly deploy Windows Vista and Windows
updates.
Usage
With the ACT, you can:
Analyze your portfolio of applications, Web sites, and computers
Evaluate operating system deployments, the impact of operating system updates, and your
compatibility with Web sites
Centrally manage compatibility evaluators and configuration settings
Rationalize and organize applications, devices, Web sites, and computers
Prioritize application compatibility efforts with filtered reporting
Add and manage issues and solutions for your enterprise-computing environment
Deploy automated mitigations to known compatibility issues
Send and receive compatibility information from the Microsoft Compatibility Exchange
Links to Other Resources
Application Compatibility Toolkit Download:
http://www.microsoft.com/downloads/details.aspx?FamilyId=24DA89E9-B581-47B0-B45E492DD6DA2971
Introduction to the Application Compatibility Toolkit: http://technet.microsoft.com/enus/library/cc722367.aspx
Application Compatibility Toolkit Technical Reference: http://technet.microsoft.com/enus/library/cc749328.aspx
ACT Walkthrough Exercises: http://technet.microsoft.com/en-us/library/cc766493.aspx
Page 62 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Compatibility Administrator
Affected Platforms
Clients: Windows 2000 | Windows XP | Windows Vista | Windows 7
Servers: Windows Server 2003 | Windows Server 2008 | Windows Server 2008 R2
Description
The Compatibility Administrator tool, provided by the Application Compatibility Toolkit (ACT) enables
you to resolve many of your potential application compatibility issues, before deploying a new version of
Windows to your organization, by:
Providing individual compatibility fixes, compatibility modes, and AppHelp messages that you can
use to resolve specific compatibility issues
Enabling you to create customized compatibility fixes, compatibility modes, AppHelp messages, and
compatibility databases
Providing a query tool that enables you to search for installed fixes on your local computers
Usage
The following flowchart illustrates the steps required in using the Compatibility Administrator to create
your compatibility fixes, compatibility modes, and your AppHelp messages.
Links to Other Resources
Application Compatibility Toolkit Download:
http://www.microsoft.com/downloads/details.aspx?FamilyId=24DA89E9-B581-47B0-B45E492DD6DA2971
Using the Compatibility Administrator: http://technet.microsoft.com/enus/library/cc749034.aspx
Known Compatibility Fixes, Compatibility Modes, and AppHelp Messages:
http://technet.microsoft.com/en-us/library/cc765984.aspx
Testing and Mitigating Issues by Using the Development Tools:
http://technet.microsoft.com/en-us/library/cc766461.aspx
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 63 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Standard User Analyzer (SUA) Tool and Standard User Analyzer Wizard (SUA
Wizard)
Affected Platforms
Clients: Windows XP | Windows Vista | Windows 7
Servers: Windows Server 2003 | Windows Server 2008 | Windows Server 2008 R2
Description
The Application Compatibility Toolkit includes the Standard User Analyzer (SUA) tool and the Standard
User Analyzer Wizard (SUA Wizard). These tools enable you to test your applications and to monitor API
calls in order to detect potential compatibility issues due to the User Account Control (UAC) feature in
the Windows 7 operating system.
UAC, formerly known as Limited User Account (LUA), requires that all users (including members of the
Administrator group) run as Standard Users by using the security prompt dialog box until the application
is deliberately elevated. However, applications that require access and privileges for locations that are
unavailable to a Standard User cannot run properly with the Standard User role.
Usage
The following sections provide detailed information about how to use the SUA and SUA Wizard tools.
SUA Tool
The SUA tool enables you to analyze an application, review a detailed report about the UAC-related
issues, and then apply the suggested and selected application mitigations, as shown in the following
flowchart.
SUA Tool and Virtualization
Only the SUA tool enables you to turn on and off the virtualization feature. By turning off the
virtualization feature, the tested application will behave more like when it is functioning on the
Windows XP operating system.
SUA Tool and Elevated Privileges
Only the SUA tool enables you to turn on and off the Launch Elevated feature. The Launch Elevated
feature enables the selected application to run as an Administrator or as a Standard User. Depending on
your selection, you will locate different types of UAC-related issues. If you clear the Launch Elevated
check box, your application will run with full Administrator privileges, which enables SUA to predict the
issues that might occur for a Standard User. If you select the Launch Elevated check box, you will see
errors that result from the application actually running and generating errors.
Page 64 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
SUA Wizard
The SUA Wizard enables you to follow a guided, step-by-step process by which you can analyze an
application and then apply the suggested and selected application mitigations, as shown in the following
flowchart. Unlike the SUA tool, the wizard does not enable a review of the detailed UAC-related issues.
Links to Other Resources
Application Compatibility Toolkit Download:
http://www.microsoft.com/downloads/details.aspx?FamilyId=24DA89E9-B581-47B0-B45E492DD6DA2971
Understanding the Standard User Analyzer Tools: http://technet.microsoft.com/enus/library/cc838047.aspx
Standard User Analyzer Technical Reference: http://technet.microsoft.com/enus/library/cc765948.aspx
Testing and Mitigating Issues by Using the Development Tools:
http://technet.microsoft.com/en-us/library/cc766461.aspx
Application Compatibility and User Account Control: http://technet.microsoft.com/enus/windows/aa905066.aspx
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 65 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Application Verifier
Affected Platforms
Clients - Windows XP | Windows Vista | Windows 7
Servers - Windows Server 2003 | Windows Server 2008 | Windows Server 2008 R2
Description
Promote and enforce Application Verifier as a quality gate for all development. It includes several
improvements:
We have provided additional checks to address issues that the Windows Error Reporting team
discovered during thread-pool usage.
We combined 32- and 64-bit versions of the package to address changes in Windows 7, including
the needs for testing 32-bit components under a 64-bit version of Windows, as well as for
general simplification.
We have included additional checks for multi-threaded applications, running 32-bit applications
on 64-bit Windows, as well as many bug fixes.
These changes should have no negative impact on users who do not enable the Thread Checks; those
who do should receive additional support in discovery and diagnosis of existing thread-pool usage
problems. Whether or not you enable Thread Checks, you will benefit from the other improvements and
bug fixes in this service.
While there is a slight performance penalty when using this service, the performance levels should
remain acceptable because it does not typically run in retail environments.
Usage
General Information:
To deliver reliable Windows applications:
1. Test applications written in unmanaged (native) code with Application Verifier under the
debugger and with full-page heap before releasing it to customers.
2. Follow the steps provided by Application Verifier to resolve errant conditions.
3. Once your application is released, regularly monitor the application failure reports collected by
Windows error reporting.
Thread-pool checks are enabled by default under the "Basics" check heading. As this is included in the
default setting, users need only to run Application Verifier on their code with the default settings to
leverage the new checks.
Details:
At a minimum, you should run Application Verifier with the Basics setting selected. This is required for
WinLogo and WinQual. The Basics setting checks for the following:
Exceptions Stop Details - Ensures that applications do not hide access violations using
structured exception handling
Handles Stop Details - Tests to ensure the application is not attempting to use invalid handles
Page 66 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Heaps Stop Details - Checks for memory corruptions issues in the heap
Input/Output Stop Details - Monitors the execution of asynchronous IO, and performs various
validations
Leak Stop Details - Detects leaks by tracking the resources made by a dll that are not freed by
the time the dll was unloaded
Locks Stop Details - Verifies the correct usage for critical sections
Memory Stop Details - Ensures APIs for virtual space manipulations are used correctly (for
example, VirtualAlloc, MapViewOfFile)
TLS Stop Details - Ensures that Thread Local Storage APIs are used correctly
Thread Pool Stop Details - Ensures correct usage of thread pool APIs and enforces consistency
checks on worker-thread-states after a callback
If your application is migrating from a "Pre-Vista" application, you will want to leverage the "LuaPriv"
(also known as UAC checks). The Limited User Account Privilege Predictor (LuaPriv) has two primary
goals:
Predictive: While running an application with administrative privilege, predict whether that
application would work as well if run with less privilege (generally, as a normal user). For
example, if the application writes to files that only allow Administrators access, then that
application will not be able to write to the same file if run as a non-administrator.
Diagnostic: While running with non-administrator privilege, identify potential problems that
may already exist with the current run. Continuing the previous example, if the application tries
to write to a file that grants only Administrator group members access, the application will get
an ACCESS_DENIED error. If the application does not operate correctly, this operation may be
the culprit.
LuaPriv identifies the following types of problems:
Potential Issue
Restricted
Namespaces
Hard Administrator
Checks
Requesting Privileges
Missing Privileges
INI-File Operations
Access Denied
Revised: March 20, 2010
Description
Creating a named synchronization object (Event, Semaphore, Mutex, etc) without a
namespace may complicate running without privilege on some operating systems
because the operating system may choose to place the object in a restricted namespace.
Creating such an object in a restricted namespace (such as the Global namespace)
requires SeCreateGlobalPrivilege, which is granted only to administrators.
LuaPriv flags both these issues if it detects them.
Some applications interrogate the user's security token to find out how much privilege
he/she has. In those cases, the application may change its behavior depending on how
much power it thinks the user has.
LuaPriv flags API calls that return this information.
An application may attempt to enable a security-relevant privilege (such as
SeTcbPrivilege or SeSecurityPrivilege) prior to performing an operation that requires it.
LuaPriv flags attempts to enable security-relevant privileges.
If an application attempts to enable a privilege that the user does not have, it probably
signals that the application expects the privilege, which can cause behavior differences.
LuaPriv flags failed privilege requests.
Attempts to write to mapped INI files (WritePrivateProfileSection and similar APIs) can
fail as a non-administrator user.
LuaPriv flags such operations.
If the application attempts to access an object (File, registry key, etc) but the attempt
fails due to insufficient access, then the application probably expects to be running with
more privilege than it has.
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 67 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Potential Issue
Deny ACEs
Access Restricted
MAXIMUM_ALLOWED
Description
LuaPriv flags object-open attempts that fail with ACCESS_DENIED and similar errors.
If an object has Deny ACEs in its DACL, then it explicitly denies access to specific entities.
This is uncommon, and makes prediction difficult, so LuaPriv flags Deny ACEs when it
finds them.
If an application attempts to open an object for rights that are not granted to normal
users (for example, trying to write to a file that is only writeable by administrators), then
the application probably will not work the same when run as a normal user.
LuaPriv flags such operations.
If an application opens an object for MAXIMUM_ALLOWED, then the actual access check
on the object will occur elsewhere. Most code that does this does not work correctly,
and will almost certainly work differently when run without privilege.
LuaPriv thus flags all incidents of MAXIMUM_ALLOWED.
Commonly overlooked issues are captured in the nebulous Misc Checks:
Dangerous APIs Stop Details
Dirty Stacks Stop Details
Time Rollover
We have added a new Print Verifier. This layer helps find and troubleshoot issues that may result when
an application calls the print subsystem. Print Verifier targets the two layers of the print subsystem, the
PrintAPI layer and the PrintDriver layer.
Print API Layer
Print Verifier tests the interface between a program and Winspool.drv and prntvpt.dll and tests the
interfaces of those DLLs. You can review the rules for calling functions in this interface in the MSDN help
section for APIs exported by winspool.drv and prntvpt.dll.
Print Driver Layer
Print Verifier also tests the interface between a core print driver such as UNIDRV.DLL, UNIDRUI.DLL,
PSCRIPT5.DLL, PS5UI.DLL, or MXDWDRV.DLL, and the print driver plug-ins. You can find information
about this interface in the MSDN and the WDK.
Note that some of these checks are for Windows 7 only, and others will simply perform better under
Windows 7.
Typically, only debug versions run the Application Verifier, so performance is not generally an issue. If
performance issues arise from the use of this, or any other Application Verifier check, run one check at a
time until you have performed all needed checks.
Nearly 10% of application crashes on Windows systems are due to heap corruption. These crashes are
nearly impossible to debug after the fact. The best way to avoid these issues is to test with the Page
Heap features found in Application Verifier. There are two flavors of Page Heap: "Full" and "Light." Full is
the default; it will force a debugger stop instantly upon detecting corruption. This feature MUST be run
while under the debugger. However, it is also the most resource demanding. If a user is having timing
issues and has already run a scenario under "Full" Page Heap, setting it to "Light" will likely address
these issues. Additionally, Light Page Heap does not crash until the process exits. It does provide a stack
trace to the allocation, but can take considerably longer to diagnose than leveraging its Full counterpart.
Page 68 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Monitor the reliability status of the applications via the Winqual Web portal. This portal shows the error
reports collected via Windows error reporting, so it is easy to identify the most frequent failures. Learn
about this at Windows Error Reporting: Getting Started. Microsoft does not charge for this service.
To take advantage of WinQual, you must:
Register your company for WinQual, which requires a VeriSign ID. You can find Windows 7
information about WinQual in the developer portal grouped under Windows Vista SP1 \
Windows Server 2008. It will have a Windows 7 location soon.
Map the ISV applications to a product name and the ISV name, which links the failure reports to
the company. Other ISVs cannot view your error reports.
Use the portal to identify top issues. ISVs can also create responses that inform customers what
steps to take after a failure. The response system supports over 10 languages worldwide.
One further note: Application Verifier is only as good as the code paths you run it against. The value of
combining this tool with a code coverage tool cannot be overstated.
Links to Other Resources
Debugging Tools for Windows:
Overview and download site:
http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx
Online documentation: http://msdn.microsoft.com/en-us/library/cc267445.aspx
Application Verifier:
Overview: http://msdn.microsoft.com/en-us/library/ms644353.aspx
Download: http://www.microsoft.com/downloads/details.aspx?FamilyID=c4a25ab9-649d-4a1bb4a7-c9d8b095df18&DisplayLang=en
For Microsoft Visual Studio 2008/.NET Framework 3.5: http://msdn.microsoft.com/enus/library/ms220948.aspx
Note: the Application Verifier version that ships in VS is quite dated. If possible, use the
standalone package instead. For this reason, future versions of VS will no longer have embedded
AV.
WinQual:
Windows Quality Online Services (Winqual): https://winqual.microsoft.com
Windows Error Reporting: Getting Started:
http://www.microsoft.com/whdc/maintain/StartWER.mspx
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 69 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Best Practices for On/Off Performance
Platform
Clients - Windows Vista | Windows 7
Servers - Windows Server 2008 | Windows Server 2008 R2
Description
The system power states (or S-states), as defined in the Advanced Computer Power Interface (ACPI)
specification, are colloquially called on/off states since the most common S-state transition is a
computer turning on and off. The different on/off state transitions on a system running Windows Vista
or Windows 7 are boot, sleep (ACPI S3), hibernate (ACPI S4), and shutdown.
Good performance during these on/off transitions not only improves the perceived quality of a
computer, but also greatly affects daily computer usage patterns and system reliability. Customers can
become frustrated by systems that take too long to boot or to shut down. Mobile systems that have
lengthy sleep and hibernation transitions can unnecessarily deplete battery life. Longer shutdown times
can also adversely affect the reliability of mobile systems. For example, they increase the risk of
unexpected power cut-offs.
System extensions like drivers, applications, and services can have a significant impact on on/off
transition times. This section discusses some of the best practices that application and service
developers can follow to avoid delays during boot, standby, and shutdown, and to ensure a responsive
post-boot and post-resume user experience. For more details on how to identify on/off performance
issues using the Windows Performance Toolkit and implement the below recommendations for your
application or service, please refer to the whitepapers in the ‘Links to other Resources’ section.
Best Practices
Use the Windows Performance Toolkit to measure performance during all on/off transitions
Perform testing in a controlled way, and make comparisons against a valid baseline:
o Obtain a baseline measurement on a system with as few system extensions as possible
o
Add applications and services one at a time
o
Test for unacceptable regressions in on/off transition times
Avoid using managed code for applications on the critical boot path
Ensure that all applications respond quickly to shutdown notifications (WM_QUERYENDSESSION
and WM_ENDSESSION messages)
Reduce delays in the shutdown path of services and applications by minimizing CPU, disk, and
network activity in response to shutdown notifications
Avoid delays in processing the suspend notification (WM_POWERBROADCAST message)
Respond quickly to resume events and minimize post-resume CPU, disk, and network usage
Reduce application resource consumption post-boot
Do not start applications from the RunOnce key on every boot
Convert all nonessential services to demand start or trigger start in order to make system
resources available during boot
Page 70 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Avoid using load order groups to express service dependencies
Ensure that all running services report this status as soon as possible during boot to avoid
blocking the Service Control Manager (SCM)
Avoid using managed code for services on the startup path
Do not allow services to opt in to receive pre-shutdown and shutdown notifications
(SERVICE_CONTROL_PRESHUTDOWN and SERVICE_CONTROL_SHUTDOWN control codes) unless
absolutely required
Ensure that all services that have opted to receive shutdown notifications respond quickly to the
SCM
Verify that services do not opt in to receive suspend notifications unless absolutely required
Ensure that all services respond quickly to resume events and minimize post-resume CPU, disk,
and network usage
Links to Other Resources
Windows On/Off Transitions Solutions Guide
http://www.microsoft.com/whdc/system/pnppwr/powermgmt/OnOffTrans.mspx
On/Off Transition Performance Analysis of Windows Vista
http://www.microsoft.com/whdc/system/sysperf/On-Off_Transition.mspx
Windows Performance Analysis
http://msdn.microsoft.com/en-us/performance/default.aspx
Windows Performance Toolkit documentation on MSDN
http://msdn.microsoft.com/en-us/library/cc305187.aspx
Windows Performance Analysis forum
http://social.msdn.microsoft.com/Forums/en-US/wptk_v4/threads/
Event Tracing for Windows on MSDN
http://msdn.microsoft.com/en-us/library/aa363787.aspx
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 71 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Preventing Memory Leaks in Windows Applications
Affected Platforms
Clients - Windows 7
Servers - Windows Server 2008 R2
Description
Memory leaks are a class of bugs where the application fails to release memory when no longer needed.
Over time, memory leaks affect the performance of both the particular application as well as the
operating system. A large leak might result in unacceptable response times due to excessive paging.
Eventually the application as well as other parts of the operating system will experience failures.
Windows will free all memory allocated by the application on process termination, so short-running
applications will not affect overall system performance significantly. However, leaks in long-running
processes like services or even Explorer plug-ins can greatly impact system reliability and might force the
user to reboot Windows in order to make the system usable again.
Applications can allocate memory on their behalf by multiple means. Each type of allocation can result in
a leak if not freed after use. Here are some examples of common allocation patterns:
Heap memory via the HeapAlloc function or its C/C++ runtime equivalents malloc or new
Direct allocations from the operating system via the VirtualAlloc function
Kernel handles created via Kernel32 APIs such as CreateFile, CreateEvent, or CreateThread, hold
kernel memory on behalf of the application
GDI and USER handles created via User32 and Gdi32 APIs (by default, each process has a quota
of 10,000 handles)
Best practices
Monitoring the resource consumption of your application over time is the first step in detecting and
diagnosing memory leaks. Use Windows Task Manager and add the following columns: "Commit Size,"
"Handles," "User Objects," and "GDI Objects." This will allow you to establish a baseline for your
application and monitor resource usage over time.
Page 72 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
The following Microsoft tools provide more-detailed information and can help to detect and diagnose
leaks for the various allocation types in your application:
Performance Monitor and Resource Monitor are part of Windows 7 and can monitor and graph
resource use over time
The latest version of Application Verifier can diagnose heap leaks on Windows 7
UMDH, which is part of the Debugging Tools for Windows, analyzes the heap memory
allocations for a given process and can help find leaks and other unusual usage patterns
Xperf is a sophisticated performance analysis tool with support for heap allocation traces
CRT Debug Heap tracks heap allocations and can help build your own heap debugging features
Certain coding and design practices can limit the number of leaks in your code.
Use smart pointers in C++ code both for heap allocations as well as for Win32 resources like
kernel HANDLEs. The C++ Standard library provides the auto_ptr class for heap allocations. For
other allocation types you will need to write your own classes. The ATL library provides a rich set
of classes for automatic resource management for both heap objects and kernel handles
Use compiler intrinsic features like _com_ptr_t to encapsulate your COM interface pointers into
"smart pointers" and assist with reference counting. There are similar classes for other COM
data types: _bstr_t and _variant_yt
Monitor your .NET code unusual memory usage. Managed code is not immune to memory leaks.
The Garbage Collector (GC) will not free an object until its references count reaches zero. See
"tracking down managed memory leaks" on how to find GC leaks
Be aware of leak patterns in web client-side code. Circular references between COM objects and
scripting engines like JScript can cause large leaks in Web applications. "Understanding and
Solving Internet Explorer Leak Patterns" has more information on these kinds of leaks. You can
use the JavaScript Memory Leak Detector to debug memory leaks in your code. While Internet
Explorer 8, which is shipping with Windows 7, mitigates most of these issues, older browsers are
still vulnerable to these bugs
Avoid using multiple exit paths from a function. Allocations assigned to variables at function
scope should be freed in one particular block at the end of the function
Do not use exceptions in your code without freeing all local variables in functions. If you use
native exceptions, free all your allocations inside the __finally block. If you use C++ exceptions,
all your heap and handle allocations need to be wrapped in smart pointers
Do not discard or reinitialize a PROPVARIANT object without calling the PropVariantClear
function
Links to Resources
Common Allocation Patterns:
Heap Allocation Function: http://msdn.microsoft.com/en-us/library/aa366597(VS.85).aspx
Memory Allocation Function: http://msdn.microsoft.com/en-us/library/6ewkz86d.aspx
New Operator (C++): http://msdn.microsoft.com/en-us/library/kewsb8ba.aspx
Virtual Allocation Function: http://msdn.microsoft.com/en-us/library/aa366887(VS.85).aspx
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 73 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Kernel Objects: http://msdn.microsoft.com/en-us/library/ms724485(VS.85).aspx
GDI Object Handles: http://msdn.microsoft.com/en-us/library/ms724291(VS.85).aspx
User Interface Object Handles: http://msdn.microsoft.com/en-us/library/ms725486.aspx
Microsoft Tools:
Application Verifier: http://msdn.microsoft.com/en-us/library/dd371695(VS.85).aspx
Debugging Tools for Windows: http://msdn.microsoft.com/en-us/library/cc267445.aspx
User-Mode Dump Heap: http://msdn.microsoft.com/en-us/library/cc267868.aspx
Trace Capture, Processing, and Analysis Tool: http://msdn.microsoft.com/enus/performance/cc825801.aspx
CRT Debug Heap: http://msdn.microsoft.com/en-us/library/974tc9t1.aspx
Additional Links:
auto_ptr Class: http://msdn.microsoft.com/en-us/library/ew3fk483.aspx
Active Template Library (ATL) Memory Classes: http://msdn.microsoft.com/enus/library/44yh1z4f.aspx
_com_ptr_t Object: http://msdn.microsoft.com/en-us/library/417w8b3b.aspx
_bstr_t Class: http://msdn.microsoft.com/en-us/library/zthfhkd6.aspx
_variant_yt Class: http://msdn.microsoft.com/en-us/library/x295h94e.aspx
"Tracking down managed memory leaks":
http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx
"Understanding and Solving Internet Explorer Leak Patterns": http://msdn.microsoft.com/enus/library/bb250448.aspx
"JavaScript Memory Leak Detector": http://blogs.msdn.com/gpde/pages/javascript-memoryleak-detector.aspx
Circular Memory Leak Mitigation (in browsers): http://msdn.microsoft.com/enus/library/dd361842(VS.85).aspx
try-finally statement: http://msdn.microsoft.com/en-us/library/yb3kz605.aspx
PROPVARIANT Structure: http://msdn.microsoft.com/en-us/library/aa380072(VS.85).aspx
PropVariantClear Function: http://msdn.microsoft.com/en-us/library/aa380073(VS.85).aspx
Page 74 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Preventing Hangs in Windows Applications
Affected Platforms
Clients - Windows 7
Servers - Windows Server 2008 R2
Description
Hangs - User Perspective
Users like responsive applications. When they click on a menu, they want the application to react
instantly, even if it is currently printing their work. When they save a lengthy document in their favorite
word processor, they want to continue typing while the disk is still spinning. Users get impatient rather
quickly when the application does not react in a timely fashion to their input.
A programmer might recognize many legitimate reasons for an application not to instantly respond to
user input. The application might be busy recalculating some data, or simply waiting for its disk I/O to
complete. However, from user research, we know that users get annoyed and frustrated after just a
couple of seconds of unresponsiveness. After 5 seconds, they will try to terminate a hung application.
Next to crashes, application hangs are the most common source of user disruption when working with
Win32 applications.
There are many different root causes for application hangs, and not all of them manifest themselves in
an unresponsive UI. However, an unresponsive UI is one of the most common hang experiences, and this
scenario currently receives the most operating system support for both detection as well as recovery.
Windows automatically detects, collects debug information, and optionally terminates or restarts hung
applications. Otherwise, the user might have to restart the machine in order to recover a hung
application.
Hangs - Operating System Perspective
When an application (or more accurately, a thread) creates a window on the desktop, it enters into an
implicit contract with the Desktop Window Manager (DWM) to process window messages in a timely
fashion. The DWM posts messages (keyboard/mouse input and messages from other windows, as well as
itself) into the thread-specific message queue. The thread retrieves and dispatches those messages via
its message queue. If the thread does not service the queue by calling GetMessage(), messages are not
processed, and the window hangs: it can neither redraw nor can it accept input from the user. The OS
detects this state by attaching a timer to pending messages in the message queue. If a message has not
been retrieved within 5 seconds, the DWM declares the window to be hung. You can query this
particular window state via the IsHungAppWindow() API.
Detection is only the first step. At this point, the user still cannot even terminate the application - clicking
the X (Close) button would result in a WM_CLOSE message, which would be stuck in the message queue
just like any other message. The Desktop Window Manager assists by seamlessly hiding and then
replacing the hung window with a 'ghost' copy displaying a bitmap of the original window's previous
client area (and adding "Not Responding" to the title bar). As long as the original window's thread does
not retrieve messages, the DWM manages both windows simultaneously, but allows the user to interact
only with the ghost copy. Using this ghost window, the user can only move, minimize, and - most
importantly - close the unresponsive application, but not change its internal state.
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 75 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
The whole ghost experience looks like this:
The Desktop Window Manager does one last thing; it integrates with Windows Error Reporting, allowing
the user to not only close and optionally restart the application, but also send valuable debugging data
back to Microsoft. You can get this hang data for your own applications by signing up at the Winqual
Web site.
Windows 7 added one new feature to this experience. The OS analyzes the hung application and, under
certain circumstances, gives the user the option to cancel a blocking operation and make the application
responsive again. The current implementation supports cancellation of blocking Socket calls; more
operations will be user-cancelable in future releases.
To integrate your application with the hang recovery experience and to make the most out of the
available data, follow these steps:
Ensure that your application registers for restart and recovery, making a hang as pain-free as
possible to the user. A properly registered application can automatically restart with most of its
unsaved data intact. This works for both application hangs and crashes.
Get frequency information as well as debugging data for your hung and crashed applications
from the Winqual Web site. You can use this information even during your Beta to improve your
code. See "Introducing Windows Error Reporting" for a brief overview.
You can disable the ghosting feature in your application via a call to
DisableProcessWindowsGhosting (). However, this prevents the average user from closing and
restarting a hung application and often ends in a reboot.
Hangs - Developer Perspective
The OS defines an application hang as a UI thread that has not processed messages for at least 5
seconds. Obvious bugs cause some hangs, for example, a thread waiting for an event that is never
signaled, and two threads each holding a lock and trying to acquire the others. You can fix those bugs
without too much effort. However, many hangs are not so clear. Yes, the UI thread is not retrieving
messages - but it is equally busy doing other 'important' work and will eventually come back to
processing messages.
However, the user perceives this as a bug. The design should match the user's expectations. If the
application's design leads to an unresponsive application, the design will have to change. Finally, and this
is important, unresponsiveness cannot be fixed like a code bug; it requires upfront work during the
Page 76 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
design phase. Trying to retrofit an application's existing code base to make the UI more responsive is
often too expensive. The following design guidelines might help.
Make UI responsiveness a top-level requirement; the user should always feel in control of your
application
Ensure that users can cancel operations that take longer than one second to complete and/or
that operations can complete in the background; provide appropriate progress UI if necessary
Queue long-running or blocking operations as background tasks (this requires a well-thought out
messaging mechanism to inform the UI thread when work has been completed)
Keep the code for UI threads simple; remove as many blocking API calls as possible
Show windows and dialogs only when they are ready and fully operational. If the dialog needs to
display information that is expensive to calculate, show some generic information first and
update it on the fly when more data becomes available. A good example is the folder properties
dialog from Windows Explorer. It needs to display the folder's total size, information that is not
readily available from the file system. The dialog shows up right away and the "size" field is
updated from a worker thread:
Unfortunately, there is no simple way to design and write a responsive application. Windows does not
provide a simple asynchronous framework that would allow for easy scheduling of blocking or longrunning operations. The following sections introduce some of the best practices in preventing hangs and
highlight some of the common pitfalls.
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 77 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Best Practices
Keep the UI Thread Simple
The UI thread's primary responsibility is to retrieve and dispatch messages. Any other kind of work
introduces the risk of hanging the windows owned by this thread.
Do:
Move expensive or unbounded algorithms that result in long-running operations to worker
threads
Identify as many blocking function calls as possible and try to move them to worker threads; any
function calling into another DLL should be suspicious
Make an extra effort to remove all file I/O and networking API calls from your worker thread.
These functions can block for many seconds if not minutes. If you need to do any kind of I/O in
the UI thread, consider using asynchronous I/O
Be aware that your UI thread is also servicing all single-threaded apartment (STA) COM servers
hosted by your process; if you make a blocking call, these COM servers will be unresponsive
until you service the message queue again
Don't:
Wait on any kernel object (like Event or Mutex) for more than a very short amount of time; if
you have to wait at all, consider using MsgWaitForMultipleObjects(), which will unblock when a
new message arrives
Share a thread's window message queue with another thread by using the AttachThreadInput()
function. It is not only extremely difficult to properly synchronize access to the queue, it also can
prevent the Windows operating system from properly detecting a hung window
Use TerminateThread() on any of your worker threads. Terminating a thread in this way will not
allow it to release locks or signal events and can easily result in orphaned synchronization
objects
Call into any 'unknown' code from your UI thread. This is especially true if your application has
an extensibility model; there is no guarantee that 3rd-party code follows your responsiveness
guidelines
Make any kind of blocking broadcast call; SendMessage(HWND_BROADCAST) puts you at the
mercy of every ill-written application currently running
Implement Asynchronous Patterns
Removing long-running or blocking operations from the UI thread requires implementing an
asynchronous framework that allows offloading those operations to worker threads.
Do:
Use asynchronous window message APIs in your UI thread, especially by replacing SendMessage
with one of its non-blocking peers: PostMessage, SendNotifyMessage, or SendMessageCallback
Page 78 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Use background threads to execute long-running or blocking tasks. Use the new thread pool API
to implement your worker threads
Provide cancellation support for long-running background tasks. For blocking I/O operations, use
I/O cancellation, but only as a last resort; it's not easy to cancel the 'right' operation
Implement an asynchronous design for managed code by using the IAsyncResult pattern or by
using Events
Use Locks Wisely
Your application or DLL needs locks to synchronize access to its internal data structures. Using multiple
locks increases parallelism and makes your application more responsive. However, using multiple locks
also increases the chance of acquiring those locks in different orders and causing your threads to
deadlock. If two threads each hold a lock and then try to acquire the other thread's lock, their operations
will form a circular wait that blocks any forward progress for these threads. You can avoid this deadlock
only by ensuring that all threads in the application always acquire all locks in the same order. However, it
isn't always easy to acquire locks in the 'right' order. Software components can be composed, but lock
acquisitions cannot. If your code calls some other component, that component's locks now become part
of your implicit lock order - even if you have no visibility into those locks.
Things get even harder because locking operations include far more than the usual functions for Critical
Sections, Mutexes, and other traditional locks. Any blocking call that crosses thread boundaries has
synchronization properties that can result in a deadlock. The calling thread performs an operation with
'acquire' semantics and cannot unblock until the target thread 'releases' that call. Quite a few User32
functions (for example SendMessage), as well as many blocking COM calls fall into this category.
Worse yet, the operating system has its own internal process-specific lock that sometimes is held while
your code executes. This lock is acquired when DLLs are loaded into the process, and is therefore called
the 'loader lock.' The DllMain function always executes under the loader lock; if you acquire any locks in
DllMain (and you should not), you need to make the loader lock part of your lock order. Calling certain
Win32 APIs might also acquire the loader lock on your behalf - functions like LoadLibraryEx,
GetModuleHandle, and especially CoCreateInstance.
To tie all of this together, look at the sample code below. This function acquires multiple synchronization
objects and implicitly defines a lock order, something that is not necessarily obvious on cursory
inspection. On function entry, the code acquires a Critical Section and does not release it until function
exit, thereby making it the top node in our lock hierarchy. The code then calls the Win32 function
LoadIcon(), which under the covers might call into the Operating System Loader to load this binary. This
operation would acquire the loader lock, which now also becomes part of this lock hierarchy (make sure
the DllMain function does not acquire the g_cs lock). Next the code calls SendMessage(), a blocking
cross-thread operation, which will not return unless the UI thread responds. Again, make sure that the UI
thread never acquires g_cs.
bool foo::bar (char* buffer)
{
EnterCriticalSection(&g_cs);
// Get 'new data' icon
this.m_Icon =
LoadIcon(hInst, MAKEINTRESOURCE(5));
// Let UI thread know to update icon
SendMessage(hWnd,WM_COMMAND,IDM_ICON,NULL);
this.m_Params = GetParams(buffer);
LeaveCriticalSection(&g_cs);
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 79 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
return true;
}
Looking at this code it seems clear that we implicitly made g_cs the top-level lock in our lock hierarchy,
even if we only wanted to synchronize access to the class member variables.
Do:
Design a lock hierarchy and obey it. Add all the necessary locks. There are many more
synchronization primitives than just Mutex and CriticalSections; they all need to be included.
Include the loader lock in your hierarchy if you take any locks in DllMain()
Agree on locking protocol with your dependencies. Any code your application calls or that might
call your application needs to share the same lock hierarchy
Lock data structures not functions. Move lock acquisitions away from function entry points and
guard only data access with locks. If less code operates under a lock, there is less of a chance for
deadlocks
Analyze lock acquisitions and releases in your error handling code. Often the lock hierarchy if
forgotten when trying to recover from an error condition
Replace nested locks with reference counters - they cannot deadlock. Individually locked
elements in lists and tables are good candidates
Be careful when waiting on a thread handle from a DLL. Always assume that your code could be
called under the loader lock. It's better to reference-count your resources and let the worker
thread do its own cleanup (and then use FreeLibraryAndExitThread to terminate cleanly)
Use the Wait Chain Traversal API if you want to diagnose your own deadlocks
Don't:
Do anything other than very simple initialization work in your DllMain() function. See DllMain
Callback Function for more details. Especially don't call LoadLibraryEx or CoCreateInstance
Write your own locking primitives. Custom synchronization code can easily introduce subtle
bugs into your code base. Use the rich selection of OS synchronization objects instead
Do any work in the constructors and destructors for global variables, they are executed under
the loader lock
Be Careful with Exceptions
Exceptions allow the separation of normal program flow and error handling. Because of this separation,
it can be difficult to know the precise state of the program prior to the exception and the exception
handler might miss crucial steps in restoring a valid state. This is especially true for lock acquisitions that
need to be released in the handler to prevent future deadlocks.
The sample code below illustrates this issue. The unbounded access to the "buffer" variable will
occasionally result in an access violation (AV). This AV is caught by the native exception handler, but it
has no easy way of determining if the critical section was already acquired at the time of the exception
(the AV could even have taken place somewhere in the EnterCriticalSection code).
Page 80 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
BOOL bar (char* buffer)
{
BOOL rc = FALSE;
__try {
EnterCriticalSection(&cs);
while (*buffer++ != '&')
;
rc = GetParams(buffer);
LeaveCriticalSection(&cs);
} __except (EXCEPTION_EXECUTE_HANDLER)
{
return FALSE;
}
return rc;
}
Do:
Remove __try/__except whenever possible; do not use SetUnhandledExceptionFilter
Wrap your locks in custom auto_ptr-like templates if you use C++ exceptions. The lock should be
released in the destructor. For native exceptions release the locks in your __finally statement
Be careful with the code executing in a native exception handler; the exception might have
leaked many locks, so your handler should not acquire any
Don't:
Handle native exceptions if not necessary or required by the Win32 APIs. If you use native
exception handlers for reporting or data recovery after catastrophic failures, consider using the
default OS mechanism of Windows Error Reporting instead
Use C++ exceptions with any kind of UI (user32) code; an exception thrown in a callback will
travel through layers of C code provided by the operating system. That code doesn't know about
C++ unroll semantics
Links to Resources
"Introducing Windows Error Reporting": http://msdn.microsoft.com/en-us/isv/bb190483.aspx
Asynchronous Design: http://msdn.microsoft.com/en-us/library/ms228969.aspx
Asynchronous I/O: http://msdn.microsoft.com/en-us/library/aa365683(VS.85).aspx
AttachThreadInput(): http://msdn.microsoft.com/en-us/library/ms681956(VS.85).aspx
auto_ptr: http://msdn.microsoft.com/en-us/library/ew3fk483.aspx
DisableProcessWindowsGhosting (): http://msdn.microsoft.com/en-us/library/ms648415.aspx
DllMain Callback Function: http://msdn.microsoft.com/en-us/library/ms682583.aspx
Events: http://msdn.microsoft.com/en-us/library/wewwczdw.aspx
GetMessage(): http://msdn.microsoft.com/en-us/library/ms644936(VS.85).aspx
I/O cancellation: http://msdn.microsoft.com/en-us/library/aa363789(VS.85).aspx
IsHungAppWindow(): http://msdn.microsoft.com/en-us/library/ms633526.aspx
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 81 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Message Queue: http://msdn.microsoft.com/en-us/library/ms644928.aspx
MsgWaitForMultipleObjects(): http://msdn.microsoft.com/en-us/library/ms684242(VS.85).aspx
New Thread Pool API: http://msdn.microsoft.com/en-us/library/ms686766(VS.85).aspx
PostMessage: http://msdn.microsoft.com/en-us/library/ms644944(VS.85).aspx
Restart and Recovery: http://msdn.microsoft.com/en-us/library/bb525423(VS.85).aspx
SendMessageCallback: http://msdn.microsoft.com/en-us/library/ms644951(VS.85).aspx
SendNotifyMessage: http://msdn.microsoft.com/en-us/library/ms644953(VS.85).aspx
Synchronization Objects: http://msdn.microsoft.com/en-us/library/ms681924(VS.85).aspx
TerminateThread(): http://msdn.microsoft.com/en-us/library/ms686717(VS.85).aspx
Windows Error Reporting: http://msdn.microsoft.com/en-us/library/bb513641(VS.85).aspx
Winqual: https://winqual.microsoft.com/
Page 82 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Deployment Image Servicing and Management (DISM)
Affected Platforms
Clients - Windows Vista SP1 and later | Windows 7
Servers - Windows Server 2008 RTM and later | Windows Server 2008 R2
Description
The Deployment Image Servicing and Management (DISM) tool replaces the pkgmgr, PEImg, and
IntlConfg tools that are being retired in Windows 7. DISM provides a single centralized tool for
performing all of the functions of these three tools in a more efficient and standardized way, eliminating
the source of many of the frustrations experienced by current users of these tools.
DISM includes a shim for Windows Vista SP1 and later as well as for Windows Server 2008 RTM and
later, that redirects pkgmgr calls from legacy applications running on Windows 7 to DISM. If the
application is running on one of the supported operating systems, the shim routes the call to pkgmgr.
No shims exist for legacy applications that call PEImg or IntlConfg.
Usage
DISM is transparent to pkgmgr end users on any of the supported platforms. However, if an application
calls either PEImg or IntlConfg from Windows 7, the call will fail.
Update any scripts that call pkgmgr, PEImg, or IntlConfg to call DISM instead. It is important to include
the updating of pkgmgr scripts in this effort, since the shim that provides backwards compatibility for
pkgmgr will be removed in future versions of the Windows operating systems.
Check to ensure that calls to DISM have replaced any calls to pkgmgr, PEImg, and IntlConfg, and that the
operation executes successfully.
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 83 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Windows Troubleshooting
Affected Platforms
Clients - Windows 7
Servers - Windows Server 2008 R2
Description
A new Windows 7 Action Center (formerly known as Solutions Center) feature, Windows
Troubleshooting, delivers a systematic troubleshooting experience for the user. The Action Center is one
of the five icons pinned in the systray. Windows Troubleshooting allows you to browse or search for inbox troubleshooting packs and for troubleshooting packs that are stored on a Microsoft server on the
Internet - a Better When Connected (BWC) experience. You can select and run a troubleshooting pack to
attempt to try to resolve their problem. If you cannot identify a resolution to the problem, you have the
option of searching help, community content, and support articles, or other troubleshooting packs for
relevant related content. Should that not provide an answer to the problem, you can restore the PC to a
time prior to when the problem occurred or get help through remote assistance. The intent is to allow
you to find a solution to the problem easily and quickly.
Usage
The Action Center is clearly visible and available from several locations. You can launch it from the
context menu of the Action Center in the systray, from the control panel as a shortcut link under system
and maintenance, from the main page of the Action Center, and from Help content.
Troubleshooting packs are based upon powershell scripts. Microsoft is making public the process of
authoring and publishing a troubleshooting pack to allow OEMs, IHVs, ISVs, and IT Professionals to
develop and ship their own troubleshooting content.
For a consistent user experience, be sure to follow the best practices and guidelines described in the
Windows troubleshooting toolkit when designing your own troubleshooting packs.
Page 84 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Windows Error Reporting Problem Steps Recorder
Affected Platforms
Clients - Windows 7
Servers - Windows Server 2008 R2
Description
Prior to Windows 7, Windows Error Reporting (WER) collected error reports that indicated problems in
need of repair. These error reports contain helpful information that describes the general nature of a
problem, but not enough information to determine its root cause. For that, developers need a tool to
reproduce the crash/hang scenario for debugging.
A new application, Problem Steps Recorder (PSR.exe), is shipping on all builds of Windows 7. This
feature enables the collection of the actions performed by a user while encountering a crash so that
testers and developers can reproduce the situation for analysis and debugging.
Usage
Currently, a Windows Error Reporting service developer must request PSR enablement for an
application; Microsoft support organizations also use this tool while troubleshooting with end users.
Plans are in place to make PSR available at Windows Quality Online Services (Winqual) after the release
of Windows 7.
NOTE: With PSR enabled for an application, the application may see some performance degradation.
Links to Other Resources
Windows Error Reporting blog entry:
http://blogs.msdn.com/wer/archive/2009/03/30/problem-steps-recorder-psr-exe-windowserror-reporting-another-tool-to-help-find-solutions-to-software-defects.aspx
Windows Quality Online Services (Winqual): http://winqual.microsoft.com
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 85 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Best Practices for Energy Efficiency
Platform
Clients - Windows XP | Windows Vista | Windows 7
Description
Windows®-based laptops must meet energy efficiency regulatory requirements such as those of the
United States Environmental Protection Agency (EPA) Energy Star program. Furthermore, surveys have
shown that longer battery life continues to be what consumers most want and need in laptops.
To meet consumer demands, Windows laptops must continually advance in the following areas:
Energy efficiency in all usage scenarios, including idle, productivity workloads, DVD and media
playback, and industry benchmarks
Mobile PC battery life - for hardware platforms and for Windows
The Windows platform is highly reliable and enables fast on-and-off performance. However, extensions
provided with mobile PC systems, such as services, system tray applets, drivers, and other software, can
significantly affect performance, reliability, and energy efficiency.
Energy efficiency is a complex problem, with factors affected by and affecting all elements of the PC
ecosystem. Small improvements across multiple scenarios can improve energy efficiency, and yet a
single poorly performing application, device, or system feature can increase energy consumption
significantly.
Hardware and devices form the foundation for energy efficiency. However, application and service
software must also be efficient to allow the system to achieve optimal battery life. Each software
component on the system, including the operating system and value-added applications and services,
must conform to basic efficiency guidelines. A single misbehaving application or service can eliminate
any energy efficiency gains that the latest processor, devices, or platform hardware achieved. For more
detailed information regarding battery life and energy efficiency, please refer to the Battery Life
Solutions Guide located on the Energy Efficiency Portal at
http://www.microsoft.com/whdc/system/pnppwr/mobilepwr.mspx.
The principle issues and components that affect battery life in a mobile PC are:
Battery Characteristics
Size, type, and quality of battery capacity affect battery life
The larger the battery, the greater the power supply
Larger batteries are more expensive and heavier; users prefer lighter systems
Hardware Components
Frequency and depth to which hardware can enter lower power states
Hardware support of lower power states
Driver optimization for energy efficiency
Operating System - Directed Power Management
Efficiency of Windows code while under a load versus while idle
Cooperation level of all components with Windows-directed power management
Page 86 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Proper configuration of OS to optimize for power management through power policy settings
Application Software and Services
Efficiency of applications, drivers, and services while under a load versus while idle
Cooperation level of applications with Windows - directed power management
Software allowance of the system or devices to enter into low-power idle states
A single application or service component can prevent a system from realizing optimal battery life.
Although Windows provides many power configuration options, preinstalled software or power policy
settings on many systems are not optimized for the host hardware platform.
A common method for evaluating the battery-life impact of preinstalled software is to compare the
power consumption of the system with a clean installation of Windows versus a Windows installation
that includes value-added software and services. Although a clean installation does not represent the
typical platform that OEMs ship to customers, the power consumption comparison can provide insight
into the energy-efficiency of preinstalled software.
Best Practices
To ensure that your application is optimized on Windows platforms, follow these best practices when
you design applications or services:
Avoid use of high-resolution periodic timers
Using high-resolution periodic timers (<10 ms) reduces the efficiency of processor powermanagement technologies.
Invest in performance optimizations
Every performance optimization is a battery life optimization. Reductions in required resources,
such as using less processor time or batching/clustering disk reads, allow system hardware to
become idle and enter low-power modes.
Adjust to user power policy
Windows Vista and later make it easy for the user to choose the overall power-savings or
performance behavior of the system. Your application should respond to changes in power
policy and reduce resource usage or increase performance accordingly. For example, an
application should disable background activity such as indexing or system scanning when the
user has selected a Power Saver power plan.
Reduce resource usage when the system is on battery power
Your application should reduce its resource usage - such as background update frequency - when
the system is on battery power.
Do not render to the display when it is off
The system display might be off for power savings. Your application should not perform
unnecessary graphics rendering when the display is off because this wastes system resources
and power.
Avoid polling and spinning in tight loops
Heavy processor usage reduces the effectiveness of processor power-management technologies
such as processor idle states and processor performance states.
Do not prevent the system from turning off the display or idling to sleep
Your application should make judicious power requests with the SetThreadExecutionState API.
The system should make these requests only when critical operations must delay the system
from powering off the display or automatically entering sleep.
Respond to common power-management events
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 87 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Your application should register for and respond to common power-management events, such
as system power-source changes and power-on and power-off notifications for the display.
Do not enable debug logging by default; use Event Tracing for Windows instead
Periodic debug logging can prevent disk spin-down.
Links to Other Resources
Battery Life Solutions Guide:
http://www.microsoft.com/whdc/system/pnppwr/mobile_bat.mspx#
Energy Efficiency Portal: http://www.microsoft.com/whdc/system/pnppwr/mobilepwr.mspx
Windows Performance Toolkit:
http://www.microsoft.com/whdc/system/sysperf/perftools.mspx
Page 88 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Best Practices for Minimizing Unresponsive Services
Affected Platforms
Clients - Windows Vista | Windows 7
Description
Unresponsive services can result in timeouts, terminated sessions, and even lost data. Employing best
practices can greatly reduce the occurrence of unresponsive services.
Best Practices
Make sure your applications and all of their dependent services and drivers respond to system power
and shutdown notifications.
All applications should respond promptly and appropriately to shutdown messages such as
WM_QUERYENDSESSION and WM_ENDSESSION that indicate a shutdown is in progress.
All services should promptly respond to SCM shutdown notifications. If they fail to do so, the
machine treats them as unresponsive, initiates a 20-second timeout, and kills them opening up
the possibility of lost data. This also adds 20 seconds to the shutdown time of a machine
shutdown.
All services that have kernel device-driver dependencies should respond promptly and
appropriately to IRP_MJ_SHUTDOWN notification in their DispatchShutdown routines.
Links to Other Resources
Windows Performance Toolkit: http://www.microsoft.com/whdc/system/sysperf/perftools.mspx
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 89 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Windows 7 Client Software Logo Program
Affected Platforms
Clients - Windows 7
Description
In the Windows 7 timeframe, we want to expand the Logo Program so that it is more relevant to
customers. Based on partner and customer feedback, the Windows 7 Logo Program focuses on ensuring
that devices, systems, and applications are compatible, reliable, and can perform to meet Windows
standards. The program for Windows 7 will have only one logo for systems, devices, and applications.
This topic focuses specifically on client software compatibility.
We have improved the process to qualify software applications for the "Compatible with Windows 7"
logo. Microsoft will no longer require developers to have their applications tested for certification by
authorized testing authorities. Instead, Microsoft is developing a logo toolkit that you can use to ensure
that your application is compatible with Windows 7, and meets the Windows 7 Client Software Logo
Program requirements. We have significantly reduced the number of requirements. Similar to the
hardware program, we have created some policies; while not linked to specific test cases, we will
enforce these policies. Partners must meet all requirements and observe all policies for their software
applications to qualify for the "Compatible with Windows 7" logo.
Process
When software applications are ready to be tested, go to the Microsoft Connect Windows 7 Software
Logo Program page and follow the instructions:
1. Start early
Review the requirements and identify any code changes necessary to meet them.
2. Use the alpha self-test tool for verification
Download and install the latest release of the toolkit. Note the 64-bit architecture and OS
requirements in the readme.txt file. Run your application through the toolkit as explained in the
overview to verify the application’s compliance against the requirements.
3. Make any code changes (if necessary) and retest
If any changes to the application are needed to comply with the requirements, make the
necessary changes and retest with the toolkit to verify compliance.
4. Opt-in to receive email notifications
Microsoft will begin accepting Logo submissions with the release of the beta toolkit due out the
end of May. We strongly encourage you to opt-in to receive email notifications when the
toolkit is released and when the program opens for submissions.
The following steps can be taken only after the beta toolkit is released:
5. Download the beta toolkit, test, and submit for the Logo
Once the beta toolkit is available, download, install, and test your application. Submit the
passing results to Microsoft.
Page 90 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
6. Sign the Software Logo License Agreement
Once passing results have been submitted, sign the license agreement at:
http://winqual.microsoft.com.You can then download and begin to use the Logo artwork and
will be eligible to receive all the available Logo benefits.
Links to Other Resources
Windows 7 Logo Program Overview: http://msdn.microsoft.com/enus/windows/dd203105.aspx
Windows Application Compatibility Resources: http://msdn.microsoft.com/enus/windows/aa904987.aspx
Microsoft Connect Windows 7 Software Logo Program page:
https://connect.microsoft.com/site/sitehome.aspx?SiteID=831
Windows 7 Software Logo Requirements: http://go.microsoft.com/?linkid=9630189
Windows 7 Software Logo Toolkit - Beta 2:
https://connect.microsoft.com/Downloads/DownloadDetails.aspx?SiteID=831&DownloadID=190
72
Client Logo Mailbox: SWLogo@Microsoft.com
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 91 of 93
Tel: 0333 101 1000 Email: software@entatech.com
www.entaonline.com
Windows Server 2008 R2 Logo Program for Software
Affected Platforms
Servers - Windows Server 2008 R2
Description
We want to continue building on the success of Windows and expand the logo program so that it is
more relevant to customers. Based on partner and customer feedback, the Windows Server 2008 R2
logo program will focus on ensuring that devices, systems, and applications are compatible, reliable and
can perform to meet Windows standards.
Microsoft has focused the Logo Program on fundamentals that enable partners to innovate and reward
them for their deeper technical investments through additional qualifications (AQs). AQs increase the
visibility of key technologies by recognizing the investment and easily identifying them for customers.
Information on the logo program, including AQs, will be available at InnovateOn: Windows Server 2008.
The process for qualifying server applications for Windows Server 2008 R2 is similar to that for Windows
Server 2008. There are five Requirement Chapters for Logo certification:
Windows Fundamentals
Install and uninstall
Security
Reliability and high availability
Hyper-V compatibility
Each chapter contains specific requirements that the application must meet. Requirements are further
divided into deterministic tests.
Three Server Logo program tools are available to help test for the requirements, the Certification Tool,
the Works with Tool, and the Windows System State Analyzer. All are included in the Software
Certification Toolkit. Downloads are available here:
Software Certification Toolkit x64
Software Certification Toolkit x86
New for Windows Server 2008 R2:
The Windows 7 Compatibility Logo self-test is an important change in the Windows Server 2008 R2 Logo
program.
Server Logo certification already includes the required tests for Client components
Test vendors will test all Client components that are part of the Server application concurrently
against all applicable test cases in the Certified for Windows Server 2008 R2 test framework as
part of the testing efforts for Server Certification
Client components of Server applications passing all the required tests under the Certified for
Windows Server 2008 R2 Logo Program may receive the Windows 7 Compatibility Logo by selftesting with the Windows 7 Software Logo Toolkit
Applications may also add the Hyper-V designation if all testing is performed on a Hyper-V based
virtual machine and requirements in Chapter 6 are also met
Page 92 of 93
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Revised: March 20, 2010
Process
The Logo certification process includes both self-testing and a third party test. An authorized third party
testing vendor performs most of the tests. However, some long-term and Cluster tests must be done by
the ISV developers themselves.
When you are ready to consider Logo certification:
1. Download the Software Certification Toolkit from the InnovateOn Web site. (no registration or
fee required).
2. Evaluate your applications against the technical bar.
o First level help for technical questions and clarifications is available at an MSDN Forum.
o Second-level help is available via a dedicated mailbox at WsLogoFB@Microsoft.com.
3. All application drivers must pass Windows Hardware Quality Labs (WHQL) tests and be signed
specifically for R2 by WHQL. This also applies to drivers already WHQL-signed for Windows
Server 2008. The WHQL Submission ID is required for Logo qualification. Get started with
WHQL.
4. Certain self-test logs need to be made available before Final certification is complete (for
example, long-term stress tests are self-tested by the ISVs; the Test Vendor only requires
interpretable logs).
5. When you are ready to submit your application for official testing, contact one of our authorized
test vendors who will guide you from that point. Contact information is available at InnovateOn.
If all tests are successful, Microsoft will grant you the right to use the "Certified for Windows Server"
logo on your packaging and in your advertising.
If any tests fail, Microsoft may assist you in resolving the failure, including evaluating waiver requests
where applicable.
Links to Other Resources
Server Logo Program Certification Tool x86: http://go.microsoft.com/fwlink/?LinkID=140110
Server Logo Program Certification Tool x64: http://go.microsoft.com/fwlink/?LinkID=140109
Get Started with WHQL: http://www.microsoft.com/whdc/winlogo/getstart/default.mspx
Server Logo Mailbox: WsLogoFB@Microsoft.com
MSDN Forum: http://social.msdn.microsoft.com/forums/enUS/winserver2008appcompatabilityandcertification/threads/
Windows Quality Online Services (Winqual): https://winqual.microsoft.com
Revised: March 20, 2010
Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
Microsoft Confidential
Page 93 of 93
