Share via


The Cable Guy - July 2006

Network Diagnostics Framework in Windows Vista

TechNet's The Cable Guy

By The Cable Guy

The Network Diagnostics Framework in Microsoft® Windows Vista is an infrastructure and a set of built-in and extensible components that attempts to automatically diagnose and correct network connectivity problems.

Introduction

Network connectivity is an expected and required capability of modern computers. However, relatively few users of computers have detailed knowledge of how computer networking works and what to do to correct problems. Unfortunately, error messages in Windows and Windows-based applications in many cases only indicate that there is a problem, not the actual root cause of the problem or how to correct it.

Successfully understanding and diagnosing network connectivity problems is complicated by the fact that computer networking has a layered architecture and consists of many protocols and services that work together. Examples of layered architectures are the 7-layer Open Systems Interconnection (OSI) model and the 4-layer Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite. Components at a given layer rely on components functioning correctly at lower layers in the stack. A failure in a component of a layer can affect the functionality of all the layers above it.

An additional element to diagnosing problems is that some components have their own diagnostics, which can work well for their own component, but are not integrated across components to provide an integrated function. It is often left up to the user, helpdesk support person, or network troubleshooter to determine the relationships between components and determine the root cause of the problem. This can be a difficult and time-consuming process for users, helpdesk staff, and Microsoft support personnel.

A good example of a connectivity issue that provides incomplete information and can be difficult to troubleshoot is the following Internet Explorer error message page when a Web page cannot be loaded:

  • The page cannot be displayed

  • The page you are looking for is currently unavailable. The Web site might be experiencing technical difficulties, or you may need to adjust your browser settings.

Internet Explorer was unable to load the Web page corresponding to the URL address in the Address bar and is giving the user the best information that it has. Unfortunately, the problem that Internet Explorer encountered could be in numerous locations on the Web client computer, in the network infrastructure, or on the Web server. On the Web client computer, the problem can be due to TCP/IP misconfiguration, Internet Explorer misconfiguration, name resolution problems, or security settings.

To provide a better user experience when encountering network connectivity issues, Windows Vista includes the Network Diagnostics Framework (NDF), a set of technologies and guidelines that allows a set of troubleshooters (also known as a helper classes) to assist in the diagnosis and possible automatic correction of networking problems. When a user experiences a networking problem in Windows Vista, NDF will provide the user the ability to diagnose and repair the problem within the context of that problem. This means that the diagnostics assessment and resolution steps are presented to the user within the application or dialog box that they were using when the problem occurred or based on the failed network operation.

With NDF, when the user tries to complete a task that depends on network connectivity, such as browsing to a Web site or sending an email message, an error message may appear indicating failure to complete the task (such as Page cannot be displayed or Server is not available). With NDF, the error message might include an option to diagnose the problem, resulting in a diagnosis session taking place within the context of the task the user was trying to complete.

For example, if Internet Explorer in Windows Vista cannot display a Web page, the error message text informs the user to click Tools, and then Diagnose Connection Problems. This invokes NDF to attempt to identify and correct the problem within the context of Internet Explorer. By diagnosing problems within their context, the diagnostics process is aware of the task and relevant information related to it, such as a URL, an email server name, or a wireless network name.

During the diagnosis, NDF will analyze why the user's task has failed and present a solution to the problem or possible list of causes and corrections in clear language, allowing the user to take action to fix the problem. The following figure shows an example.

Example of an NDF dialog box that offers the user corrective options

The solution may be automatically performed or require the user to choose a solution or manually perform steps in the resolution process. The steps could involve configuration changes, connecting or resetting network devices, contacting a helpdesk support person for additional assistance, or providing a report of the problem. In many cases, this new capability allows the user to resolve their network problem without having to request outside help or intervention.

The primary function of NDF is to diagnose and help troubleshoot connectivity issues, including failed connections. The diagnostics and solution to the problem are customized based on the network components involved and their dependencies, without allowing the computer to be placed in an unsafe configuration. When a problem is not diagnosable or no solution is available, NDF will guide the user to report the issue to Microsoft through Windows Error Reporting.

NDF is based on client-side diagnostics and might not be able to diagnose server-based or end-to-end diagnostics using diagnostics servers or services in the network infrastructure. However, NDF will attempt to analyze the problem from the client computer to determine if the problem is outside the client in any of the involved services or infrastructure components.

NDF Architecture

NDF is part of the Windows Diagnostics Infrastructure (WDI), the overall infrastructure for writing diagnostic troubleshooters in Windows Vista. The following figure shows the architecture of WDI and NDF.

The architecture of WDI and NDF

Applications can use the Windows Vista networking diagnostics application programming interfaces (APIs) to access diagnostic functionality in Windows Vista. System components and services can use the networking diagnostics APIs or the WDI Client API to access diagnostic functionality in Windows Vista. The WDI Client API passes the application or system request to the Windows Diagnostics Policy service, which passes the request to an installed troubleshooter. For NDF, the Windows Diagnostics Policy service passes the request to the Network Diagnostics Engine, which, with the help of installed Microsoft or third-party helper classes, diagnoses the problem.

A helper class can determine the state of a specific layer or component of networking functionality. A helper class plugs into the NDF along with other helper classes from other network components. This allows the helper classes to work within a common framework to determine the root cause of a networking problem.

For example, there is a helper class for wireless connectivity. The wireless helper class plugs into the NDF, which in turn plugs into WDI. The role of the wireless helper class is to be the expert for wireless connectivity issues by collecting and analyzing information about wireless connectivity and providing the results of the analysis with repair options to WDI through NDF.

NDF Example

The following is an example of how NDF works with a set of helper classes to diagnose and resolve a problem:

  1. An application or system component reports a perceived problem with a TCP connection and prompts the user with an error message.

  2. The user invokes networking diagnostics, which forwards the problem parameters to the Network Diagnostics Engine.

  3. The Network Diagnostics Engine constructs an internal cause-and-effect graph based on the reported problem and the set of relevant helper classes and begins to invoke helper classes from the top of the stack down to determine the root cause or causes. For example:

    • The Network Diagnostics Engine invokes the helper class for the WinINet API, which finds that a problem exists and indicates a specific TCP connection to the Network Diagnostics Engine.

    • The Network Diagnostics Engine invokes the helper class for TCP connections, which finds that a problem exists and indicates a specific IP interface to the Network Diagnostics Engine.

    • The Network Diagnostics Engine invokes the helper class for IP interfaces, which finds that a problem exists and indicates an address acquisition issue.

    • The Network Diagnostics Engine invokes the helper class for address acquisition, which finds that a problem exists and indicates an underlying NDIS interface (an NDIS miniport driver).

    • The Network Diagnostics Engine invokes the helper class for NDIS miniports, which finds that a problem exists but does not indicate any other possible cause.

    This step finds one or more problem causes that point to no other possible problem causes. The Network Diagnostics Engine treats these as root causes.

  4. The Network Diagnostics Engine displays a root cause description and a list of repair options to the user.

    If there is only one repair option and it can be performed without requiring user input, the Network Diagnostics Engine performs it automatically.

  5. If there is only one repair option or the user selected a repair option, the Network Diagnostics Engine requests that the appropriate helper class perform the repair.

    In this example, the Network Diagnostics Engine requests that the NDIS miniports helper class perform the repair and indicate whether the repair has been completed to the Network Diagnostics Engine.

  6. The Network Diagnostics Engine retests the same set of helper classes in the internal cause-and-effect graph.

    If the problem is not corrected and new causes exist, the Network Diagnostics Engine goes back to step 3.

    If the problem is not corrected, no new causes exist, and alternate repairs exist, the Network Diagnostics Engine goes back to step 4.

    If the problem is corrected, the Network Diagnostics Engine prompts the user with a message indicating that the repair has been completed successfully.

For More Information

For more information about networking technologies in Windows Vista, consult the following resources:

For a list of all The Cable Guy articles, click here.