Version 1.7
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
[pic] Tel: 0333 101 1000 Email: software@
Table of Contents
Introduction 5
Compatibility 7
General Compatibility 7
Operating System Versioning 8
Removal of Windows Mail 10
Removal of Windows Movie Maker 12
NLS Sorting Changes 13
Internet Explorer 8 - User Agent String 16
Additional Windows Resource Protection on Registry Keys 18
Removal of Microsoft Agent 20
AppInit_DLLs in Windows 7 and Windows Server 2008 R2 21
Removal of Windows Registry Reflection 22
Removal of WPDUSB.SYS Driver for Windows Portable Devices 24
Microsoft Message Queuing (MSMQ) - SHA-2 Is the Default Hash Algorithm 25
Windows Server 2008 R2 Compatibility 27
File Replication Service (FRS) Is Deprecated in Windows Server 2008 R2 28
Microsoft Message Queuing (MSMQ) - Removal of Windows 2000 Client Support Service 29
New Low-Level Binaries 30
Removal of UDDI Services from Server OS 31
64-Bit Only 33
WoW64 Is Now an Optional Feature for Server Core 35
Subset of .NET 2.0 Now on Server Core 36
.NET 3.0 and 3.5 Now on Server Core 37
New Features and Enhancements 38
File Library Replaces Document Folder 39
User Interface - High DPI Awareness 40
Fault Tolerant Heap 42
Internet Explorer 8 - Data Execution Protection/NX 43
User Interface - User Account Control Dialog Updates 45
ChooseFont() Win32 Common Dialog 46
Application Manifest 48
Server Hyper-V 51
Microsoft Message Queuing (MSMQ) - Improved Queue Handling 53
Remote Desktop Services 54
Tools, Best Practices, and Guidance 56
Application Compatibility Toolkit (ACT) 5.5 57
Compatibility Administrator 58
Standard User Analyzer (SUA) Tool and Standard User Analyzer Wizard (SUA Wizard) 59
Application Verifier 61
Best Practices for On/Off Performance 65
Preventing Memory Leaks in Windows Applications 67
Preventing Hangs in Windows Applications 70
Deployment Image Servicing and Management (DISM) 78
Windows Troubleshooting 79
Windows Error Reporting Problem Steps Recorder 80
Best Practices for Energy Efficiency 81
Best Practices for Minimizing Unresponsive Services 84
Windows 7 Client Software Logo Program 85
Windows Server 2008 R2 Logo Program for Software 87
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 (). 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
[pic] Tel: 0333 101 1000 Email: software@
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
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
• Win98VersionLie
• WinNT4SP5VersionLie
• Win2000VersionLie
• Win2000SP1VersionLie
• Win2000SP2VersionLie
• Win2000SP3VersionLie
• WinXPVersionLie
• WinXPSP1VersionLie
• WinXPSP2VersionLie
• VistaRTMVersionLie
• VistaSP1VersionLie
• VistaSP2VersionLie
• Win2K3RTMVersionLie
• Win2K3SP1VersionLie
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:
Known Compatibility Fixes, Compatibility Modes, and AppHelp Messages:
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
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:
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.
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 |
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.
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: (VS.85).aspx
GetNLSVersionEx: (VS.85).aspx
GetNLSVersion: (VS.85).aspx
How to tell if the collation version changed:
Handling Locale and Language Information: (VS.85).aspx
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.
Links to Other Resources
Understanding User Agent Strings: (VS.85).aspx
The Internet Explorer 8 User-Agent String:
User-Agent String and Version Vector:
Hosting and Reuse: (VS.85).aspx
Application Compatibility Toolkit Download:
Known Internet Explorer Security Feature Issues:
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
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: (VS.85).aspx
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) -
• Merlin Character File -
• Peedy Character File -
• Genie Character File -
• Robby Character File -
Links to Other Resources
Microsoft Agent Resources:
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 |Globally enables or disables AppInit_DLLs. |0x0 – AppInit_DLLs are disabled. |
|(REG_DWORD) | |0x1 – AppInit_DLLs are enabled. |
|AppInit_DLLs |Space or comma delimited list of DLLs to load. The|C:\ PROGRA~1\WID288~1\MICROS~1.DLL |
|(REG_SZ) |complete path to the DLL should be specified using| |
| |Short Names. | |
|RequireSignedAppInit_DLLs |Only load code-signed DLLs. |0x0 – Load any DLLs. |
|(REG_DWORD) | |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.
Links to Other Resources
Additional Information:
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.
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 - (VS.85).aspx
• Redirected keys list within Registry Redirector article - (VS.85).aspx
Best Practices for Wow64 -
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.
Links to Other Resources
Windows Portable Devices: (VS.85).aspx
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.
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
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:
• Distributed File System Replication: Frequently Asked Questions: (WS.10).aspx#BKMK_035)
• SYSVOL Replication Migration Guide: FRS to DFS Replication: (WS.10).aspx
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.
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.
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 services-oriented 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.
Links to Other Resources
Microsoft UDDI Services Web site:
UDDI specifications:
UDDI Services v3.0 download for Windows Server 2008 R2:
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, 32-bit 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
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: (VS.85).aspx
Performance and Memory Consumption: (VS.85).aspx
WoW64 Implementation Details: (VS.85).aspx
Registry Redirector: (VS.85).aspx
File System Redirector: (VS.85).aspx
Memory Management: (VS.85).aspx
Processor Affinity: (VS.85).aspx
Interprocess Communication: (VS.85).aspx
Application Installation: (VS.85).aspx
Debugging WoW64: (VS.85).aspx
Is WoW64 Process Running: (VS.85).aspx
Get Native System Info: (VS.85).aspx
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: (VS.85).aspx
Debugging WoW64: (VS.85).aspx
Server Core: (VS.85).aspx
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: (VS.85).aspx
• Server Core Blog:
• See also the Server Core section of the Windows Server 2008 R2 SDK when it becomes available
.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: (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
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
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: (VS.85).aspx
• Keeping in sync with a library: (VS.85).aspx#library_keeping_in_sync
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 |What to look for |
|1024x768 @ 120 DPI (125% scaling) |This is an effective resolution of ~800x600, so look for UI clipped off the screen |
|[Note: If your app requires 1024x768, then do this |or layout issues. Also look for pixilated bitmaps and icons. |
|test at 1280x960] | |
|1600x1200 @ 144 DPI (150% scaling) |Blurry UI. Verify that all mouse operations work, especially drag-and-drop |
| |operations. Also, verify full-screen modes work properly. |
|1600x1200 @ 144 DPI with DPI Virtualization |Often buttons and UI will not scale in relation to larger text and there will be |
|disabled. |significant text clipping. Look for layout issues in general and pixilated bitmaps |
| |and icons. |
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: for the PDF version or for the Windows XPS version or
(VS.85).aspx for the MSDN online version
Contact for technical questions: disup@
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-Tolerant-Heap
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.
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)
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:
Data Execution Prevention:
New NX APIs added to Windows Vista SP1, Windows XP SP3 and Windows Server 2008 R2:
Application Compatibility Toolkit Download:
Known Internet Explorer Security Feature Issues:
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:
• Application Compatibility Toolkit Download:
• Standard User Analyzer:
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.
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.
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.
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:
0. {e2011457-1546-43c5-a5fe-008deee3d3f0} for Windows Vista: This is the default value for the switchback context.
0. {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.
An XML example of an updated manifest:
Note: The attribute and tag names in the application manifest are case sensitive.
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
0. Test the application with the new compatibility section and SupportedOS ID ={35138b9a-5d96-4fbd-8e2d-a2440225f93a} to ensure that the application works properly using the latest Windows 7 behaviors
0. Test the application with the new compatibility section and SupportedOS ID ={e2011457-1546-43c5-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 for additional details and to download the correct version for your system.
Links to Other Resources
• QueryActCtxW Function: (VS.85).aspx
• UAC manifest:
• Application manifests for Windows applications: (VS.85).aspx
• Desktop Window Manager (DWM):
• Context Mismatch Patch:
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.
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 (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.
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.
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 64-bit 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.
• 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: (VS.85).aspx
Terminal Services at TechNet:
Terminal Services product homepage:
Application Readiness for Terminal Services whitepaper:
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
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:
• Introduction to the Application Compatibility Toolkit:
• Application Compatibility Toolkit Technical Reference:
• ACT Walkthrough Exercises:
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.
[pic]
Links to Other Resources
• Application Compatibility Toolkit Download:
• Using the Compatibility Administrator:
• Known Compatibility Fixes, Compatibility Modes, and AppHelp Messages:
• Testing and Mitigating Issues by Using the Development Tools:
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.
[pic]
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.
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.
[pic]
Links to Other Resources
• Application Compatibility Toolkit Download:
• Understanding the Standard User Analyzer Tools:
• Standard User Analyzer Technical Reference:
• Testing and Mitigating Issues by Using the Development Tools:
• Application Compatibility and User Account Control:
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
• 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 |Description |
|Restricted Namespaces |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. |
|Hard Administrator Checks |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. |
|Requesting Privileges |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. |
|Missing 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. |
|INI-File Operations |Attempts to write to mapped INI files (WritePrivateProfileSection and similar APIs) can fail as a |
| |non-administrator user. |
| |LuaPriv flags such operations. |
|Access Denied |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. |
| |LuaPriv flags object-open attempts that fail with ACCESS_DENIED and similar errors. |
|Deny ACEs |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. |
|Access Restricted |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. |
|MAXIMUM_ALLOWED |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.
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:
Online documentation:
Application Verifier:
Overview:
Download:
For Microsoft Visual Studio 2008/.NET Framework 3.5:
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):
Windows Error Reporting: Getting Started:
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
• 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
• On/Off Transition Performance Analysis of Windows Vista
• Windows Performance Analysis
• Windows Performance Toolkit documentation on MSDN
• Windows Performance Analysis forum
• Event Tracing for Windows on MSDN
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.
[pic]
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: (VS.85).aspx
• Memory Allocation Function:
• New Operator (C++):
• Virtual Allocation Function: (VS.85).aspx
• Kernel Objects: (VS.85).aspx
• GDI Object Handles: (VS.85).aspx
• User Interface Object Handles:
Microsoft Tools:
• Application Verifier: (VS.85).aspx
• Debugging Tools for Windows:
• User-Mode Dump Heap:
• Trace Capture, Processing, and Analysis Tool:
• CRT Debug Heap:
Additional Links:
• auto_ptr Class:
• Active Template Library (ATL) Memory Classes:
• _com_ptr_t Object:
• _bstr_t Class:
• _variant_yt Class:
• "Tracking down managed memory leaks":
• "Understanding and Solving Internet Explorer Leak Patterns":
• "JavaScript Memory Leak Detector":
• Circular Memory Leak Mitigation (in browsers): (VS.85).aspx
• try-finally statement:
• PROPVARIANT Structure: (VS.85).aspx
• PropVariantClear Function: (VS.85).aspx
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.
The whole ghost experience looks like this:
[pic]
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 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
[pic]
• 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:
[pic]
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 long-running operations. The following sections introduce some of the best practices in preventing hangs and highlight some of the common pitfalls.
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
• 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);
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).
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":
• Asynchronous Design:
• Asynchronous I/O: (VS.85).aspx
• AttachThreadInput(): (VS.85).aspx
• auto_ptr:
• DisableProcessWindowsGhosting ():
• DllMain Callback Function:
• Events:
• GetMessage(): (VS.85).aspx
• I/O cancellation: (VS.85).aspx
• IsHungAppWindow():
• Message Queue:
• MsgWaitForMultipleObjects(): (VS.85).aspx
• New Thread Pool API: (VS.85).aspx
• PostMessage: (VS.85).aspx
• Restart and Recovery: (VS.85).aspx
• SendMessageCallback: (VS.85).aspx
• SendNotifyMessage: (VS.85).aspx
• Synchronization Objects: (VS.85).aspx
• TerminateThread(): (VS.85).aspx
• Windows Error Reporting: (VS.85).aspx
• Winqual:
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.
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 in-box 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.
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:
• Windows Quality Online Services (Winqual):
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 .
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
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 ( ................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.