[Bug] Per-test CTest source resolution rescans every target source, freezing the extension host for minutes after each configure

[mewiof]

Brief Issue Summary

After 1.24.42 landed our workspace became unusable in VS Code.

On window open the status bar sits on "Configuring..." for several minutes with nothing further appearing in the CMake/Build output channel, and the extension host is unresponsive the whole time (other extensions stop answering, and opening a view shows "Activating Extensions..."). Launching a target looks the same. ninja reports no work to do, the log prints

[driver] Build completed: 00:00:00.748
[build] Build finished with exit code 0

and then nothing happens for minutes before the executable starts. This is every configure and every launch, not a one-off.

The project itself is fine. The same configure takes 2.1 s from the command line, a clean 662-step build takes 28.8 s, and the target is up in 0.26 s.

What it is doing

I profiled the extension host while it was stuck. All of the time is in CTest source resolution:

36.9%  existsSync
35.4%  readFileUtf8
16.7%  readFileSync
 8.3%  parseDoctestCases                          dist/main.js:7834
 0.6%  tryResolveTestSourceFromExecutableSources  dist/main.js:7760

tryResolveTestSourceFromExecutableSources walks every source file of the test's target once per test, and tryResolveDoctestLine does existsSync + readFileSync + a regex parse for each of those files, with nothing cached between tests:

for (const source of targetInfo.sources) {
    const candidateFile = path.resolve(targetInfo.sourceDir, source);
    const candidateLine = this.tryResolveDoctestLine(candidateFile, test.name);
    if (candidateLine !== undefined) { ... }
}

We use GoogleTest through gtest_discover_tests(), which registers 4093 CTest tests, and the test target has 250 sources. Those sources contain no doctest TEST_CASEs, so parseDoctestCases never matches, the loop never exits early, and every test ends up scanning all 250 files. That is up to 1,023,250 existsSync + readFileSync + parse calls, synchronously on the extension host, per configure.

Two things make it avoidable:

The expensive path runs before the cheap one. resolveTestSourceLocation calls tryResolveTestSourceFromExecutableSources first and only checks the DEF_SOURCE_LINE test property afterwards. gtest_discover_tests already writes DEF_SOURCE_LINE for every test it registers, so the correct file and line were available without touching the disk at all.

There is also no way to opt out. cmake.ctest.testExplorerIntegrationEnabled: false gates the post-build refreshTests call (#4909, #4914), but the post-configure call is unconditional:

const result = await drv.configure(trigger, []);
if (result.exitCode === 0) { ... }
await this.cTestController.refreshTests(drv);   // not gated

cmake.configureOnOpen: false does not help either, since it still runs off the cached configuration. I measured both and neither changed the profile.

Numbers

Same workspace, same settings, only the extension version changed. CPU time measured 240 s after opening the folder, with the machine otherwise idle:

Version	Extension host process	All VS Code processes
1.24.42	220.0 s, still climbing (~92% of one core, indefinitely)	242.8 s
1.22.28	5.0 s, flat after 40 s	14.2 s

We have pinned 1.22.28 as a workaround, which is also why the diagnostics block below reports 1.22.28 rather than 1.24.42.

Repro

1. A CMake project with a GoogleTest target registered through gtest_discover_tests(), where the test count multiplied by the number of sources in the test target is large. Ours is 4093 x 250, but it should be visible well below that.
2. Build once so CTest can enumerate the tests.
3. Open the folder with CMake Tools 1.24.42 and let it configure.
4. The extension host pegs a core for minutes after the configure has already finished.

Suggested fix

Check DEF_SOURCE_LINE before falling back to scanning target sources, and memoize the parse per file, since the same 250 files are read and parsed 4093 times in a row. Honoring cmake.ctest.testExplorerIntegrationEnabled on the post-configure refreshTests call would at least give people a way out in the meantime.

CMake Tools Diagnostics

{
  "os": "win32",
  "vscodeVersion": "1.137.0",
  "cmtVersion": "1.22.28",
  "configurations": [
    {
      "folder": "c:\Users\mewio\Documents\GitHub\Shalltear",
      "cmakeVersion": "4.2.0",
      "configured": true,
      "generator": "Ninja",
      "usesPresets": true,
      "compilers": {
        "C": "C:/Users/mewio/Documents/GitHub/Shalltear/External/Prebuilt/llvm-mingw/bin/x86_64-w64-mingw32-clang.exe",
        "CXX": "C:/Users/mewio/Documents/GitHub/Shalltear/External/Prebuilt/llvm-mingw/bin/x86_64-w64-mingw32-clang++.exe"
      }
    }
  ],
  "cpptoolsIntegration": {
    "isReady": false,
    "hasCodeModel": false,
    "activeBuildType": "",
    "buildTypesSeen": [],
    "requests": [],
    "responses": [],
    "partialMatches": [],
    "targetCount": 0,
    "executablesCount": 0,
    "librariesCount": 0,
    "targets": []
  },
  "settings": [
    {
      "communicationMode": "automatic",
      "useCMakePresets": "auto",
      "configureOnOpen": true
    }
  ]
}

Debug Log

cmake.loggingLevel: trace, cmake.showTimestampsInOutput: true. Configure finishes at 13:38:24.481 and the last line of any kind is 13:38:25.092; the extension host then stays pegged at ~93% of one core for minutes with nothing further logged.

2026-09-13T13:38:23.441Z [info] [proc] Executing command: "C:\Program Files\CMake\bin\cmake.EXE" -DCMAKE_BUILD_TYPE=Debug -DSHALLTEAR_BUILD_SHARED=ON -DCMAKE_C_COMPILER=... -DCMAKE_CXX_COMPILER=... -DCMAKE_MAKE_PROGRAM=... -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -S C:/Users/mewio/Documents/GitHub/Shalltear -B C:/Users/mewio/Documents/GitHub/Shalltear/build -G Ninja
2026-09-13T13:38:24.478Z [trace] [cache] Read line in cache with name=GIT_EXECUTABLE-ADVANCED, typename=INTERNAL, valuestr=1
2026-09-13T13:38:24.481Z [trace] [cache] Parsed 161 cache entries
2026-09-13T13:38:24.481Z [trace] [cache] Parsed 161 entries from C:/Users/mewio/Documents/GitHub/Shalltear/build/CMakeCache.txt
2026-09-13T13:38:25.092Z [trace] [rollbar] Invoking function [$] with Rollbar wrapping [$Resolving process on "close" event]

<nothing further; UI frozen from here>

Additional Information

The profile was taken by launching VS Code with --inspect-extensions and running a CPU profile against the extension host over the DevTools protocol while the freeze was in progress, on an otherwise idle machine. The A/B was run in a separate --user-data-dir and --extensions-dir so that nothing but the extension version differed between the two runs.

Environment: VS Code 1.137.0, Windows 11 build 26200, CMake 4.2.0, Ninja, clang 23.1.1 (llvm-mingw), 28 logical cores. Test target is 250 sources and 4093 CTest tests registered by gtest_discover_tests.

[yanghhhhhhh]

Hi mewiof , thank you for reporting this issue. We tried to check this issue in a test project on Visual Studio Code v1.137.0 + CMake Tools v1.24.42. Please refer to the video. Could you please check if our repro are the same as yours? If we missed something, please let us know. Thanks.

[mewiof]

Thanks for trying it. I can't see inside tests in the recording, but a single target called big_test sounds like one .cpp with all the cases in it, and that is the one shape that does not reproduce. The cost is per test times per source file in the test target (the for (const source of targetInfo.sources) loop runs inside the per-test loop), so 4000 tests in one file is 4000 cheap reads, while the same 4000 tests spread across 250 files is a million.

Here is a self-contained repro. The whole project is this one CMakeLists.txt; it generates the sources at configure time and fetches googletest itself. Also attached as a zip.

cmake_minimum_required(VERSION 3.24)
project(ctest_source_resolution_repro CXX)

# CMake Tools' cost is (CTest tests) x (source files in the test target). The
# defaults reproduce the report: 250 files x 16 cases = 4000 tests. Configure
# with -DREPRO_FILES=1 -DREPRO_TESTS_PER_FILE=4000 for the same number of tests
# in a single translation unit, which does not reproduce.
set(REPRO_FILES 250 CACHE STRING "source files in the test target")
set(REPRO_TESTS_PER_FILE 16 CACHE STRING "TEST() cases per source file")

include(FetchContent)
FetchContent_Declare(googletest
    URL https://github.com/google/googletest/archive/refs/tags/v1.15.2.zip
    DOWNLOAD_EXTRACT_TIMESTAMP TRUE)
set(gtest_force_shared_crt ON CACHE BOOL "" FORCE)
FetchContent_MakeAvailable(googletest)

set(gen_dir "${CMAKE_CURRENT_BINARY_DIR}/generated")
set(sources)
foreach(i RANGE 1 ${REPRO_FILES})
    set(f "${gen_dir}/file_${i}.cpp")
    set(body "#include <gtest/gtest.h>\n")
    foreach(j RANGE 1 ${REPRO_TESTS_PER_FILE})
        string(APPEND body "TEST(File${i}, Case${j}) { EXPECT_TRUE(true); }\n")
    endforeach()
    set(existing "")
    if(EXISTS "${f}")
        file(READ "${f}" existing)
    endif()
    if(NOT existing STREQUAL body)
        file(WRITE "${f}" "${body}")
    endif()
    list(APPEND sources "${f}")
endforeach()

add_executable(many_tests ${sources})
target_link_libraries(many_tests PRIVATE GTest::gtest_main)

enable_testing()
include(GoogleTest)
gtest_discover_tests(many_tests)

I ran it three ways today on VS Code 1.137.0 + CMake Tools 1.24.42, in a fresh --user-data-dir with only CMake Tools and its dependency installed, watching the extension host process after opening the folder:

Files x tests per file	Generator	Extension host CPU
250 x 16	Ninja	113.7 s, one core pegged for about two minutes, then done
250 x 16	Visual Studio 18 2026	114.2 s, same
1 x 4000	Ninja	3.5 s

Same 4000 tests in all three, and DEF_SOURCE_LINE is present for every test in all three CTest files. The generator makes no difference; the number of source files is the whole story. A CPU profile of the extension host during the 250-file runs is the same as the one in the report: 52.7% existsSync, 41.5% readFileUtf8, then parseDoctestCases and tryResolveTestSourceFromExecutableSources.

The generated files are 17 lines each, which is why it finishes in about two minutes here. Our real test sources are 470 lines median, 730 mean, and on the real project it was still going at four minutes when I stopped measuring. It is bounded work, it just scales with tests times sources times file size.

To see it:

1. Put the CMakeLists.txt in an empty folder and open it in VS Code with any kit or generator.
2. Configure and build once. The build is what lets gtest_discover_tests write the 4000 CTest entries.
3. Reload the window. Configure-on-open completes in well under a second, and the extension host then sits at 100% of a core with nothing further in the CMake/Build channel. Developer: Show Running Extensions, or Task Manager on the extension host process, shows it. Anything that goes through the extension host is stuck until it ends.

-DREPRO_FILES=1 -DREPRO_TESTS_PER_FILE=4000 gives the one-file variant, which is what I think your project is doing, and that one is fine.

ctest-source-resolution-repro.zip

[yanghhhhhhh]

Hi mewiof , thank you for the detailed information. We followed the steps to try to reproduce the issue, could you please take a look at this video? If we missed anything, please let us know. Thank you.

[mewiof]

That run does reproduce it. It is in your own video, in the Task Manager you open at the end.

The Visual Studio Code (11) group sits at 3.9%, and one child process inside it, the 263.3 MB one, is at 3.6%. That is not the renderer, which is listed separately as Running Extensions - ctest-source-resolution-repro at 0%. It holds between 3.3% and 4.5% for the whole time the window is open, with nothing happening in the editor.

The Processes tab reports share of all logical processors, not of one, so what 3.6% is worth depends on the core count of that machine. At 28 logical processors, which is what I have here, it is exactly one saturated core. The snippet at the end of this comment reports CPU seconds instead, so it needs no arithmetic either way.

The same frame has the other half of it. The status bar still reads Configuring project: ctest-source-resolution-repro, while the output channel just above it already shows -- Generating done (0.9s) and -- Build files have been written to. That gap is the whole report: cmake is done, the extension host is not.

Same shape here on the same repro, 250 files x 16 tests, Visual Studio generator, CMake Tools 1.24.42, sampling the extension host in ten second windows:

w1  pid 31836 = 3.6% of total  (100% of one core)  244 MB
w2  pid 31836 = 3.6% of total  (100% of one core)  244 MB
w3  pid 31836 = 3.6% of total  (100% of one core)  245 MB
w4  pid 31836 = 3.5% of total  ( 99% of one core)  246 MB
w5  pid 31836 = 3.5% of total  ( 99% of one core)  248 MB
w6  pid 31836 = 3.5% of total  ( 99% of one core)  250 MB

28 logical processors here, so one core is 3.57%, which is why it reads as 3.6%. The configure itself was Configuring done (1.7s) and Generating done (0.4s); everything after that is the test source resolution.

Two things make it look clean from the outside.

Developer: Show Running Extensions only reports activation time, the 159ms / 136ms / 75ms figures in your video. It does not report ongoing CPU, so an extension that activates in 136ms and then burns a core for two minutes looks exactly like an idle one. The button that does show it is the profile control at the top of that same view: start it during the stall, give it ten seconds, and parseDoctestCases and tryResolveTestSourceFromExecutableSources are the top frames.

Here is that snippet. Run it after a configure, while the editor looks idle:

$p = Get-Process code | Sort-Object WorkingSet64 -Descending | Select-Object -First 5
$a = @{}; $p | ForEach-Object { $a[$_.Id] = $_.CPU }
Start-Sleep 10
$p | ForEach-Object { '{0,6} {1,5:N1}s CPU in 10s ({2,3:N0}% of one core) {3,5:N0} MB' -f $_.Id, ($_.CPU - $a[$_.Id]), (10 * ($_.CPU - $a[$_.Id])), ($_.WorkingSet64/1MB) }

Idle, every process reports 0.0s. During the stall one of them reports close to 10.0s of CPU per 10 seconds of wall clock, and that one is the extension host. When it drops back to zero the scan has finished, which is about two minutes for this synthetic project and longer on a real one because the source files are bigger than 17 lines.

[yanghhhhhhh]

mewiof Thank you for the detailed information. We were able to reproduce this issue by following the repro steps. Thank you. (Sample project: ctest-source-resolution-repro.zip)
Env: VS Code Version: 1.137.0 + CMake Tools Version: 1.24.42

FYI: Garrett Campbell (@gcampbell-msft)