Windows binary crashes at startup with C++ exception 0xE06D7363 — reproduces v26.03.26 → v26.04.22

[dailylawgroup]

Summary

The Windows release binary (flapi-windows-amd64.zip) crashes immediately at startup on every Windows host I've tested, with an unhandled C++ exception. The crash fires consistently after credential-manager init logs and before any DuckDB engine init log line. Reproduces across at least 4 releases.

--validate-config always passes; the crash is purely at runtime initialization.

Environment

• OS: Windows 10 Pro (build 19045)
• Architecture: AMD64
• DuckDB file: tested with both an existing file created by DuckDB 1.5.1 and a fresh file flapi itself creates (via --access-mode READ_WRITE)
• Telemetry: disabled three ways (--no-telemetry CLI flag, DATAZOO_DISABLE_TELEMETRY=1, FLAPI_NO_TELEMETRY=1) — no change

Crash signature (consistent across versions)

[INFO]  Initializing cloud storage credentials...
[INFO]  Credential Manager Status:
[INFO]    S3: not configured
[INFO]    GCS: not configured
[INFO]    Azure: not configured
[ERROR] Unhandled Windows exception caught!
[ERROR] Exception code: e06d7363
[ERROR] Address: 00007FFE6C655369
[ERROR] Writing crash dump to crash_dump_<pid>.dmp

0xE06D7363 is the standard MSVC magic number for a throw statement, so something is throwing an exception that nothing catches. The address is consistent across runs and across versions, suggesting it's the same throw site.

Versions tested (all crash identically)

Version	Result
v26.04.22 (latest)	crash
v26.04.21	crash
v26.04.03	crash
v26.03.26	crash

Minimal reproduction

1. Download flapi-windows-amd64.zip from any release
2. Extract flapi.exe
3. Create config.yaml:

   project-name: repro
   project-description: Windows crash repro
   template:
     path: './sqls'
   duckdb:
     db-path: ./fresh.duckdb
     access-mode: READ_WRITE
     threads: 1
     max-memory: 1GB

4. Create empty sqls/ directory
5. Run: flapi.exe -c config.yaml --no-telemetry

Same crash, same address.

Diagnostics ruled out

I bisected and ruled out the obvious candidates:

• SQLite ATTACH connection — removing the entire connections: block doesn't fix it
• Existing DuckDB file format — crashes equally with a fresh empty file flapi creates itself
• Telemetry — disabled all three ways, no change in behavior
• Config schema — --validate-config passes cleanly; all _ keys converted to - per the v1.0+ schema
• Path resolution — tested with absolute and relative paths
• Credentials — no S3/GCS/Azure credentials configured (also tested with AWS_ACCESS_KEY_ID set to a dummy value, no change)

Hypothesis

The crash appears to be in the DuckDB engine init path (the next initialization phase after credential manager finishes logging). Recent commits like "Explicitly set MSVC static CRT (/MT) to fix LNK2038 with DuckDB 1.5.0" and "Switch Windows vcpkg triplet to x64-windows-static for DuckDB 1.5.0 /MT compatibility" suggest the Windows build path has had CRT-related fragility before. The bug persisting across 4 releases suggests the Windows binary may not be getting a functional smoke test in CI before release.

Workaround I'm using

Running the Linux binary inside WSL2 — works as expected.

Suggested triage

If the CI matrix doesn't include a step like "launch flapi.exe with a minimal config and curl /health on a Windows runner", that would catch this regression. I'm happy to:

• Share the crash_dump_*.dmp file
• Run additional diagnostics with a debug build if one is available
• Test fixes on Windows 10 Pro 19045 / Windows 11

Thanks for flAPI — even with this Windows wrinkle, the YAML-driven endpoint pattern + DuckDB integration is one of the cleanest data-API designs I've evaluated.

[dailylawgroup]

Update on bisection scope: I extended the test to 8 versions over a 13-month window. All crash identically with the same exception code at the same address.

Version	Date	Result
v26.04.22	2026-04-22	crash
v26.04.21	2026-04-21	crash
v26.04.03	2026-04-03	crash
v26.03.26	2026-03-26	crash
v26.02.17.1	2026-02-16	crash
v26.02.17	2026-02-15	crash
v26.02.15	2026-02-15	crash
v25.03.22	2025-03-22	crash

This strongly suggests the Windows binary path has been broken for at least 14 months, not introduced in a recent regression. The fact that no prior issue mentions it (this is #20, with 11 closed before it) suggests the Windows user community is essentially zero — Linux/Docker is where flAPI is actually used.

If the CI matrix doesn't currently include a Windows smoke step (download artifact → launch → curl /health), adding one would catch this immediately. Happy to test fix candidates on Windows 10 Pro 19045 if helpful.

[dailylawgroup]

Also tested the Python wheel as a potential workaround:

• pip install flapi-io (installs flapi_io-26.4.22-py3-none-win_amd64.whl)
• Reports same version 26.4.22
• Bundles the exact same flapi.exe (32,349,696 bytes, identical sha256)
• The wheel's __init__.py is a thin subprocess.call([binary] + sys.argv[1:]) wrapper — no bundled DLLs, no env fixup
• Crashes identically when invoked via python -c "from flapi_io import main_flapi_exe; main_flapi_exe()"

So the Python wheel doesn't bypass the issue — it ships the same broken binary. Worth knowing if anyone considers it as a Windows workaround.

For my own use I'm running the Linux binary in WSL2, which works as expected.

[dailylawgroup]

Tested the uvx --from flapi-io flapi -c flapi.yaml invocation per the PyPI README. Same crash, same address. uv 0.11.6, fresh ephemeral env, no shared parent state.

Now confirmed identical crash across 5 distinct invocation paths:

1. Raw bin/flapi.exe (downloaded from this release)
2. Raw older versions (8 releases over 13 months — bisection table above)
3. pip install flapi-io && python -m flapi_io
4. pip install flapi-io && python -c "from flapi_io import main_flapi_exe; main_flapi_exe()"
5. uvx --from flapi-io flapi -c config.yaml

So whatever's happening is in the C++ binary's own initialization code, not in environment setup, parent-shell quirks, working-directory issues, missing DLLs, or the Python wrapper layer. The bug travels with the binary itself.

The architectural takeaway for upstream: the PyPI distribution is a pure subprocess wrapper around the same broken Windows binary, so a CI fix needs to address the binary build, not the wheel packaging. The good news: when you do fix the binary, both PyPI and direct-download paths heal at once.

[dailylawgroup]

Final diagnostic data point: tested the pip-installed shim too.

pip install flapi-io creates a 108 KB launcher exe at Scripts/flapi.exe (standard pip console-script pattern). Running that directly: same crash, same address. So the failure mode is invariant across:

1. Raw downloaded binary
2. Older versions (8 releases / 13 months)
3. `python -c" with direct entry-point call
4. uvx --from flapi-io flapi (fresh ephemeral env)
5. pip install flapi-io && flapi (pip shim on PATH)
6. pip shim invoked from its install directory

Every wrapper layer eventually calls subprocess on the same bundled flapi.exe, which throws an unhandled C++ exception during DuckDB engine init. The bug is invariant to caller, env, working directory, and Python tooling.

I'll stop testing more invocation paths — this is structural. Falling back to WSL2 (Linux binary works as expected) for my own use.

[dailylawgroup]

Confirmed PE imports + isolated the crash site:

PE inspection (via pefile): flapi.exe imports only standard Windows system DLLs — dbghelp, RstrtMgr, USERENV, VERSION, WININET, WINHTTP, Secur32, ncrypt, KERNEL32, bcrypt, ADVAPI32, WS2_32, CRYPT32, IPHLPAPI, USER32, MSWSOCK. No MSVCR* / VCRUNTIME* imports — confirms /MT static CRT, no VCRedist needed. All 16 DLLs ship with Windows 10/11.

Crash address 0x00007FFE6C655369 is in system-DLL range (likely KernelBase!RaiseException or similar SEH helper) — i.e. the binary's own code is doing throw, the unwind hits no handler, the SEH unwinder shows the throw stub address.

Crash isolated to cloud-storage-credentials init phase, not later. Added storage.cache.enabled: false to config and the crash moved EARLIER — same exception, but no longer prints Credential Manager Status: ... not configured before crashing. Means the throw is somewhere inside Initializing cloud storage credentials...'s execution, BEFORE the status report.

Tested AWS SDK kill switches (AWS_SDK_LOAD_CONFIG=0, AWS_EC2_METADATA_DISABLED=true, AWS_CONFIG_FILE=NUL, AWS_SHARED_CREDENTIALS_FILE=NUL, AWS_PROFILE=_disabled_, etc.): no change in crash. ~/.aws directory does not exist on this host (so no SSO state to corrupt).

Likely culprit: the credential manager init code (probably built around aws-sdk-cpp with the sso, sts, secretsmanager features per vcpkg.json) is doing some Windows-specific call during initialization — possibly Windows credential store probe, registry access, or SSO token lookup — that throws an unhandled exception. Setting all the AWS-disabling env vars doesn't bypass it because the code path is run unconditionally before checking config.

One useful diagnostic for the maintainer: if there's a storage.credentials.enabled: false config block I'm missing that would skip the entire credential manager init, that would let me confirm. Alternatively, a CredentialManagerProvider::Initialize call site stack trace from the crash dump would localize it definitively. Happy to upload the .dmp file if useful.

[dailylawgroup]

Tested DuckLake-as-required hypothesis (per the README's 'DuckLake-backed caching (current implementation)' section). Same crash.

Configuration tested:

ducklake:
  enabled: true
  alias: cache
  metadata-path: ./local/cache.ducklake
  data-path: ./local/cache
  retention:
    max-snapshot-age: 14d
  compaction:
    enabled: false
  scheduler:
    enabled: false
mcp:
  enabled: false
storage:
  cache:
    enabled: false

Crash signature identical, same address, same phase (post-Credential-Manager-Status, pre-DuckLake-init logs).

Combinations tested matrix:

• ducklake.enabled = true with local paths → crash
• ducklake.enabled = false (default) → crash
• mcp.enabled = true → crash
• mcp.enabled = false → crash
• AWS env vars set (S3 reports 'configured') → crash
• AWS env vars unset (S3 reports 'not configured') → crash
• storage.cache.enabled = false → crash earlier (before credential status report)

Looks like the throw is unconditional and happens in the boot-sequence step that follows the credential manager's status report — possibly DuckDB engine initialization or some unconditional cache/scheduler bootstrap that runs whether or not DuckLake/cache are enabled.

Most useful debugging info from this round: the crash is invariant to every config option I've been able to toggle. Whatever code is throwing runs regardless of ducklake.enabled, mcp.enabled, storage.cache.enabled, or AWS credential state.

[dailylawgroup]

Did source-code RCA from the public repo. Throw site narrowed:

Boot sequence (main.cpp:338-347)

initializeCloudCredentials();        // ← LAST log we see (Credential Manager Status)
if (cmd_port != -1) ...               // skipped (no --port)
initializeDatabase(config_manager);   // ← throw site is HERE
configureCloudCredentialsInDuckDB();  // never reached
verifyStorageHealth(config_manager);  // never reached

initializeDatabase (main.cpp:136-142)

void initializeDatabase(std::shared_ptr<ConfigManager> config_manager) {
    try {
        DatabaseManager::getInstance()->initializeDBManagerFromConfig(config_manager);
    } catch (const std::exception& e) {
        throw std::runtime_error("Error creating database, Details: " + std::string(e.what()));
    }
}

If this rethrows, main()'s catch (const std::runtime_error&) block fires + logs "An unhandled exception occurred:". We never see that message. And we never see terminateHandler()'s "Unhandled exception caught! flapi is giving up :-(" either.

We ONLY see the Windows SEH SetUnhandledExceptionFilter handler (windowsExceptionHandler, main.cpp:208).

DatabaseManager::initializeDBManagerFromConfig (database_manager.cpp:115)

void DatabaseManager::initializeDBManagerFromConfig(...) {
    std::lock_guard<std::mutex> lock(db_mutex);
    if (!db) {
        duckdb_config config;
        std::string db_path = config_manager->getDuckDBPath();
        createAndInitializeDuckDBConfig(config_manager, config);    // ← candidate 1
        
        char* error = nullptr;
        if (duckdb_open_ext(db_path.c_str(), &db, config, &error)   // ← candidate 2
            == DuckDBError) { ... throw std::runtime_error(...) }
        
        duckdb_destroy_config(&config);                              // ← candidate 3
        
        logDuckDBVersion();      // ← "DuckDB version" log NEVER appears, so throw is BEFORE this
        loadDefaultExtensions(config_manager);
        initializeConnections(config_manager);
        ...
    }
}

We never see the "DuckDB version" log line, so the throw fires at one of three sites before logDuckDBVersion is called.

Why the C++ catch chain is bypassed

The SEH-level handler being the only thing that fires means the C++ exception unwinding is broken between the throw site and main()'s catch. The recent commit history is specifically about this:

• "fix: Explicitly set MSVC static CRT (/MT) to fix LNK2038 with DuckDB 1.5.0"
• "fix: Switch Windows vcpkg triplet to x64-windows-static for DuckDB 1.5.0 /MT compatibility"

Most likely root cause: a CRT runtime mismatch (e.g. /MD vs /MT) somewhere in the static dependency graph that links cleanly but breaks C++ exception unwinding at runtime. The throw at the DuckDB boundary (or inside duckdb_open_ext) hits a frame whose unwind tables don't match the SEH chain expectation, so _CxxFrameHandler doesn't unwind and the SEH exception escalates to the unhandled-filter.

Suggested investigation

1. Verify every add_library/add_executable in flAPI's CMake graph uses /MT consistently (not just the top-level target — every static archive too).
2. Check whether duckdb_static.lib from your vcpkg installation was actually built with /MT. The vcpkg triplet x64-windows-static should enforce this, but worth verifying with dumpbin /headers duckdb_static.lib | findstr -i runtime.
3. Particularly look at whether any /MD-built archive is accidentally pulled in via transitive vcpkg deps (fmt, crow, curl, aws-sdk-cpp features).

Happy to test a candidate fix on Windows 10 Pro 19045 if you want to ship a debug build with extra logging at createAndInitializeDuckDBConfig / duckdb_open_ext / duckdb_destroy_config. The crash dump from a fresh-config crash should show the exact throw frame in WinDbg.

[jrosskopf]

Update: cannot reproduce

We added platform smoke tests to CI (commit b3c9744) that start each binary with a file-based DuckDB database and verify the HTTP health endpoint. All four platforms passed in run 24994416975:

Platform	Result
Windows AMD64	✅ healthy after 2s
macOS ARM64	✅ pass
Linux AMD64	✅ pass
Linux ARM64	✅ pass

The smoke config matches your minimal repro exactly — file-based DuckDB (db_path: ./smoke-test.duckdb, access_mode: READ_WRITE) with MCP disabled and telemetry off.

The crash no longer reproduces on current main. The most likely fix is the DuckDB 1.5.1 → 1.5.2 upgrade in PR #19. These smoke tests are now a permanent gate on every release, so a regression like this can't ship undetected again.

Closing as fixed. Please reopen if you can still reproduce on a newer release.