Bug Report: Microsoft Support Assistant HTTP 500 with non-ASCII account names

Summary

Microsoft Support Assistant on support.microsoft.com returns HTTP 500 when the authenticated Microsoft account profile contains non-ASCII characters in the user's name.

The same Support Assistant workflow works normally after changing the profile name to ASCII-only characters.

This appears to be a server-side defect in the Microsoft Support Assistant / CMSP Peridot backend.

Microsoft Support case

Case number: 7109874722

Microsoft Consumer Support reviewed the issue and stated that it appeared to be a backend issue in the Support Assistant service and that it should be handled by a dedicated team. However, the case was ultimately closed without an engineering escalation.

Initial state

My Microsoft account profile contained:

• Given name: Тимофей
• Surname: Денисов

Steps to reproduce

1. Open https://support.microsoft.com/en-us/home/contact
2. Enter:
   Gaming Services GameInput MSI detection defect
3. Select Get Help
4. Select Ask our Support Assistant
5. Send the request.

The Support Assistant sends a POST request to its backend Stream endpoint.

The request returns:

HTTP 500

Response body:

{"error":"Request headers must contain only ASCII characters."}

I reproduced the failure twice in the captured session.

Browser-side HTTP headers

The HTTP request headers sent by Firefox contain only ASCII characters.

Therefore, the error does not appear to be caused by a non-ASCII HTTP header sent by the browser itself.

The browser-side HAR shows the HTTP 500 response being returned by support.microsoft.com.

A/B reproduction

I then changed my Microsoft account profile to ASCII-only values:

• Given name: Timofey
• Surname: Denisov

After making this change, I repeated the same Support Assistant workflow.

The HTTP 500 error no longer occurred.

Therefore, the observed behavior is:

Microsoft account name contains Cyrillic characters ↓ Support Assistant ↓ HTTP 500 "Request headers must contain only ASCII characters." Microsoft account name changed to ASCII-only ↓ Same Support Assistant workflow ↓ No HTTP 500

This provides a reproducible A/B test showing a strong correlation between non-ASCII characters in the authenticated profile name and the server-side failure.

Relevant data observed in the HAR

The authenticated profile information includes the original Unicode values.

The CMSP session initialization also contains:

"UserDisplayName":"Тимофей"

The Support Assistant Init request itself succeeds.

The subsequent Stream request fails with HTTP 500.

Relevant correlation IDs:

3b5e8862-81d1-4797-8f7b-8a05ffcc2b89 9829ec10-4d5a-4687-9ad9-ce2ea4c8b7db

Additional environment information:

Environment: emerald-prod-we Build: v20260923.1.official Browser: Firefox 157.0 OS: Windows 11 Enterprise 25H2 x64

Possible technical cause

The exact internal request that fails cannot be observed from the browser-side HAR.

However, the error message:

Request headers must contain only ASCII characters.

is consistent with a .NET HTTP client rejecting a non-ASCII value while constructing an outbound HTTP request.

One possible explanation is that a value derived from the authenticated user's profile, such as GivenName, Surname, or UserDisplayName, is being inserted into an internal HTTP request header without appropriate encoding or validation.

This is a hypothesis; the exact internal header and downstream request need to be determined from server-side telemetry.

Expected behavior

The Support Assistant should successfully process requests regardless of whether the authenticated Microsoft account contains Unicode characters in the user's name.

At minimum, a valid Unicode profile value should not cause an HTTP 500 response from the Support Assistant backend.

Actual behavior

A Microsoft account profile containing Cyrillic characters causes the Support Assistant Stream request to return HTTP 500:

{"error":"Request headers must contain only ASCII characters."}

Changing only the profile name to ASCII-only characters removes the failure.

Request

Please investigate this as a Microsoft Support Assistant / CMSP Peridot backend defect.

In particular, please check the server-side telemetry for the correlation IDs above and determine:

1. Which internal HTTP request generated the ASCII-header exception.
2. Which HTTP header contained the non-ASCII value.
3. Which profile field supplied that value.
4. Why the value was allowed to reach an HTTP header rather than being encoded, transformed, or rejected earlier.
5. Whether other Microsoft Support Assistant users with non-ASCII account names are affected.

I have the original HAR capture containing the complete browser-side HTTP exchange. I have not attached the full HAR publicly because it contains authentication/session information.

The exact backend endpoint and the complete HAR can be provided through an appropriate private Microsoft support channel if required.