| Previous | Next |
| STATUS_INVALID_ADDRESS_COMPONENT | STATUS_TOO_MANY_ADDRESSES |
STATUS_INVALID_ADDRESS_WILDCARD
A wildcard valid for one endpoint operation can be invalid for another
STATUS_INVALID_ADDRESS_WILDCARD should be diagnosed in the context of the transport operation that consumed the address. Legacy TDI providers maintained separate address objects and connection endpoints. A local address-open or listen path can have different address rules from an endpoint-to-endpoint connect request, so replacing an address field with zeroes, an unspecified type, or another wildcard convention is not universally valid.
The NTSTATUS value does not define which field is the wildcard. That detail belongs to the selected transport address type. TA_ADDRESS explicitly makes the address bytes type-specific, and TDI supported many address families beyond IP. Record the address type and provider before interpreting a zero, blank name, or unspecified address as a wildcard.
Do not “fix” the error by substituting the machine's first IP address or by expanding a wildcard into every interface. That can change binding scope and security behavior. Compare the failing request with the provider's documented address structure and with a known-good request at the same lifecycle stage.
What to inspect
- The address type and the exact component treated as wildcard by the code constructing the request.
- Whether the operation is opening a local address, associating an endpoint, listening, or connecting to a remote node.
- Differences between the failing structure and a provider-accepted address, especially zeroed fields and declared lengths.
References
- Microsoft: TA_ADDRESS structure
- Microsoft: TDI_ASSOCIATE_ADDRESS
- Microsoft: TDI_CONNECT
- Microsoft: TDI_LISTEN
- Microsoft Open Specifications: NTSTATUS values
Looking for a different code? Search another status or error code.