XGameSaveInitializeProvider hangs

Hello Maksim,

Here is what the official GDK documentation says, with recommendations.

1) Why the call can block for a long time

XGameSaveInitializeProvider does more than create a handle. When the provider initializes, the title tries to acquire the lock on the user’s cloud save storage and sync the player’s saves (XGameSave API overview). Its reference page states that it can block and may show UI to the user while saves are synchronized. For that reason it should not be called on the UI thread or on a time-sensitive thread (XGameSaveInitializeProvider – Remarks).

So yes, network conditions can cause the delay. A XNetworkingGetConnectivityHint check made just before the call doesn’t guarantee that the sync will be fast: connectivity can change, and the service can still be slow to respond. If you initialize with syncOnDemand = true, the docs also note that container access is impossible when the device is offline or has connectivity issues, and that sync progress UI may appear.

2) Can you rely on XAsyncCancel?

Not as your main protection. The XAsyncCancel documentation says cancellation may happen synchronously, asynchronously, or not at all, depending on the call being canceled. The XGameSaveInitializeProviderAsync page does not say whether this specific operation honors cancellation. Treat it as best-effort:

• Call XAsyncCancel if you want to, but design your game to stay correct even if the operation keeps running.
• If cancellation does take effect, XGameSaveInitializeProviderResult returns E_ABORT, and your completion callback still runs. Free your context there, and only there.

3) Recommended design

1. Switch to XGameSaveInitializeProviderAsync. The official sample notes that it can be started even from a time-sensitive thread, because the work and the callback run on platform threads. Your game loop keeps running, so there is nothing to terminate.
2. Use your own timeout at the game level, not cancellation. If initialization hasn’t completed after N seconds, show a “Syncing saves…” state, or let the player continue offline if your design allows it. The overview says that when the cloud sync fails because of connection loss, the title should decide whether users can keep playing in offline mode.
3. Handle every failure HRESULT in the completion callback, and retry the initialization later if needed.
4. Close the provider with XGameSaveCloseProvider when the title suspends or terminates. The provider can’t be reused across suspend/resume, so re-initialize it after resume.

Also note that Microsoft now recommends XGameSaveFiles for new GDK titles, with XGameSave used only when XGameSaveFiles isn’t an option. The two can’t be mixed in the same title.

To narrow down the root cause, please share:

• The platform (PC or console) and GDK version.
• The syncOnDemand value you pass.
• Whether any sync UI appears during the 30 seconds.
• Whether the hang happens mostly on first launch, after switching devices, or after resuming.

The lock and sync behavior depends on these details.

Hope this helps. If it does, please consider accepting the answer.Hello Maksim,

Here is what the official GDK documentation says, with recommendations.

1) Why the call can block for a long time

XGameSaveInitializeProvider does more than create a handle. When the provider initializes, the title tries to acquire the lock on the user’s cloud save storage and sync the player’s saves (XGameSave API overview). Its reference page states that it can block and may show UI to the user while saves are synchronized. For that reason it should not be called on the UI thread or on a time-sensitive thread (XGameSaveInitializeProvider – Remarks).

So yes, network conditions can cause the delay. A XNetworkingGetConnectivityHint check made just before the call doesn’t guarantee that the sync will be fast: connectivity can change, and the service can still be slow to respond. If you initialize with syncOnDemand = true, the docs also note that container access is impossible when the device is offline or has connectivity issues, and that sync progress UI may appear.

2) Can you rely on XAsyncCancel?

Not as your main protection. The XAsyncCancel documentation says cancellation may happen synchronously, asynchronously, or not at all, depending on the call being canceled. The XGameSaveInitializeProviderAsync page does not say whether this specific operation honors cancellation. Treat it as best-effort:

• Call XAsyncCancel if you want to, but design your game to stay correct even if the operation keeps running.
• If cancellation does take effect, XGameSaveInitializeProviderResult returns E_ABORT, and your completion callback still runs. Free your context there, and only there.

3) Recommended design

1. Switch to XGameSaveInitializeProviderAsync. The official sample notes that it can be started even from a time-sensitive thread, because the work and the callback run on platform threads. Your game loop keeps running, so there is nothing to terminate.
2. Use your own timeout at the game level, not cancellation. If initialization hasn’t completed after N seconds, show a “Syncing saves…” state, or let the player continue offline if your design allows it. The overview says that when the cloud sync fails because of connection loss, the title should decide whether users can keep playing in offline mode.
3. Handle every failure HRESULT in the completion callback, and retry the initialization later if needed.
4. Close the provider with XGameSaveCloseProvider when the title suspends or terminates. The provider can’t be reused across suspend/resume, so re-initialize it after resume.

Also note that Microsoft now recommends XGameSaveFiles for new GDK titles, with XGameSave used only when XGameSaveFiles isn’t an option. The two can’t be mixed in the same title.

To narrow down the root cause, please share:

• The platform (PC or console) and GDK version.
• The syncOnDemand value you pass.
• Whether any sync UI appears during the 30 seconds.
• Whether the hang happens mostly on first launch, after switching devices, or after resuming.

The lock and sync behavior depends on these details.

Hope this helps. If it does, please consider accepting the answer.

Fontes:

• XGameSaveInitializeProvider – Microsoft Learn
• XGameSaveInitializeProviderAsync – Microsoft Learn
• XAsyncCancel – Microsoft Learn
• XGameSave API overview – Microsoft Learn