Skip to content

Add TSG: Get-SolutionUpdate intermittent NullReferenceException (2505-2604)#331

Closed
AlBurns-MSFT wants to merge 1 commit into
mainfrom
tsg/get-solutionupdate-intermittent-nre
Closed

Add TSG: Get-SolutionUpdate intermittent NullReferenceException (2505-2604)#331
AlBurns-MSFT wants to merge 1 commit into
mainfrom
tsg/get-solutionupdate-intermittent-nre

Conversation

@AlBurns-MSFT

Copy link
Copy Markdown
Collaborator

What

Adds a customer-facing troubleshooting guide for an intermittent NullReferenceException from Get-SolutionUpdate / Get-SolutionUpdateEnvironment seen during solution updates on builds 2505-2604. The failure is transient (a retry usually succeeds) and is resolved in build 2605 and later.

Why

There is currently no public article for this symptom -- only the existing Get-SolutionUpdate GatewayTimeout TSG, which covers the hang / timeout variant of the same cmdlet, not the intermittent NullReferenceException. Customers who hit the NRE have nothing to self-identify against.

Guidance shape

  • Applicability gate uses only customer-observable signals: build range, the exact error text, occurs during an update, and the intermittent / retry-succeeds behavior. A banner notes it does not apply on 2605+.
  • Mitigation is tiered and conservative: retry first (resolves most cases); if it persists or the update is stalled, route to support; permanent fix is updating to 2605+. No self-service service restart is included.
  • Cross-links the existing GatewayTimeout TSG for the hang variant, and is indexed in TSG/Update/README.md.

Status

Draft -- opened for the Update Service PG to review the wording and confirm this is the right public surface and framing before it merges.

…-2604)

Customer-facing troubleshooting guide for an intermittent NullReferenceException
from Get-SolutionUpdate / Get-SolutionUpdateEnvironment during solution updates on
builds 2505-2604 (resolved in 2605+). The applicability gate uses only
customer-observable signals (build range, exact error, intermittent behavior);
guidance is retry -> contact support, with the permanent fix being an update to
2605+. Cross-links the existing GatewayTimeout TSG and indexes the new page in
TSG/Update/README.md.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Signed-off-by: AlBurns-MSFT <6195567+AlBurns-MSFT@users.noreply.github.com>

This article applies when **all** of the following are true:

1. The cluster is on a build in the range **2505-2604** (23H2 `11.25xx`-`11.26xx`, or 24H2 `12.25xx`-`12.26xx`). Confirm the current version from the Azure portal (your Azure Local instance -> **Updates**), or from `Get-SolutionUpdate | ft Version, State` once the cmdlet returns.

@haowenliumsft haowenliumsft Jul 21, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we are confirming current stamp version, we should use Get-SolutionUpdateEnvironment instead of Get-SoluitonUpdate on the device. But since those 2 cmdlets are also impacted, I'm thinking that we should use Get-StampInformation instead which is through ECE

@AlBurns-MSFT

Copy link
Copy Markdown
Collaborator Author

I'm going to pull this draft and not merge. The keep retrying you will likely succeed advice doesn't hold up upon a second look. I don't think this will actually help anyone avoid a support case if they run into this and cant resolve through a retry.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants