Creating Quality Applications: Roadmap

Modern users want to have their applications "just run." This means users should be able to run and use applications that are immediately compatible with their environment, avoiding complex installations and configuration operations. Their settings should follow them when they migrate from one computer to another and in roaming situations.

Windows Vista® provides developers with a complete set of tools for creating high-quality applications that will not compromise system stability, and will provide solid performance.

For more information on writing quality applications, see Guidelines for Creating Quality Applications.

State Separation

State separation (the isolation of per-user settings, per-computer configuration, user data and code) provides users with two principal benefits. Using state separation in an application makes it easier for roaming users to access their applications, and allows the creation of new features for finding, sharing and managing user data. Effective state separation for Windows Vista applications requires abstracting resource access (such as file system and registry access) by using Known Folders.

A C-callable set of libraries extends the CSIDL technology and its APIs (such as SHGetFolderPath and SHGetFolderLocation). Using these libraries, application developers can avoid hard-coding file or registry paths or making assumptions as to the actual physical layout of data on disk. Instead, they can use the extended versions of the CSIDL functions (such as SHGetFolderPathEx and SHGetFolderLocationEx) to query the system for locations. Unlike the previous CSIDL mechanism, Known Folders is an extensible technology, with a COM interface for adding custom locations. For more information about developing with Known Folders, see Developing Quality Applications with Known Folders.

Data and Application Recovery

Windows Vista developers can ensure users will not lose data or work because of a software problem or system instability. For example:

  • A well-defined mechanism is provided so that all user-mode applications can register themselves as restartable and provide document recovery interfaces.

  • Used in conjunction with the Restart Manager, Windows Vista application and data recovery mechanisms make application installation and upgrading less invasive, preserving the running state of applications that need to be interrupted for system reconfiguration.

  • These mechanisms, which are part of Windows Feedback, support error handling and reporting.

Developing Applications That Can Be Updated Without Reboots

To minimize interruptions to a user's work, Microsoft has invested in reducing the situations in Windows Vista where it will be necessary to reboot the system to install updates.

  • Microsoft Installers and patch management tools use the Restart Manager to install updates without reboots.

  • Restart Manager can identify which applications and services have files in use, gracefully stopping those applications and services without the need to restart the entire computer.

  • Applications that are written to take advantage of the new Restart Manager features can be restarted and restored to the same state and with the same data as before the restart.

  • When reboots are unavoidable, the Restart manger should allow them to be undertaken with minimum disruption to a user's work flow.

For more information, see Restart Manager Development.

Windows Feedback

Windows Vista provides enhanced feedback and diagnostic mechanisms to developers through Windows Feedback, which extends the Windows Error Reporting feature found in earlier releases of Windows. The features include:

  • Making it easier to detect and obtain information for common scenarios, such as when an application or the computer stops responding

  • Allowing the specification and collection of additional data during error handling

  • Adding new diagnostic scenarios for reporting

In addition to providing statistical, historical information and feedback to Microsoft for operating system problems, Windows Vista supports an enhanced version of its error reporting and tracking technology.

Windows Vista provides mechanisms for collecting and reporting both incident and longitudinal data about application behavior and problems as part of Windows Feedback, and its constituent Windows Error Reporting service. By default, these technologies allow quick and efficient handling of operating system-generated unrecoverable errors, and can be extended to handle supporting feedback to application developers as well. Such support has already been produced, and is familiar to users through the well-known feedback windows that accompany unrecoverable errors. Windows Vista provides an extensible reporting environment, online problem tracking and a development community.

Developers can collect the data needed to debug problems from instances of their applications running in the field. This information is used to generate reports that are archived and studied at a Microsoft portal site. The portal allows Microsoft staff to provide feedback for product improvement to developers, provide users with information about workarounds or updates, and deliver fixes to resolve issues. This technology supports system administrators and other IT professionals by allowing them to:

  • View the history of errors on a computer to aid in troubleshooting

  • Create policies to control the reporting behavior of desktop computers in a corporation

To aid in viewing and managing error reports created by error reporting clients, Microsoft provides the Corporate Error Reporting (CER) tool that can be downloaded from the Microsoft Corporate Error Reporting (http://www.microsoft.com/resources/satech/cer/) site. Users benefit from improvements to their applications, and by having error handling with a consistent look and feel native to Windows Vista. Users can expect:

  • Streamlined data collection and user interface, reducing wait time when forwarding an error report

  • A simple mechanism to cancel reporting

  • A global opt-in mechanism, automating user response to error report requests

  • Improved customer feedback that allows users to search for a solution, including automatic solution checking

  • More secure and reliable data collection and transport

  • Better protection of customer privacy and intellectual property

  • Improved ease of management for both users and administrators

  • Increased support for offline scenarios

Application Data Collection and Reporting

Windows Vista introduces Windows Feedback interfaces to allow developers to instrument code for continuous quality improvement (by making use of the Windows default error handling and reporting mechanisms) or to customize their error handling.

Standard Application Failure Reporting

The standard failure report transparently provides all participating applications with a rich source of information about problems. Applications can opt out of failure reporting. For more information, see Windows Feedback Services.

The automatic support for detailed error reporting is performed through:

  1. Default failure discovery support.

    1. User-mode application failures are detected by the Windows operating system's unhandled exception filter (UEF), which detects all events that are not explicitly handled by an application.

      Although applications should continue to handle all ordinary or benign exceptions — such as those returned on file-open failure — developers do not need to implement their own unhandled exception filter (typically created by implementing the UnhandledExceptionFilter function).

      It is generally recommended that most applications remove any such custom UEF or unrecoverable-error handling in favor of having the operating system handle these events. If an application developer chooses to trap and handle unrecoverable errors, he or she can still make use of the automated failure reporting by rethrowing those errors to the operating system.

      For more information on the unhandled exception filter and custom UEF implementations, see the SetUnhandledExceptionFilter and UnhandledExceptionFilter functions in the Windows SDK

    2. The shell attempts to detect application failures, using as a basis:

    • Application failure to respond to Windows messages in less than five seconds.

    • Failures initiated by a user when accessing an application's top-level user interface.

  2. An error-handling interface for users redesigned from the error-handling popups found in earlier releases of Windows. This interface:

    • Requests user consent before submitting error reports, and allows automated report submission.

    • Allows users to check for possible solutions for the recent application or system failure.

    • Provides access to data and applications state recovery, as well as automatic application restart (if supported by the application).

    • In the case of suspected application failures, offers users the option of terminating an application or waiting for it to end. The latter is useful in cases such as large data transfers, where the user knows the application will be dormant for a period.

  3. The automated preservation of the state of a failing application in minidump and heap dump files. For more information on working with dump files, see Debugging OCA Minidump Files on the Windows Quality Online Services (WinQual) portal, or "Minidump Files" and "Dumps" sections of the Windows SDK.

  4. The submission of standard error reports for all failures detected by the operating system to a centralized location managed by Microsoft (the Windows Quality Online Services site) and accessible to participating developers through WER. This transparently provides applications with a robust report transport mechanism that includes message queuing (with support for offline systems) and the smooth uploading of large files (such as CABs) through the Background Intelligent Transfer Service (BITS) mechanism. For more information on BITS, see "Background Intelligent Transfer Service" in the Windows SDK.

Customizing Standard Report Data

Windows Vista provides additional error reporting functionality, which allows developers to augment standard failure reports. This allows developers to include more and different information than is necessarily contained in the default error report.

Applications simply need to register as providing custom feedback at startup, and then can optionally set reporting preferences and add files, data structures, and memory location for inclusion in the error handling report.

For more information about the APIs and development practices, see Windows Feedback Services.

Creating Custom Reports for Application and System Failures

In addition to using standard reporting or adding new data to a standard error report, the client is architected to allow the creation of customized report types, called generic reporting. Generic reporting gives application developers greater control over when error reports are generated, what these reports contain, and how these reports are categorized or "bucketed." However, generic reporting is not currently supported.

For more information about the APIs and development practices, see Windows Feedback Services.

System Failures

In addition to support for application failures, Windows Vista provides an improved Online Crash Analysis (OCA) Service to help with the analysis of system failures. If an error causes the system to stop responding or objects on your screen disappear, the system state information will be saved, including minidump files and heap data. This information (depending on the system configuration) is either forwarded to Microsoft for examination upon successful restart and reattachment to the Internet, or can be manually forwarded through the Event Reporting Console (ECR). In this way, the reporting of system failures is fully and seamlessly integrated into the same robust reporting system as is used for reporting application failures.

Users can also use the ECR to obtain feedback from Microsoft about possible fixes.

Error Report Collection

Through Windows Quality Online Services (WinQual), available at winqual.microsoft.com, Microsoft provides a centralized repository and database for the collection and dissemination of problem reports across the full range of Windows development.

The WinQual application guarantees the following benefits:

  • Increased application visibility

  • Access to user-generated product feedback

  • The Windows development community and analysis aids

  • Improved privacy and intellectual property protection

For more information about WinQual, visit the Windows Quality Online Services Online Help site.

Application Visibility

Qualifying applications are listed and described in the Windows Catalogs, Windows Marketplace, and other directories managed by or relating to Microsoft-based software. For more information on the Windows Catalog listing and Windows Marketplace, see the WinQual portal site at winqual.microsoft.com. Thus, users can learn of a product's features and determine whether to use the application.

The WinQual system can also act as an information conduit. Users can obtain information on how to fix problems, obtain upgrades, and work around known issues.

Product Feedback

Through WinQual, a developer can retrieve user failure data for applications running in the field, categorized and ready for analysis. The objective is to have data acquisition with security and minimal impact on the user.

When the portal receives a report from a user, that user's personal identity information is sanitized, and then the data is categorized. This categorization is determined using the report's event parameters (text descriptors of the event), as well as (if appropriate) hard data from the user's system (for example, minidump files are required to categorize operating-system failures that display a blue screen and an error message).

In addition, the WinQual system tracks problem information on the basis of the hardware vendor, software vendor, or system manufacturer. Because of this error report categorization, development teams participating in WinQual can use the portal as a problem database and track the frequency and severity of common user problems.

Error Analysis and the Development Community

By querying the WinQual portal, participating developers can obtain all problem reports associated with one of their registered products.

The WinQual portal analyzes the data to locate the source of the problem, and then provides solutions both through the user error dialog boxes and by providing updated files on Windows Update.

To support error analysis, the WinQual site provides detailed and easily accessible information on debugging, including instructions on how to read application dump files, a knowledge base, and a means for creating bugs against the Windows operating system.

In addition to debugging help, through Windows Hardware Quality Labs (WHQL), developers can receive technical help and guidance in state-of-the-art testing design and certification.

Forums and discussion groups are also available. Microsoft support staff monitors both discussions and error data to improve the Windows operating system itself.

Privacy and Intellectual Property Protection

Microsoft guarantees intellectual property protection through the WinQual site. Vendor-specific data is available only to developers of properly registered applications and only for their own applications. User privacy is ensured by the user interfaces and Microsoft privacy policy, which can be seen at the Microsoft Online Privacy Notice Highlights site. The WinQual system will never automatically collect data containing personal user information without first prompting users.

The Event Reporting Console

The Event Reporting Console (ERC) compliments Windows Feedback with its ability to report issues to Microsoft, by providing accurate, actionable responses back to the user about problems.

With the Event Reporting Console users, developers, and system administrators have a simple and efficient location to:

  • View problem events that have occurred on their systems

  • Track their reports to resolution

  • Manage responses from Microsoft

  • Act on these responses to prevent future issues

By using the ERC, a developer, user or IT professional can:

  • Obtain a list of which applications have failed or stopped responding on a particular computer

  • Check for updates and information on problems

  • Obtain access to minidump files and heap dump files from failed applications

  • Control which error reports are sent to WinQual

Corporate Error Reporting

In an enterprise environment, users who might send error reports and other information to the WinQual portal might not understand the security and privacy implications of their action. It is possible that error reporting might compromise sensitive information. Therefore, in a corporate environment, it is important to provide a way to control what data is sent to Microsoft based on the contents of the report.

Windows Vista provides Corporate Error Reporting (CER) functionality (a part of Microsoft Operations Manager server software) as a tool to manage reporting across an enterprise. CER allows an organization to control, enable or disable error reporting across the organization or on a computer-by-computer basis. More importantly, it allows for the redirection of error reports to internal servers, instead of submitting the information directly to the WinQual portal. IT staff can then review the information and submit only selected reports for analysis, screening any sensitive data.

The CER can be configured with a complete set of analysis and debugging engines stored locally on the corporation's network. Reports created within the enterprise can then be processed locally with only high-level aggregate data about the event sent to the portal.

The information in the CER reporting interface can be used to:

  • Help Operations and Helpdesk track down the cause and possible solution for specific failures on a network

  • Determine the types of errors that users are experiencing most frequently

  • Make Total Cost of Ownership (TCO) analyses and recommendations for the organization

  • Certify system components, applications and hotfixes before deployment

  • Monitor the general health of systems and applications within an organization

  • Directly escalate important issues to Microsoft Product Support Services (PSS)

For more information on Corporate Error Reporting, visit the Microsoft Corporate Error Reporting site.

I/O Cancellation Management

To prevent application failure or the appearance of application failure due to an unresponsive I/O operation, Windows provides developers with technology for managing the duration and cancellation of I/O operations. To avoid becoming unresponsive to users all applications, DLLs, plug-ins, or controls that could block on a hung synchronous I/O operation should make use of I/O cancellation. It is also worthwhile to use this feature for asynchronous I/O if the failure of the I/O operation could eventually result in an unresponsive application.

Applications that use this feature must either be multithreaded or use asynchronous I/O operations. They must be coded and tested properly because either the I/O operation or the I/O cancellation can fail, or both. Included in this design is proper UI to notify the user about the disposition of the I/O operation and to provide confirmation or alternate choices before I/O operations are cancelled.

For more information, see I/O Cancellation.

Diagnostics and Performance Tuning

The Windows Vista infrastructure provides developers new technologies for improving the health and performance of their applications.

Diagnostics

The Windows Diagnostic Infrastructure (WDI) in Windows Vista makes it possible for applications to define algorithms for the automatic detection, reporting, diagnosis and solving of a set of scenarios. Although the initial release of WDI in Windows Vista does not have an associated developer API, WDI works with other technologies, such as the Microsoft Event Tracing for Windows (ETW) service, to improve its functionality.

Event Reporting and Tracing

Windows Vista provides enhanced event logging through its new implementation of the Microsoft Event Tracing for Windows (ETW) and a new Windows Event Logging Service. These provide developers with a high-performance, low-overhead and highly scalable tracing facility featuring:

  • Better scalability because of a redesigned architecture and features such as non-blocking I/O, using per-processor buffers and a separate writer thread.

  • Support for detailed tracing in production mode by dynamic enabling or disabling, removing the need for special logging executables.

  • Improved reliability over its predecessor, the NT Event Log, while preserving complete compatibility and functionality with the existing APIs.

  • New XML support. Event structure can be declared in the application manifest and viewed as XML in the Event Viewer and by monitoring applications.

  • Provides better manageability and discoverability. For example, cross-log querying and end-to-end tracing using common correlation features are now supported.

  • New functionality for applications. For example, the subscription services now offer triggers and support for monitoring applications. Also, event forwarding is now supported within domains and through firewalls.

  • Full Multilingual User Interface (MUI) compatibility.

These two technologies are used by developers, administrators, support technicians, expert users and management tools. Although similar, they have different capabilities and uses:

  • The Windows Event Log service (codenamed "Crimson") represents a standardized service for creating and publishing system and application events, storing events into standard event logs, and notifying applications of interesting events. It is intended primarily as a diagnostics and auditing tool that replaces the older NT Event Log facility in Windows and the numerous proprietary logging mechanisms used by applications and libraries.

  • The Event Tracing for Windows (ETW) is a higher performance facility used to instrument and monitor an application for performance and operational data. ETW was introduced in Windows 2000, although improvements to it have been made with every subsequent version of Windows, including Vista.

Previously, developers had to specifically access these technologies separately using either the NT Event Log API or the ETW API, although there is some overlap in functionality. In Windows Vista, the ETW API can be used in conjunction with the new Windows Event Logging API to access both facilities. This API, designed for C/C++ developers, offers a standardized architecture and approach to manage event logs, query for events in an event log, create and raise (publish) events, receive notifications of (subscribe to) events and format event data for display. For more information, see Developing Using Event Reporting and Tracing.

Performance Counters

Windows Vista introduces a new version of its performance counter technology, Performance Library (PERFLIB version 2.0). The Windows Vista implementation of PERFLIB provides increased performance usability, maintainability and reliability through:

  • Unified support for 32-bit and 64-bit CPUs

  • Scalability support, allowing developers to obtain information from multiple instances of an instrumented application

  • A new lightweight buffering model

  • No requirements for counter DLLs, named mutex or shared memory, improving performance and security

  • Internationalization capabilities

  • Closer integration with ETW technology

For more information, see Developing with Performance Counters.

Community Additions

Show:
© 2015 Microsoft