Export (0) Print
Expand All

Getting Started with WSDAPI Troubleshooting

This troubleshooting guide contains a set of diagnostic procedures that can be used to help identify the cause of application problems. Once the cause of the problem has been successfully identified, the suggested solutions in the diagnostic procedure can be applied in order to resolve the problem.

There are two ways to determine the diagnostic procedure to use. One way is to go to the troubleshooting page for the type of client to view a step-by-step list of diagnostic procedures to use to troubleshoot the client. The other way is to go to the troubleshooting quick reference below to view summary tables that show common problems with WSDAPI applications and the procedures to use to diagnose the problems.

Troubleshooting by Type of Client

The following topics show the relevant diagnostic procedures by type of client. These topics also show the message patterns associated with the client type.

Troubleshooting Quick Reference

The following tables show some problems that can prevent WSDAPI clients and hosts from seeing each other on the network and from exchanging device metadata. The tables also show the diagnostic procedures to run and the criteria to use to evaluate whether the application suffers from a particular problem.

Network environment problems

ProblemDiagnostic ProcedureProblem Identification
The firewall blocks Network Discovery traffic. Inspecting Adapter and Firewall Settings Enabling the Network Discovery exception on the firewall solves the problem.
Firewall exceptions specific to the application are blocking messages. Inspecting Adapter and Firewall Settings Disabling the firewall solves the problem. WF.msc shows application-specific firewall rules.
The device does not respond to UDP requests by sending a ProbeMatches or ResolveMatches message in a timely fashion (less than 4 seconds). Inspecting Adapter and Firewall Settings Disabling the firewall solves the problem, and a generic host that responds in less than 4 seconds works successfully.
The security context of the application is incorrect (that is, the client and host do not have adequate permissions on the network). Using a Generic Host and Client for UDP WS-Discovery or Using a Generic Host and Client for HTTP Metadata Exchange The device address is not shown in WSD Debug Client output. Running the application as Administrator solves the problem.
An IPSec policy is blocking messages. Using a Generic Host and Client for UDP WS-Discovery or Using a Generic Host and Client for HTTP Metadata Exchange The device address is not shown in WSD Debug Client output. The problem is not solved by disabling the firewall. The problem cannot be reproduced on a machine not subject to any IPSec policies.

 

Discovery traffic problems

ProblemDiagnostic ProcedureProblem identification
Hello, Probe, or Resolve messages are not transmitted on the network because the application does not correctly enumerate the multicast network interfaces. Using WSD Debug Client to Verify Multicast Traffic The Hello, Probe, or Resolve messages do not appear in WSD Debug Client output. The packets do not appear on the network. Packets are not generated for the loopback interface or for other interfaces.
Probe messages are not sent by UDP multicast to port 3702 (for applications not using directed discovery). Inspecting Network Traces for UDP WS-Discovery Inspection of the message shows that it was sent to the wrong port.
The Probe message does not contain a Types element, or the Types element is empty. Inspecting Network Traces for UDP WS-Discovery or Inspecting Network Traces for Applications Using Directed Discovery Inspection of the message shows that the Types element is not present or empty.
The Types element of a Probe message does not contain the types to which a host will respond. Inspecting Network Traces for UDP WS-Discovery or Inspecting Network Traces for Applications Using Directed Discovery Inspection of the message shows that the Types element contains a malformed or incorrect value.
A ProbeMatches message was not sent unicast to the UDP port from which the Probe was sent. Inspecting Network Traces for UDP WS-Discovery or Inspecting Network Traces for Applications Using Directed Discovery Inspection of the output shows that no ProbeMatches message was sent or that the message was sent to the wrong port.

Note  For applications using directed discovery, the ProbeMatches must be sent over HTTP or HTTPS in response to the Probe message.

The ProbeMatches message does not contain a RelatesTo element, or the RelatesTo element is empty. Inspecting Network Traces for UDP WS-Discovery or Inspecting Network Traces for Applications Using Directed Discovery Inspection of the message shows that the RelatesTo element is not present or empty.
The value of the RelatesTo element in a ProbeMatches message does not match the value of the MessageId element from the corresponding Probe message. Inspecting Network Traces for UDP WS-Discovery or Inspecting Network Traces for Applications Using Directed Discovery Inspection of the message shows that the RelatesTo element contains a malformed or incorrect value.
The XAddrs element included in a ProbeMatches message does not conform to the XAddr Validation Rules. Inspecting Network Traces for UDP WS-Discovery or Inspecting Network Traces for Applications Using Directed Discovery Inspection of the message shows that the XAddrs are invalid.
Resolve messages are not sent by UDP multicast to port 3702 (for applications not using directed discovery). Inspecting Network Traces for UDP WS-Discovery or Inspecting Network Traces for Applications Using Directed Discovery Inspection of the output shows that the Resolve message was sent to the wrong port.
A ResolveMatches message was not sent unicast to the UDP port from which a Resolve message was sent. Inspecting Network Traces for UDP WS-Discovery or Inspecting Network Traces for Applications Using Directed Discovery Inspection of the output shows that no ResolveMatches message was sent or that the message was sent to the wrong port.

 

Metadata exchange problems

ProblemDiagnostic ProcedureProblem identification
The transport address advertised by the host is wrong. Using a Generic Host and Client for HTTP Metadata Exchange Inspection of the XAddrs in the WSD Debug Client output shows that the transport address is wrong or malformed.
A TCP connection could not be established for metadata exchange. Inspecting Network Traces for HTTP Metadata Exchange The output from the packet analyzer does not show the following packet exchange:
  • A TCP SYN packet sent from the client
  • A TCP SYN/ACK packet sent from the host
  • A TCP ACK packet sent from the client
The client did not send a valid HTTP GET request. Inspecting Network Traces for HTTP Metadata Exchange There is no HTTP GET request in the packet analyzer output, or the request is malformed.
The client did not send a valid WS-Transfer Get message. Inspecting Network Traces for HTTP Metadata Exchange There is no WS-Transfer Get message in the packet analyzer output, or the message is malformed.
The host is not listening on the URL path specified in the HTTP GET request. Inspecting Network Traces for HTTP Metadata Exchange There is no HTTP response in the packet analyzer output.
The WS-Transfer Get message does not contain a To element, or the To element is empty. Inspecting Network Traces for HTTP Metadata Exchange Inspection of the message shows that the To element is not present or empty.
The value of the To element of a WS-Transfer Get message does not match one of the host's endpoint addresses. Inspecting Network Traces for HTTP Metadata Exchange Inspection of the message shows that value of the To element does not match one of the endpoint addresses advertised in the host's ProbeMatches or ResolveMatches message.
The host did not send a valid HTTP response header. Inspecting Network Traces for HTTP Metadata Exchange There is no HTTP response in the packet analyzer output, or the request is malformed.
The HTTP response header sent by the host indicates that the request cannot be completed. Inspecting Network Traces for HTTP Metadata Exchange The response header has a status code other than HTTP/1.1 200.
The host did not send a valid GetResponse message. Inspecting Network Traces for HTTP Metadata Exchange There is no GetResponse message in the packet analyzer output, or the message is malformed.
The GetResponse message does not contain a RelatesTo element, or the RelatesTo element is empty. Inspecting Network Traces for HTTP Metadata Exchange Inspection of the message shows that the RelatesTo element is not present or empty.
The value of the RelatesTo element in a GetResponse message does not match the value of the MessageId element from the corresponding Get message. Inspecting Network Traces for HTTP Metadata Exchange Inspection of the message shows that the RelatesTo element contains a malformed or incorrect value.

 

SSL/TLS negotiation problems

ProblemDiagnostic ProcedureProblem identification
The operating system does not trust the server certificate presented by the device. Using WinHTTP Logging to Verify SSL/TLS Negotiation The WinHTTP log contains the error 0x800b0109 (CERT_E_UNTRUSTEDROOT).
The common name (CN) of the server certificate does not match the hostname part of the device address. Using WinHTTP Logging to Verify SSL/TLS Negotiation The WinHTTP log contains the error 0x800b010f (CERT_E_CN_NO_MATCH).
Certificate revocation cannot be checked because the certificate revocation server was offline. Using WinHTTP Logging to Verify SSL/TLS Negotiation The WinHTTP log contains the error 0x80092013 (CRYPT_E_REVOCATION_OFFLINE).
There is no valid certificate for client authentication to the local computer certificate store. Using WinHTTP Logging to Verify SSL/TLS Negotiation The WinHTTP log contains the error 12044 (ERROR_WINHTTP_CLIENT_AUTH_CERT_NEEDED) and SSL/TLS negotiation failed. Inspection of the certificate store using the Certificates MMC snap-in shows that there isn't a valid certificate.
The process trying to issue the HTTP request does not have access to the private key of the client certificate. Using WinHTTP Logging to Verify SSL/TLS Negotiation The WinHTTP log contains the error 12044 (ERROR_WINHTTP_CLIENT_AUTH_CERT_NEEDED) and SSL/TLS negotiation failed. Inspection of the ACL of the client certificate shows that the account running the process trying to issue the HTTP request does not have read access.

 

Related topics

WSDAPI Troubleshooting Guide

 

 

Community Additions

ADD
Show:
© 2014 Microsoft