Document Details
Troubleshoot
This page contains Windows bias
About This Page
This page is part of the Azure documentation. It contains code examples and configuration instructions for working with Azure services.
Bias Analysis
Detected Bias Types
windows_first
cmd_examples
missing_linux_example
Summary
The documentation generally uses cross-platform commands (iotedge, docker, az) and mostly shows bash examples, which are suitable for Linux. However, there are several instances where Windows command prompt (cmd) syntax is shown (e.g., iotedge logs <container name>, docker rm --force <container name>, iotedge restart <container name>), and these are presented without equivalent Linux/bash examples. In some sections, the cmd syntax is shown first or exclusively, and there is a lack of explicit Linux-specific troubleshooting steps or notes, which may confuse Linux users. There is also a lack of clarity on platform-specific differences (e.g., service management, log locations, or permissions), and the documentation does not mention or address Linux-specific tools or patterns.
Recommendations
- For every command shown in cmd syntax, provide the equivalent bash/Linux command, and clearly label which platform each example is for.
- If a command is cross-platform (e.g., iotedge, docker), use bash syntax by default, as most IoT Edge deployments are on Linux, or show both bash and cmd examples side by side.
- Add a section or notes about platform-specific differences, such as service management (systemctl vs. Windows Services), log file locations, and permissions.
- Avoid using 'cmd' code blocks unless the command is truly Windows-only; otherwise, prefer 'bash' or 'shell' for cross-platform commands.
- Include troubleshooting steps or tips that are specific to Linux environments, such as checking systemd service status, journalctl logs, or SELinux/AppArmor issues.
- Review the order of examples and ensure Linux is not deprioritized in favor of Windows.
Create Pull Request
Scan History
| Date | Scan | Status | Result |
|---|---|---|---|
| 2026-01-14 00:00 | #250 | in_progress |
 Clean
|
| 2026-01-13 00:00 | #246 | completed |
Clean
|
| 2026-01-11 00:00 | #240 | completed |
Clean
|
| 2026-01-10 00:00 | #237 | completed |
Clean
|
| 2026-01-09 00:34 | #234 | completed |
Clean
|
| 2026-01-08 00:53 | #231 | completed |
Clean
|
| 2026-01-06 18:15 | #225 | cancelled |
Clean
|
| 2025-08-22 00:01 | #88 | completed |
Clean
|
| 2025-08-17 00:01 | #83 | cancelled |
Clean
|
| 2025-07-13 21:37 | #48 | completed |
Biased
|
| 2025-07-12 23:44 | #41 | cancelled |
Biased
|
| 2025-07-09 13:09 | #3 | cancelled |
Clean
|
| 2025-07-08 04:23 | #2 | cancelled |
Biased
|
Flagged Code Snippets
For more information about ongoing logs maintenance and production scenarios, see [Set up default logging driver](production-checklist.md#set-up-default-logging-driver). ## View the messages going through the IoT Edge hub You can view the messages going through the IoT Edge hub and gather insights from verbose logs from the runtime containers. To turn on verbose logs on these containers, set the `RuntimeLogLevel` environment variable in the deployment manifest. To view messages going through the IoT Edge hub, set the `RuntimeLogLevel` environment variable to `debug` for the edgeHub module. Both the edgeHub and edgeAgent modules have this runtime log environment variable, with the default value set to `info`. This environment variable can take the following values: * fatal * error * warning * info * debug * verbose You can also check the messages being sent between IoT Hub and IoT devices. View these messages by using the [Azure IoT Hub extension for Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=vsciot-vscode.azure-iot-toolkit). For more information, see [Handy tool when you develop with Azure IoT](https://blogs.msdn.microsoft.com/iotdev/2017/09/01/handy-tool-when-you-develop-with-azure-iot/). ## Restart containers After investigating the logs and messages for information, you can try restarting containers. On the IoT Edge device, use the following commands to restart modules:
Restart the IoT Edge runtime containers:
You can also use the built-in direct method call [UploadSupportBundle](how-to-retrieve-iot-edge-logs.md#upload-support-bundle-diagnostics) to upload the output of the support-bundle command to Azure Blob Storage. > [!WARNING] > Output from the `support-bundle` command can contain host, device names, module names, and information logged by your modules. Be aware of this inclusion if sharing the output in a public forum. ## Review metrics collected from the runtime The IoT Edge runtime modules produce metrics to help you monitor and understand the health of your IoT Edge devices. Add the **metrics-collector** module to your deployments to handle collecting these metrics and sending them to the cloud for easier monitoring. For more information, see [Collect and transport metrics](how-to-collect-and-transport-metrics.md). ## Check your IoT Edge version If you're running an older version of IoT Edge, then upgrading might resolve your issue. The `iotedge check` tool checks that the IoT Edge security daemon is the latest version, but doesn't check the versions of the IoT Edge hub and agent modules. To check the version of the runtime modules on your device, use the commands `iotedge logs edgeAgent` and `iotedge logs edgeHub`. The version number is declared in the logs when the module starts up. For instructions on how to update your device, see [Update IoT Edge](how-to-update-iot-edge.md). ## Verify the installation of IoT Edge on your devices You can verify the installation of IoT Edge on your devices by [monitoring the edgeAgent module twin](./how-to-monitor-module-twins.md). To get the latest edgeAgent module twin, run the following command from [Azure Cloud Shell](https://shell.azure.com/):