Edit

Troubleshooting Other WSDAPI Applications

  • Article

Applications can directly call into WSDAPI interfaces and functions to perform device discovery and metadata exchange. The message patterns used by these applications vary.

The goal of this troubleshooting guide is to help WSDAPI application developers successfully implement a device proxy. This guide is not intended to help troubleshoot all aspects of WSDAPI. If the device proxy has been successfully created and the client and host can see each other on the network, then this guide cannot address the application's problems. To troubleshoot these application problems, follow the instructions in Enabling WSDAPI Tracing and contact Microsoft support for further assistance.

Troubleshooting clients calling WSDCreateDeviceProxy

Applications call WSDCreateDeviceProxy to create and initialize an instance of the IWSDDeviceProxy interface. This device proxy object can be used to advertise services on a device and also to exchange metadata.

An application calling WSDCreateDeviceProxy always uses the following messages.

An application calling WSDCreateDeviceProxy sometimes uses the following messages.

Resolve and ResolveMatches messages are generated when a logical device address (that is, a device address of the form urn:uuid:{guid}) is passed to pszDeviceId. These messages are not generated when a physical device address is passed to pszDeviceId. When Resolve and ResolveMatches messages are used, they are sent before the Get and GetResponse messages.

The following diagnostic procedures should be used (in order) to help identify problems with an application calling WSDCreateDeviceProxy with a physical device address.

  1. Inspect adapter and firewall settings.
  2. Use a generic host and client for HTTP metadata exchange.
  3. Use WinHTTP logging to verify Get traffic.
  4. Inspect network traces for HTTP metadata exchange.

The following diagnostic procedures should be used (in order) to help identify problems with an application calling WSDCreateDeviceProxy with a logical device address.

  1. Inspect adapter and firewall settings.
  2. Use a generic host and client for UDP WS-Discovery.
  3. Use WSD Debug Client to verify multicast traffic.
  4. Inspect network traces for UDP WS-Discovery.
  5. Use a generic host and client for HTTP metadata exchange.
  6. Use WinHTTP logging to verify Get traffic.
  7. Inspect network traces for HTTP metadata exchange.

Verify that Resolve and ResolveMatches messages are generated and meet traffic requirements. It is not necessary to look for Probe or ProbeMatches messages in the WSD Debug Client output or in the network traces.

Troubleshooting clients calling WSDCreateDeviceProxyAdvanced

Applications call WSDCreateDeviceProxyAdvanced to create and initialize an instance of the IWSDDeviceProxy interface. Unlike WSDCreateDeviceProxy, WSDCreateDeviceProxyAdvanced has a pDeviceAddress parameter that is used to define the device transport address. If this transport address is specified, then logical address resolution is not required and Resolve and ResolveMatches messages are not generated.

If pDeviceAddress is set to NULL and pszDeviceId is a logical address, then address resolution is required and Resolve and ResolveMatches messages are generated.

The following diagnostic procedures should be used (in order) to help identify problems with an application calling WSDCreateDeviceProxyAdvanced with a non-NULLpDeviceAddress parameter. These procedures can also be used when pDeviceAddress is NULL and pszDeviceId is a physical address.

  1. Inspect adapter and firewall settings.
  2. Use a generic host and client for HTTP metadata exchange.
  3. Use WinHTTP logging to verify Get traffic.
  4. Inspect network traces for HTTP metadata exchange.

The following diagnostic procedures should be used (in order) to help identify problems with an application calling WSDCreateDeviceProxyAdvanced with pDeviceAddress set to NULL and with pszDeviceId set to a logical address.

  1. Inspect adapter and firewall settings.
  2. Use a generic host and client for UDP WS-Discovery.
  3. Use WSD Debug Client to verify multicast traffic.
  4. Inspect network traces for UDP WS-Discovery.
  5. Use a generic host and client for HTTP metadata exchange.
  6. Use WinHTTP logging to verify Get traffic.
  7. Inspect network traces for HTTP metadata exchange.

Verify that Resolve and ResolveMatches messages are generated and meet traffic requirements. It is not necessary to look for Probe or ProbeMatches messages in the WSD Debug Client output or in the network traces.

Troubleshooting clients using the IWSDiscoveryProvider interface

Applications calling into the IWSDiscoveryProvider interface do not perform metadata exchange. This interface is only used for discovery. The message patterns and troubleshooting procedures are different for each method called on the IWSDiscoveryProvider interface.

When an application calls IWSDiscoveryProvider::SearchByType, a Probe message is generated. The Probe message is sent by UDP multicast to port 3702. A ProbeMatches message is generated in response. The ProbeMatches message is sent by UDP unicast and it originates from port 3702.

When an application calls IWSDiscoveryProvider::SearchById, a Resolve message is generated. A Resolve message is sent by UDP multicast to port 3702. A ResolveMatches message is generated in response. The ResolveMatches is sent by UDP unicast and it originates from port 3702.

The following diagnostic procedures should be used (in order) to help identify problems with an application calling IWSDiscoveryProvider::SearchByType or IWSDiscoveryProvider::SearchById. Verify that the messages generated by the called API satisfy the traffic requirements.

  1. Inspect adapter and firewall settings.
  2. Use a generic host and client for UDP WS-Discovery.
  3. Use WSD Debug Client to verify multicast traffic.
  4. Inspect network traces for UDP WS-Discovery.

If an application calls IWSDiscoveryProvider::SearchByAddress, then it is a directed discovery application. For more troubleshooting information, see Troubleshooting Applications Using Directed Discovery.

Getting Started with WSDAPI Troubleshooting