diff --git a/aspnetcore/blazor/components/rendering.md b/aspnetcore/blazor/components/rendering.md
index 985a0015fa..b394ac8226 100644
--- a/aspnetcore/blazor/components/rendering.md
+++ b/aspnetcore/blazor/components/rendering.md
@@ -142,25 +142,25 @@ Because the callback is invoked outside of Blazor's synchronization context, the
 
 ::: moniker range=">= aspnetcore-7.0"
 
-:::code language="razor" source="~/../blazor-samples/7.0/BlazorSample_WebAssembly/Pages/rendering/CounterState2.razor" highlight="26":::
+:::code language="razor" source="~/../blazor-samples/7.0/BlazorSample_WebAssembly/Pages/rendering/CounterState2.razor" highlight="23-27":::
 
 ::: moniker-end
 
 ::: moniker range=">= aspnetcore-6.0 < aspnetcore-7.0"
 
-:::code language="razor" source="~/../blazor-samples/6.0/BlazorSample_WebAssembly/Pages/rendering/CounterState2.razor" highlight="26":::
+:::code language="razor" source="~/../blazor-samples/6.0/BlazorSample_WebAssembly/Pages/rendering/CounterState2.razor" highlight="23-27":::
 
 ::: moniker-end
 
 ::: moniker range=">= aspnetcore-5.0 < aspnetcore-6.0"
 
-:::code language="razor" source="~/../blazor-samples/5.0/BlazorSample_WebAssembly/Pages/rendering/CounterState2.razor" highlight="26":::
+:::code language="razor" source="~/../blazor-samples/5.0/BlazorSample_WebAssembly/Pages/rendering/CounterState2.razor" highlight="23-27":::
 
 ::: moniker-end
 
 ::: moniker range="< aspnetcore-5.0"
 
-:::code language="razor" source="~/../blazor-samples/3.1/BlazorSample_WebAssembly/Pages/rendering/CounterState2.razor" highlight="26":::
+:::code language="razor" source="~/../blazor-samples/3.1/BlazorSample_WebAssembly/Pages/rendering/CounterState2.razor" highlight="23-27":::
 
 ::: moniker-end
 
diff --git a/aspnetcore/blazor/state-management.md b/aspnetcore/blazor/state-management.md
index a45c5493e8..6ca80db977 100644
--- a/aspnetcore/blazor/state-management.md
+++ b/aspnetcore/blazor/state-management.md
@@ -652,6 +652,16 @@ When implementing custom state storage, a useful approach is to adopt [cascading
 
 For additional discussion and example approaches, see [Blazor: In-memory state container as cascading parameter (dotnet/AspNetCore.Docs #27296)](https://github.com/dotnet/AspNetCore.Docs/issues/27296).
 
+## Troubleshoot
+
+In a custom state management service, a callback invoked outside of Blazor's synchronization context must wrap the logic of the callback in <xref:Microsoft.AspNetCore.Components.ComponentBase.InvokeAsync%2A?displayProperty=nameWithType> to move it onto the renderer's synchronization context.
+
+When the state management service doesn't call <xref:Microsoft.AspNetCore.Components.ComponentBase.StateHasChanged%2A> on Blazor's synchronization context, the following error is thrown:
+
+> :::no-loc text="System.InvalidOperationException: 'The current thread is not associated with the Dispatcher. Use InvokeAsync() to switch execution to the Dispatcher when triggering rendering or component state.'":::
+
+For more information and an example of how to address this error, see <xref:blazor/components/rendering#receiving-a-call-from-something-external-to-the-blazor-rendering-and-event-handling-system>.
+
 ## Additional resources
 
 * [Save app state before an authentication operation](xref:blazor/security/webassembly/additional-scenarios#save-app-state-before-an-authentication-operation)