Configure crash dumps

Azure Sphere devices can be optionally configured so that full user-mode crash dumps are reported to Microsoft when an OS or application crash occurs. Microsoft uses this information to improve the quality of Azure Sphere OS for all Azure Sphere devices.

The following diagram illustrates the stages of crash dump collection:

Crash dump workflow

Stage Description
1. Enable crash dump collection for one or more of your device groups. If you choose to enable crash dump collection for a device group, it indicates that you have provided consent for user-mode crash dumps to be gathered, uploaded, and analyzed.
Note: If your app collects personal data from end users, you should obtain consent from them before enabling crash dumps for those devices.
2. The Azure Sphere Security service will synchronize the opt-in status with your devices within 48 hours. Crash dumps are never generated unless a device has received the opt-in signal. If a device does not contact the Azure Sphere Security Service in this time period, the device will automatically stop generating crash dumps until the opt-in status is successfully synchronized with the Azure Sphere Security Service again.
3. If crash dumps are enabled, when an OS component or application crashes, the device attempts to upload a crash dump to a secure location. Once securely uploaded, the data does not leave the secure location.
4. The data is accessible only for troubleshooting by the Azure Sphere team, through secure, remote, fully audited sessions.

Privacy considerations

  • Crash dumps from all Azure Sphere devices are securely stored in East US, West US, and EU data centers. Customers in the EU can ensure that their application images and crash dump files are processed and stored solely within the EU by setting the Regional data boundary setting parameter to EU.

    Note

    If you set the Regional Data Boundary setting to None, your crash dump files will be stored in East or West US by default.

  • Crash dump data is stored in compliance with all applicable laws and regulations, including GDPR, and is deleted after 29 days.

Performance considerations

  • Crash dump upload size typically ranges from a few KiB to tens of KiB.
  • Intelligent throttling policies ensure a crash dump upload is initiated only when necessary to minimize performance and bandwidth effects on your devices. This intelligent throttling happens automatically and requires no action. Crash dump upload will be skipped after a sufficient number of dumps from identical crashes have already been collected.
  • When an application crashes, the device will attempt to securely upload a crash dump, if enabled. The crashing application will be restarted after the crash dump upload is complete. In the event that a network connection cannot be established for the upload, and the device does not respond within the 5 second time out period, the crashed application is restarted promptly.

Enable crash dump collection

Crash dumps are not enabled by default. You can give consent to enable crash dump collection by either using the az sphere device-group update command or in the AllowCrashDumpsCollection request body field in the Device Group - Patch API.

For example, the following CLI command enables crash dump collection and specifies that crash dump data be stored in the EU.

az sphere device-group update --product DW100 --device-group Marketing --allow-crash-dumps-collection Enabled  --regional-data-boundary EU

To disable crash dump collection from the CLI, set --allow-crash-dumps-collection to "Disabled".

az sphere device-group update --product DW100 --device-group Marketing --allow-crash-dumps-collection "Disabled" 

Disabling crash dumps for all device groups is equivalent to revoking consent.

Script to configure crash dumps

We provide a sample script that you can use to make GET or PATCH calls to the Azure Sphere API to view or modify the AllowCrashDumpsCollection value for one or many device groups. For more information, see Crash Dumps Configure Script in the Azure Sphere Gallery, a collection of unmaintained scripts, utilities, and functions.

See also

Increasing transparency and customer control over data