Failure on Windows (ESP-IDF -128-NOTFOUND) (VSC-1862)

[kaedros]

OS

Windows

Operating System version

Windows 11 Pro 22H2

Visual Studio Code version

1.109.2

ESP-IDF version

5.5.2

Python version

3.8.7

Doctor command output

report.txt

Extension

esp_idf_vsc_ext.log

Description

After upgrading to the new SDK installation system (v5.5.2), the build system fails to identify the ESP-IDF version on Windows. The bootloader log shows:
(28) boot: ESP-IDF -128-NOTFOUND 2nd stage bootloader.

This seems to be a regression related to how paths are handled in the new installation flow, similar to the difficulties reported in the (now closed) issue #1760 regarding working with multiple/previous versions.

Expected behavior

The system should correctly identify the ESP-IDF version (e.g., v5.5.2) and the paths should be consistent with the OS standards.

Actual behavior

The build process mixes Linux-style forward slashes (/) and Windows-style backslashes () in the submodule worktree paths. This inconsistency prevents the build system from correctly parsing the SDK version.

Additional context

The transition to the new installation system has introduced significant friction, especially regarding backward compatibility.

1. Rigid Path Management: Unlike previous versions, the new installation method doesn't allow users to easily define custom paths for tools. This "black-box" approach makes it extremely difficult to maintain and switch between different projects that rely on older ESP-IDF versions.
2. Environment Instability: The path separator inconsistency (mixed / and ) mentioned above is a direct consequence of this new, less flexible environment management. It seems the build system is losing track of the environment context on Windows.
   We need the ability to define/override tool paths back, or at least a system that ensures path consistency across all submodules and build scripts on Windows.

Debug Message

Executing task: C:\Espressif\tools\cmake\3.30.2\bin\cmake.exe -G Ninja -DPYTHON_DEPS_CHECKED=1 -DESP_PLATFORM=1 -B c:\Users\username\Desktop\BriseII_FW\build -S c:\Users\tiago.davila\Desktop\BriseII_FW -DSDKCONFIG='c:\Users\username\Desktop\BriseII_FW\sdkconfig'

-- Found Git: C:/Program Files/Git/cmd/git.exe (found version "2.45.2.windows.1")
-- git describe returned 'fatal: bad config line 2 in file C:/Users/tiago.davila/.espressif/v5.5.2/esp-idf/.git/modules/components/bootloader/subproject/components/micro-ecc/micro-ecc/config'
fatal: bad config line 2 in file C:/Users/tiago.davila/.espressif/v5.5.2/esp-idf/.git/modules/components/bootloader/subproject/components/micro-ecc/micro-ecc/config
-- Minimal build - OFF
-- The C compiler identification is GNU 14.2.0
-- The CXX compiler identification is GNU 14.2.0
-- The ASM compiler identification is GNU
-- Found assembler: C:/Espressif/tools/xtensa-esp-elf/esp-14.2.0_20251107/xtensa-esp-elf/bin/xtensa-esp32-elf-gcc.exe
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done

Other Steps to Reproduce

1. Install ESP-IDF v5.5.2 via the VSCode Extension on Windows.
2. Create/Open any project.
3. Build the project.
4. Check the bootloader log or the initial compilation logs.

I have checked existing issues, online documentation and the Troubleshooting Guide

• I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[estevaofv]

Same error here. Also tested with another colleague and two other computers, I believe this error is related to the new installation manager, as I mentioned here:
espressif/idf-im-ui#450 (comment)

This also causes error when I try to apply any patch:
espressif/esp-adf#1585 (comment)

And VS Code does not recognize the esp-idf as a valid Git repository; for me the only valid solution so far was to downgrade the idf extension to v1.11.1 and disable the auto-update. I did not try v0.8.1, but it looks like it did not address this issue.

[radurentea]

Hi @kaedros, @estevaofv,

Sorry for the rough experience.

I was able to reproduce the issue and it appears to be related to the EIM.

They are currently working on a fix on this PR espressif/idf-im-ui#438, but the current build does not yet solve the issue. They are aware of it and are working on a fix for:

git describe returned 'fatal: bad config line 2 in file C:/esp/.espressif/master/esp-idf/.git/modules/components/bootloader/subproject/components/micro-ecc/micro-ecc/config'
fatal: bad config line 2 in file C:/esp/.espressif/master/esp-idf/.git/modules/components/bootloader/subproject/components/micro-ecc/micro-ecc/config

[radurentea]

Hi @kaedros, @estevaofv,

I've tested the latest build from here https://github.com/espressif/idf-im-ui/actions/runs/22482676664?pr=438 for windows (eim-gui-windows-x64-1782) and it looks like it solved the issue.

Could you guys test replacing the EIM with the one above and installing a new esp-idf version through it? Let me know if it fixes your issues.

[kaedros]

@radurentea thank you for sharing the build and for taking the time to investigate the issue.

Yes, all the problems started after the introduction of the new EIM. Unfortunately, it is no longer possible to properly validate the original scenario because ESP-IDF v5.5.2 can no longer be installed through EIM. The new mechanism is more restrictive than the previous installation system through extension, which allowed us to install and manage virtually any specific IDF version as needed — and it worked very well.

Therefore, it is not possible to reproduce exactly the same scenario.

That said, I tested the installer you mentioned (v8.0.1 debug build). The git describe failure on line 2 no longer occurs, so that specific issue appears to be resolved.

At the moment, we are limited to installing only the most recent available versions (currently v5.5.3). Since my original problem is specifically related to the environment setup involving v5.5.2, I cannot accurately confirm whether this new EIM build fully resolves the initial issue.

This limitation itself reinforces one of the concerns raised earlier — the reduced flexibility compared to the previous installation workflow, especially for projects that depend on maintaining exact older versions.

At this point, we have had to stop using EIM and revert to performing the installation manually using git clone and configuring VS Code ourselves. Although this approach is more labor-intensive, in practice it has proven to be more reliable and flexible.

[github-actions]

This issue has been marked as stale since there are no activities, and this will be closed in 5 days if there are no further activities