Troubleshooting Flutter on Windows: Symlink Support and ms-settings:developers Command Issues

Symptoms

Building Flutter applications with plugins fails due to missing symlink support, and the command 'start ms-settings:developers' does not work in PowerShell.

Environment

Windows 10/11 with Flutter SDK installed

Most Likely Causes

Flutter requires symlink support for building applications with plugins, which is not enabled by default on Windows. Additionally, the command to open developer settings may not execute properly in PowerShell due to permission issues or incorrect command syntax.

What to Check First

1. Confirm OS build, domain or workgroup state, local admin rights, and whether the host is managed by GPO, Intune, or another baseline.
2. Collect the exact error code, Event Viewer entries, and the command or UI action that triggers the failure.
3. Check whether the issue follows the user profile, machine, network, or application package.

Fix Steps

1. Enable Developer Mode

   To enable symlink support, you need to turn on Developer Mode in Windows.

   Example pattern only. Adjust for your environment before running.

   Open Windows Settings by pressing Win + I.
   Navigate to 'Update & Security' > 'For developers'.
   Select 'Developer mode' and confirm any prompts to enable it.

2. Verify Symlink Support

   Check if symlink support is enabled by creating a test symlink.

   Example pattern only. Adjust for your environment before running.

   Open Command Prompt as Administrator.
   Run the command: mklink test_link.txt test_file.txt
   If the symlink is created successfully, symlink support is enabled.

3. Open Developer Settings in PowerShell

   Use the correct command to open developer settings in PowerShell.

   Safe to run: read-only

   Open PowerShell as Administrator.
   Run the command: start ms-settings:developers

4. Check PowerShell Execution Policy

   Ensure that the PowerShell execution policy allows running scripts.

   Changes system state: review before running

   Open PowerShell as Administrator.
   Run the command: Get-ExecutionPolicy
   If the policy is set to 'Restricted', change it by running: Set-ExecutionPolicy RemoteSigned

Validation

• The failing Windows action completes after reboot or service restart if the remediation requires one.
• Event Viewer stops logging the same error ID for the same component during a retest.
• The fix works for the affected standard user context, not only for an elevated administrator session.

Logs to Check

• Event Viewer: System, Application, Setup, WindowsUpdateClient, TerminalServices, or PowerShell logs as relevant.
• CBS.log, DISM.log, or WindowsUpdate.log when servicing or feature installation is involved.
• Security, RDP, or application-specific logs for authentication and session failures.

Rollback and Escalation

• Record the original registry, service, feature, policy, or firewall value before changing it.
• Undo temporary local policy, firewall, or service changes after validation.
• Use a restore point, VM snapshot, or exported configuration when changing servicing, boot, or security settings.

Escalate When

• Escalate if the same error persists after rollback and a clean retry from the original failing path.
• Escalate if logs show authorization, data loss, certificate, replication, or production availability risk outside the local service owner scope.

Edge Cases

• If the 'Developer mode' option is grayed out, ensure that your Windows version supports it and that you have the necessary permissions.
• If symlink creation fails, check if your user account has permissions to create symlinks, or try running Command Prompt as Administrator.

Notes from the Field

• If the machine is domain-managed, local fixes can be overwritten. Check the winning GPO or MDM policy before repeating the same change.
• Prefer read-only collection first on Windows incidents because many repair commands change component store, services, or user profile state.