[Bug] Emulator can't connect with my backend server on Windows WSL (ECONNRESET)
Version
Emulator version: 4.15.1
Describe the bug
When connecting to a local bot using the Bot Framework Emulator, the conversation.id includes a |livechat suffix (e.g., b9261fc1-57a1-11f0-8f54-bd61984248b7|livechat), and the serviceUrl is set to http://localhost:60844.
This causes the bot to attempt to POST a response to an unavailable service on port 60844, resulting in the following error:
FetchError: request to http://localhost:60844/v3/conversations/...|livechat/activities/... failed, reason: connect ECONNREFUSED 127.0.0.1:60844
This happens even when there is no explicit fetch to that URL in the bot's code — only standard context.sendActivity() calls via the Bot Framework SDK.
To Reproduce
Steps to reproduce the behavior:
- Open Bot Framework Emulator v4.15.1
- Connect to a bot running locally (e.g.,
http://localhost:3978/api/messages) - Observe the bot's
onTurnErroror middleware logcontext.activity - Notice that
conversation.idcontains|livechatandserviceUrlpoints tohttp://localhost:60844 - Any
sendActivity()results in aFetchErrordue to connection refusal on port60844
Expected behavior
When running in the Emulator, the conversation.id should not include |livechat, and the serviceUrl should point to the bot's actual listening address (e.g., http://localhost:3978). The Emulator should not simulate an unavailable "livechat" channel by default.
Screenshots
Not applicable for this issue (behavior is observed via logs and thrown errors).
Additional context
- This behavior causes the bot to fail on the first message, even when running locally.
- Workarounds include skipping activity handling when
conversation.idincludes|livechat, or manually overriding theserviceUrl, but this is not ideal for local development.
[bug]
Hi @tifilipebr, thanks for your comments.
I dont understand how the conversation.id and serviceUrl are related. The BF Emulator starts a web server in a random port, and sends that value to the bot in the serviceUrl, so the bot can POST the responses.
When running in the Emulator, the conversation.id should not include |livechat, and the serviceUrl should point to the bot's actual listening address (e.g., http://localhost:3978). The Emulator should not simulate an unavailable "livechat" channel by default.
That's not accurate, the serviceUrl should not be the same as the bot listening port, and I still do not understand what's the issue with the conversation.id.
To move forward, I'd suggest to take a look to the new M365 Agents Toolkit, that also includes a similar tool: https://github.com/OfficeDev/microsoft-365-agents-toolkit/releases/tag/teams-app-test-tool%400.2.13 , you can also install with winget install Microsoft.AgentsPlayground
Hi, thanks for your attention.
Maybe I wasn’t clear enough earlier. The issue happens when my bot (running on port 3978) tries to send a request to the web server started by the Emulator. It seems the error occurs when the server responds with ECONNREFUSED.
I don’t fully understand how the Bot Framework Emulator works behind the scenes, but the problem is specifically in the communication between my bot’s backend and the Emulator. That’s why I decided to report it as a bug.
Interestingly, when I run it on Linux (Ubuntu 24.04) using Emulator version 4.14.1, everything works perfectly. However, on Windows (I’ve tested from version 4.0.0 to 4.15.1), none of them work — they all show errors.
This week I started migrating from Ubuntu to Windows 11 Pro, and this issue impacted my workflow significantly. I’m currently working on implementing improvements and new features for a bot, and I got completely stuck because of this. To keep progressing with the tasks on my board, I had to switch back to Linux — just because of the Emulator (lol).
I was really happy to hear about the M365 Agents Toolkit, and I hope it works well as an alternative to the Emulator. Unfortunately, I don’t have time right now to dive into the Emulator source code to investigate further. But it's great to know there’s an alternative available.
I've seen those ECONNRESET errors in two scenarios.
- On first run, it will trigger an admin dialog to consent the firewall rule, if you miss, or cancel that dialog you might be in that state
- When the bot and the emulator run on different networks, eg, from docker or WSL.
As a quick and dirty workaround, can you re-install and make sure you allow the firewall rule on first run?
Hi @rido-min, I reinstalled the BFE and it didn’t trigger the administrator dialog box to consent to the firewall rule — I think that’s where the problem is. The error persists.
can you check your firewall? Control Panel\System and Security\Windows Defender Firewall\Allowed apps
you should see bot framework emulator.exe and should have the Private Network checked.
you can also try to uninstall, delete the rule, and install again, and hopefully on first run you will see the consent dialog
Hello @rido-min, thank you for your attention. I followed your instructions, but unfortunately the issue persists. I'm still receiving the same error when my backend tries to send a message to the emulator.
wait.. this might happen because accessing localhost from WSL requires some config, see https://learn.microsoft.com/en-us/windows/wsl/networking#accessing-windows-networking-apps-from-linux-host-ip
also, keep in mind that we just announced the deprecation of this repo, I encourage you to take a look to the AgentsPlayground. To make it work in WSL you should install it in WSL with:
LATEST_TAG=$(curl -s https://api.github.com/repos/OfficeDev/microsoft-365-agents-toolkit/releases | grep -o '"tag_name": "microsoft-365-agents-playground@[^"]*"' | head -1 | cut -d'"' -f4) && curl -L -o agentsplayground.zip "https://github.com/OfficeDev/microsoft-365-agents-toolkit/releases/download/${LATEST_TAG}/agentsplayground-linux-x64.zip" && python3 -m zipfile -e agentsplayground.zip . && chmod +x agentsplayground
note: official docs will be published soon