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 daemon
• dart.exe language-server
• dart.exe tooling-daemon
• dart.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:

1. Have a Flutter SDK cache state where bin/cache/engine-dart-sdk.stamp is missing and the SDK attempts to refresh the Dart SDK.
2. Open VS Code with the Dart/Flutter extensions enabled.
3. Let the Flutter extension activate and start the daemon.
4. Observe concurrent startup of flutter daemon, analyzer, DTD, and DevTools.
5. Observe update_dart_sdk.ps1 fail to rename bin/cache/dart-sdk with Access 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.