Repository navigation
Windows: Flutter daemon startup can fail if SDK repair tries to rename dart-sdk while extension already spawned dart.exe processes #5995
Description
Summary
On Windows, the VS Code Flutter extension can fail to start the Flutter daemon when the Flutter SDK cache is missing bin/cache/engine-dart-sdk.stamp and the SDK tries to self-repair.
The failure appears to happen because the extension starts other Dart processes from bin/cache/dart-sdk (language server, DTD, DevTools) at essentially the same time that flutter daemon runs update_dart_sdk.ps1. The update script then tries to rename bin/cache/dart-sdk, but Windows denies access and the daemon exits after 3 retries.
Environment
- OS: Windows
- VS Code: 1.111.0
- Dart Code extension: 3.130.1
- Flutter extension: 3.130.0
- Flutter SDK: 3.41.4
- Dart SDK: 3.11.1
What happened
After the extension reloaded, it spawned these processes nearly simultaneously:
flutter.bat daemondart.exe language-serverdart.exe tooling-daemondart.exe devtools
Then the Flutter daemon logged:
Checking Dart SDK version...
Downloading Dart SDK from Flutter engine ...
Rename-Item: ...\update_dart_sdk.ps1:73
Access to the path '<user-home>\\tools\\flutter\\bin\\cache\\dart-sdk' is denied.
Error: Unable to update Dart SDK. Retrying...
...
Error: Unable to update Dart SDK after 3 retries.
Could Not Find <user-home>\\tools\\flutter\\bin\\cache\\engine-dart-sdk.stamp
The extension then showed:
The Flutter Daemon failed to start. Please review the log and file an issue on GitHub.
Why this looks extension-related
The key detail is that the extension starts multiple dart.exe processes out of the same bin/cache/dart-sdk directory before the Flutter daemon finishes validating/repairing that cache. On Windows, that can prevent the Flutter SDK from renaming the directory during repair.
This may require a partially broken cache to reproduce (for example, missing engine-dart-sdk.stamp), but once that state exists the extension appears to make recovery impossible by locking the folder it is trying to repair.
Expected behavior
If the Flutter SDK needs to repair/update its bundled Dart SDK, the extension should avoid starting other processes that lock bin/cache/dart-sdk until that step completes, or otherwise recover gracefully.
Actual behavior
The extension starts Dart-based helper processes immediately, update_dart_sdk.ps1 cannot rename bin/cache/dart-sdk, and the Flutter daemon exits after 3 retries.
Possible repro
I have not yet reduced this to minimal deterministic steps, but the observed sequence was:
- Have a Flutter SDK cache state where
bin/cache/engine-dart-sdk.stampis missing and the SDK attempts to refresh the Dart SDK. - Open VS Code with the Dart/Flutter extensions enabled.
- Let the Flutter extension activate and start the daemon.
- Observe concurrent startup of
flutter daemon, analyzer, DTD, and DevTools. - Observe
update_dart_sdk.ps1fail to renamebin/cache/dart-sdkwithAccess is denied, followed by daemon startup failure.
Suggestion
Consider delaying the startup of analyzer/DTD/DevTools processes that use the bundled Dart SDK until the Flutter daemon has confirmed the SDK/cache is usable, at least on Windows and especially when the cache repair path is triggered.
Activity
DanTup commentedon Mar 21, 2026
Thanks for the detailed report!
I'll do some testing, but my guess is that this is ultimately the same as #5971 which is fixed by #5982. With this change we will trigger
flutter --helpduring startup every time (instead of only when the Dart SDK is missing) so that if there's a valid Dart SDK but Flutter wants to replace it, it can do all of this before we start spawning services.I plan to publish a pre-release early next week that will include this, and it'll be in the stable release around the end/start of the month.
DanTup commentedon Mar 21, 2026
@pq @helin24 FYI - I don't know if IntelliJ might have similar issues. The problem here is that we can have what looks like a valid Flutter SDK on disk, so we start spawning services.. but then the first invocation of
fluttercan device that Dart SDK is out of date and start downloading another, which interferes with the processes we just spawned (either we may have locked files causing the SDK update to fail, or the SDK replaces parts of the Dart SDK as the analysis server loads and it crashes).My fix is just to ensure that we always run a
fluttercommand prior to starting up (flutter --helpis fastest). We already had this code for when the SDK looked incomplete, but now it's always run in a workspace with Flutter projects.DanTup commentedon Mar 22, 2026
I tested deleting
engine-dart-sdkand it did reproduce the same issue I saw in #5971, and with the fix, it's correctly handled (you'll now see the "Initializing Flutter SDK..." prompt while Flutter sets up, and then things continue afterwards).helin24 commentedon Mar 23, 2026
Thanks for the ping! I don't know either; I think we have a bunch of SDK-related issues that could be a good-sized plugin audit project, and this would fall into that.