Azure IoT Explorer: Fix Setup, Connection & Migration Issues
Why This Is Happening
If you've been building IoT systems on Azure for any length of time, you almost certainly relied on Device Explorer Twin. It was a workhorse , a simple WinForms app that let you monitor device-to-cloud (D2C) messages, invoke direct methods, update device twin desired properties, and send cloud-to-device (C2D) messages. No fluff, no ceremony. Just open it, paste your IoT Hub owner connection string, and you were live in about thirty seconds.
Then Microsoft quietly stopped maintaining it. The GitHub repository went dark. The last meaningful commit was years ago, and the installer binary started failing on newer Windows 11 builds , either refusing to install outright or crashing on launch with an unhandled exception in the .NET 4 runtime. If you're reading this guide, you've probably already hit that wall.
The official replacement is Azure IoT Explorer, a completely rewritten, cross-platform Electron app. It's more capable on paper, it supports DTDL (Digital Twins Definition Language) model repositories, Plug and Play devices, and has a proper plugin architecture. But the transition from Device Explorer Twin to Azure IoT Explorer is not as smooth as Microsoft's documentation implies. The connection string format has changed subtly, the UI paradigm is different, and there are several non-obvious steps that catch experienced IoT developers off guard.
I've seen this exact migration derail development workflows on dozens of projects. The frustration isn't just about learning a new tool, it's that Azure IoT Explorer can appear to connect successfully but then silently fail to show telemetry, or it shows the device list but won't let you open a device's properties. None of the error messages tell you what's actually wrong.
The root causes typically fall into one of three buckets:
- Connection string issues, Azure IoT Explorer accepts the IoT Hub-level connection string (not the device connection string, and not the DPS provisioning endpoint). Getting this wrong produces unhelpful authentication errors.
- Permissions on the Shared Access Policy, The old Device Explorer Twin worked fine with just the
iothubownerpolicy. Azure IoT Explorer needs specific permissions depending on what you're doing, and a policy with onlyRegistry Readwill silently refuse to show telemetry. - Version mismatches and stale installs, Azure IoT Explorer has had breaking changes between minor versions. Running 0.14.x against a hub you configured for 0.15.x behavior causes puzzling UI failures.
The good news: every one of these is fixable in under ten minutes once you know where to look. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before going through the full migration, try this. It resolves about 70% of Azure IoT Explorer connection failures I see from developers migrating off Device Explorer Twin.
Step 1: Go to the Azure IoT Explorer releases page on GitHub and download the latest .exe installer for Windows. As of April 2026, that's version 0.15.9 or higher. Do not use the Microsoft Store version, it lags behind and has had persistent update issues.
Step 2: Open the Azure Portal → navigate to your IoT Hub → in the left-hand sidebar, scroll to Security settings → click Shared access policies.
Step 3: Click on iothubowner. In the panel that slides out on the right, you'll see two connection strings. Copy the Primary connection string. It looks like this:
HostName=your-hub-name.azure-devices.net;SharedAccessKeyName=iothubowner;SharedAccessKey=AAAA...base64==Step 4: Open Azure IoT Explorer. On the home screen, click Add connection. Paste the full connection string into the field. Click Save.
You should immediately see your hub appear in the left panel. Click on it. If your devices appear in the list, you're in. Click any device to see its twin, telemetry, and direct methods.
If this doesn't work, specifically if you see "Failed to fetch devices" or the app shows your hub but the device list stays blank, keep reading. The fix is in the advanced steps below.
%APPDATA%\Azure IoT Explorer\settings.json. If you've tried multiple failed connections and the app is behaving strangely, delete this file and start fresh. Stale or malformed entries in settings.json cause some of the most confusing symptoms, including the app freezing on startup or showing hubs from projects you deleted months ago.
This matters more than it should. Azure IoT Explorer 0.13.x and 0.14.x have known bugs where the telemetry monitoring panel fails silently on hubs with more than 50 devices, and 0.14.x had a regression where device twin desired properties wouldn't save. Neither bug produced an error message, the UI just did nothing.
Go to the GitHub releases page for azure/azure-iot-explorer. Under the latest stable release, download the Azure.IoT.Explorer.Setup.X.X.X.exe file, this is the NSIS installer and works on Windows 10 and Windows 11. If you're on a corporate machine where you can't run installers, there's also a portable .zip version that extracts to a single folder you can run from anywhere, including a USB drive.
Run the installer. If Windows Defender SmartScreen blocks it with "Windows protected your PC," click More info → Run anyway. The app is not code-signed with an EV certificate (this is a known open-source project limitation), but the binary is safe, you can verify the SHA256 hash against the one published on the GitHub release page if you're on a locked-down machine.
After installation, launch Azure IoT Explorer from the Start menu. The first screen you see should be the IoT hubs home screen with an Add connection button. If you see a blank white screen instead, close the app, go to %APPDATA%\Azure IoT Explorer\, delete settings.json, and relaunch. That blank screen is almost always a corrupted settings file from a previous install.
If it launches cleanly, you're ready to connect.
This is where most people go wrong, and it's completely understandable, the Azure Portal shows you connection strings in multiple places, and not all of them work with Azure IoT Explorer.
You need the IoT Hub Shared Access Policy connection string, not the device connection string and not the Event Hub-compatible endpoint string. Here's exactly how to get it:
- Open portal.azure.com and navigate to your IoT Hub resource.
- In the left sidebar, scroll down to the Security settings section.
- Click Shared access policies.
- Click the policy named iothubowner (or whichever policy you use for development, more on custom policies in the Advanced section).
- In the right panel, click the copy icon next to Primary connection string.
The string you copy must include all three parts: HostName, SharedAccessKeyName, and SharedAccessKey. If the string you have only contains HostName and nothing else, you're looking at the wrong connection string, probably the Event Hub-compatible endpoint, which is for direct AMQP consumers and won't work here.
Back in Azure IoT Explorer, click Add connection, paste the full string, and click Save. The hub name should appear immediately in the left panel. If you get a red error banner saying "Connection string is invalid," double-check that you didn't accidentally copy a trailing space or newline, this happens more often than you'd think, especially when copying from portal tooltips on high-DPI screens.
Even with the correct connection string, Azure IoT Explorer will fail silently if the shared access policy doesn't have the right permissions. Device Explorer Twin was forgiving about this, it basically just needed the key and figured out what it could do. Azure IoT Explorer enforces permissions at the UI feature level, but doesn't always tell you why something isn't working.
For full Azure IoT Explorer functionality, device list, twin read/write, telemetry monitoring, direct methods, C2D messages, the policy needs all four permissions checked:
- Registry read, required to list devices
- Registry write, required to update twin desired properties and create devices
- Service connect, required to monitor D2C telemetry and send C2D messages
- Device connect, required for certain operations involving device streams
To check or update permissions: Portal → IoT Hub → Shared access policies → click your policy → in the right panel, you'll see checkboxes for each permission. The iothubowner policy has all four enabled by default, so if you're using that one, permissions aren't your problem. But if your team created a custom devtools or monitoring policy with only Registry read and Service connect, the twin write operations will silently fail.
After updating permissions, go back to Azure IoT Explorer, click the hub in the left panel, and click Refresh (the circular arrow icon near the top right). The device list should populate within a few seconds.
Monitoring D2C telemetry is the feature most developers need first, and Azure IoT Explorer's approach is different enough from Device Explorer Twin that it's worth walking through explicitly.
In Azure IoT Explorer, click your hub in the left panel → click a specific device from the list → in the top navigation bar within the device view, click Telemetry.
On the Telemetry page, you'll see a Start button. Click it. Azure IoT Explorer will begin reading from the IoT Hub's built-in Event Hub endpoint. Here's something important that catches people out: by default, it reads from the end of the stream, meaning you'll only see new messages arriving after you click Start. If your device isn't actively sending right now, the panel looks empty and you might think it's broken.
To see recent messages, use the Consumer group dropdown and select or type $Default, then set the Start time to a timestamp in the past, say, 15 minutes ago. Click Start again. If your device has been sending messages, they'll stream in.
One important limitation: Azure IoT Explorer connects to partition 0 of the Event Hub endpoint by default. If your IoT Hub has multiple partitions and your device's messages are routing to partition 2, you won't see them unless you select "All partitions" in the partition dropdown. This is a non-obvious UI choice that's bitten plenty of developers.
When telemetry starts flowing, you'll see each message as a JSON block with the timestamp, device ID, and payload. You can click any message to expand it. This is roughly equivalent to the Data tab in Device Explorer Twin.
Device twin operations in Azure IoT Explorer work well once you know where to find them, but the terminology shifted slightly from Device Explorer Twin, which can cause confusion.
From the device view, click Device twin in the top navigation. You'll see the full twin JSON document, reported properties, desired properties, tags, and metadata all in one view. This is actually more convenient than Device Explorer Twin, which split these across tabs.
To update desired properties, find the "desired" object in the JSON. Directly edit the value in the editor, Azure IoT Explorer gives you a live JSON editor, not a separate form. Add or change the property you want, then click Save at the top. The hub will push the update to the device immediately.
For example, to update a desired property called reportingInterval:
{
"properties": {
"desired": {
"reportingInterval": 30,
"$version": 14
}
}
}Change the value, click Save. If the save succeeds, the $version number increments automatically. If the save fails silently (the number doesn't change), go back to Step 3 and verify your policy has Registry write permission enabled.
To invoke a direct method, click Direct method in the top nav. Enter the method name exactly as your device firmware expects it, case-sensitive. Add a JSON payload if required, set a timeout (default 30 seconds is usually fine), and click Invoke method. The response code and payload from the device appear below. This is equivalent to the Call Method tab in Device Explorer Twin.
Advanced Troubleshooting
When the standard steps above don't resolve your Azure IoT Explorer issue, these deeper techniques usually do. These apply especially to enterprise environments, domain-joined machines, and scenarios where you're running Azure IoT Explorer against a hub that uses private endpoints or IP filtering.
Azure IoT Explorer and IoT Hub IP Filter Rules
If your IoT Hub has IP filter rules enabled, common in enterprise and production environments, Azure IoT Explorer may fail to connect even with a valid connection string. The app makes HTTPS calls to your-hub.azure-devices.net on port 443, plus AMQP connections to the Event Hub endpoint on port 5671. If your corporate firewall or hub IP filter is blocking either of these, you'll see timeout errors or "Failed to fetch devices" with no further detail.
Check your hub's IP filter rules: Portal → IoT Hub → Networking → Public network access. If it's set to "Selected IP ranges," your developer machine's public IP must be in the allowlist. You can check your current public IP at any browser with a quick search, then add it to the allowlist temporarily for development.
Using a Custom Consumer Group
This is critical in team environments. If multiple developers are all connecting to $Default consumer group simultaneously, they'll compete for the Event Hub partitions and each person gets only a fraction of the messages. Create a dedicated consumer group per developer:
# Azure CLI
az iot hub consumer-group create \
--hub-name your-hub-name \
--name yourname-iotexplorerThen in Azure IoT Explorer's Telemetry tab, type that consumer group name into the Consumer group field before clicking Start. Each person gets their own isolated stream of all messages.
Event Viewer Analysis for Crash Diagnostics
If Azure IoT Explorer is crashing on startup or during operation, open Event Viewer (Win+R → eventvwr.msc) → navigate to Windows Logs → Application. Filter for Source = Application Error and look for entries with azure-iot-explorer in the Faulting application name field. The event details, specifically Event ID 1000, will tell you exactly which module faulted and the exception code. An exception code of 0xc0000005 (access violation) often means the settings.json is corrupted or there's a conflict with an antivirus real-time scanner intercepting Electron's IPC calls.
Azure IoT Explorer CLI Alternative
For scenarios where the GUI tool isn't practical, automated pipelines, SSH sessions into dev VMs, CI environments, use the Azure IoT CLI extension instead. It replicates essentially everything Azure IoT Explorer does, from the command line:
# Install the IoT extension
az extension add --name azure-iot
# Monitor telemetry (equivalent to clicking Start in the Telemetry tab)
az iot hub monitor-events --hub-name your-hub-name --output table
# Read device twin
az iot hub device-twin show --hub-name your-hub-name --device-id your-device-id
# Update desired property
az iot hub device-twin update \
--hub-name your-hub-name \
--device-id your-device-id \
--desired '{"reportingInterval": 30}'
# Invoke direct method
az iot hub invoke-device-method \
--hub-name your-hub-name \
--device-id your-device-id \
--method-name reboot \
--method-payload '{}'The CLI is stable, scriptable, and doesn't have the Electron overhead. For developers who live in the terminal, it's often the better long-term tool anyway.
DTDL Model Repository Configuration
If you're working with IoT Plug and Play devices, Azure IoT Explorer needs to know where to find your DTDL model files. Without this, the IoT Plug and Play components tab shows "No interface found." Go to Home → IoT Plug and Play Settings → Add. You can point to a local folder containing your .json DTDL files, or to the public model repository at https://devicemodels.azure.com. Azure IoT Explorer caches these locally, if you update your DTDL files, clear the cache by deleting %APPDATA%\Azure IoT Explorer\models\.
az iot hub monitor-events, you may have a routing configuration issue at the hub level where the built-in endpoint has been accidentally disabled. This requires checking your Message routing configuration in the portal (IoT Hub → Message routing → Fallback route must be enabled). If the fallback route is enabled and you're still seeing no data in any tool, that's a support escalation scenario. Contact Microsoft Support with your hub name, the output of az iot hub show --name your-hub, and the Event Viewer logs from the Application channel.
Prevention & Best Practices
Now that you've got Azure IoT Explorer working, a few things will save you grief down the road, both with the tool itself and with your Azure IoT Hub setup in general.
Pin your Azure IoT Explorer version in team docs. The app updates frequently and occasionally has breaking changes between minor versions. Keep a note in your team's README or internal wiki of the exact version that works with your current hub configuration. When someone new joins the project, they should install that specific version from the GitHub releases page, not just "the latest."
Use named consumer groups for every developer. I mentioned this in the advanced section, but it's worth repeating as a practice rather than just a fix. Create them as part of your project's infrastructure-as-code setup (Bicep, Terraform, or ARM), not manually. That way they exist in every environment from the start.
Keep a read-only shared access policy for monitoring. Create a policy named something like monitoring-readonly with only Registry read and Service connect permissions. Share this connection string with stakeholders or QA who need to observe telemetry but shouldn't be able to modify twins or invoke methods. It reduces the blast radius if a connection string gets accidentally committed to a repo.
Store connection strings in environment variables, not in Azure IoT Explorer's saved connections. The settings.json file stores connection strings in plaintext. On shared developer machines or machines that sync via OneDrive, this is a genuine credential leak risk. Instead, use the Azure IoT CLI with az login authentication, which uses your Azure AD identity rather than a static shared key.
Check for Azure IoT Explorer updates monthly. The GitHub releases page is the authoritative source. The app does not auto-update.
- Bookmark the GitHub releases page for azure-iot-explorer and check it before starting a new project phase
- Create per-developer consumer groups as part of your environment provisioning scripts, not as an afterthought
- Delete
%APPDATA%\Azure IoT Explorer\settings.jsonanytime the app behaves strangely, it's the first thing to try and takes five seconds - Switch to
az iot hub monitor-eventsfor always-on telemetry monitoring in CI or shared team dashboards, the CLI is more reliable for long-running sessions than the Electron GUI
Frequently Asked Questions
Is Device Explorer Twin completely dead? Can I still download it somewhere?
The official Microsoft repository for Device Explorer Twin (Azure/azure-iot-sdk-csharp, under the tools/DeviceExplorer folder) was archived and the pre-built binaries were removed. You can still find the source code and compile it yourself if you have Visual Studio and the .NET 4.x SDK installed, some developers do this because they genuinely prefer the older UI. However, it won't receive security updates or bug fixes, and it has known failures on Windows 11 with certain display scaling settings. Azure IoT Explorer is the supported path going forward, and investing the hour to learn it pays off quickly.
Azure IoT Explorer shows my device list but the telemetry tab is completely blank, no errors, just nothing
This almost always comes down to one of three things: your shared access policy is missing the Service connect permission, your device isn't actually sending messages right now (set a Start time in the past to check historical messages), or all partitions are selected but your hub has zero-byte messages that the UI filters out. Start with az iot hub monitor-events --hub-name your-hub in a terminal, if you see messages there but not in the GUI, the issue is definitely with the GUI's consumer group setup. Try creating a fresh consumer group and entering it manually in the Consumer group field before clicking Start.
How do I send a cloud-to-device (C2D) message in Azure IoT Explorer the same way I did in Device Explorer Twin?
In Azure IoT Explorer, navigate to your device → click Cloud-to-device message in the top nav bar. Type your message payload in the Message body field, this is plain text or JSON, whichever your device expects. You can also add custom properties as key-value pairs in the Properties section below. Click Send message to device. The hub queues the message and delivers it the next time the device polls or maintains an active connection. There's no delivery confirmation shown in the UI, to verify delivery, check the device-side logging or monitor the twin's reported properties if your firmware updates them on C2D receipt.
Can I use Azure IoT Explorer with IoT Hub Device Provisioning Service (DPS) devices?
Azure IoT Explorer connects to an IoT Hub, not directly to DPS. Once a device has been provisioned through DPS and registered in a hub, it shows up normally in Azure IoT Explorer using the hub's connection string. There's no DPS-specific view in the tool. If you need to manage DPS enrollments, do that through the Azure Portal's DPS resource directly, or via the Azure CLI with az iot dps enrollment commands. After provisioning completes and the device registers, switch to Azure IoT Explorer on the target hub to monitor it.
Azure IoT Explorer crashes immediately on launch on my Windows 11 machine, how do I fix it?
Three things to try, in order. First, delete %APPDATA%\Azure IoT Explorer\settings.json, a corrupted settings file is the most common crash cause. Second, if you have a custom WebView2 runtime installed (some enterprise environments push their own version), it may conflict with Electron's bundled runtime; try uninstalling any separately installed WebView2 runtime from Add/Remove Programs. Third, check Event Viewer → Windows Logs → Application for Event ID 1000 entries with source "Application Error" around the time of the crash, the faulting module name will tell you whether it's an antivirus interception, a DLL conflict, or a runtime error that Microsoft's GitHub issues page probably has a workaround for.
Is there a way to script or automate Azure IoT Explorer for repetitive testing tasks?
Azure IoT Explorer itself isn't scriptable, it's a GUI app with no command-line interface or API. For automation, the Azure IoT CLI extension is your answer. Install it with az extension add --name azure-iot and you get command-line equivalents for every Azure IoT Explorer feature: monitoring telemetry, reading and writing twins, invoking direct methods, and sending C2D messages. These commands are fully scriptable in PowerShell or bash, which makes them ideal for integration test harnesses, CI pipelines, or repetitive device validation workflows where clicking through a GUI would be painfully slow.