[BUG] After upgrading to version v.3.6.0.0 PerformanceMonitorLite cannot start

[H-Engmark]

Component

Lite

Performance Monitor Version

3.6.0.0

SQL Server Version

SQL Server 2019 (RTM-CU32-GDR) (KB5102335) - 15.0.4480.2 (X64)

Windows Version

Windows Server 2019 Datacenter 10.0 (Build 17763: ) (Hypervisor)

Describe the Bug

After ugrading to version 3.6.0.0 PerformanceMonitorLite cannot start.
There are errors found in the lite_xxxxxx.log log file. These are pasted in below.

Steps to Reproduce

Upgrade PerformanceMonitorLite to version 3.6.0.0

Expected Behavior

I would like PerformanceMonitorLite to start.

Actual Behavior

PerformanceMonitorLite does not start.

Error Messages / Log Output

PerformanceMonitorLite does not start.

Screenshots

No response

Additional Context

2026-08-31 08.41.08.990 [INFO ] [DataRoot] Moved Lite's data out of the install directory 'C:\Users\adm-hce\AppData\Local\PerformanceMonitorLite' and into 'C:\Users\adm-hce\AppData\Local\PerformanceMonitorLite-Data' (#1832): config, archive, logs, monitor.duckdb, monitor.duckdb.wal, alert_state.json. Re-running Setup.exe deletes the install directory, which is why data kept there did not survive an installer upgrade.
2026-08-31 08.41.09.992 [INFO ] [AppLogger] Logging initialized
2026-08-31 08.41.09.995 [INFO ] [App] Starting PerformanceMonitorLite v3.6.0.0
2026-08-31 08.41.09.995 [INFO ] [App] Data directory: C:\Users\adm-hce\AppData\Local\PerformanceMonitorLite-Data
2026-08-31 08.41.10.614 [INFO ] [ServerManager] Loaded 2 servers from configuration
2026-08-31 08.41.10.632 [INFO ] [ProfileManager] Loaded 0 credential profiles
2026-08-31 08.41.10.817 [INFO ] [DuckDbInitializer] Initializing DuckDB database at C:\Users\adm-hce\AppData\Local\PerformanceMonitorLite-Data\monitor.duckdb
2026-08-31 08.41.16.741 [INFO ] [DuckDbInitializer] Schema upgrade needed: v47 -> v56
2026-08-31 08.41.16.755 [INFO ] [DuckDbInitializer] Running migration to v48: server_properties hardware columns become nullable
2026-08-31 08.41.16.759 [ERROR] [DuckDbInitializer] Failed to execute SQL: ALTER TABLE server_properties ALTER COLUMN cpu_count DROP NOT NULL | DuckDBException: Dependency Error: Cannot alter entry "server_properties" because there are entries that depend on it.
2026-08-31 08.41.16.776 [ERROR] [DuckDbInitializer] Stack: at DuckDB.NET.Data.PreparedStatement.PreparedStatement.Execute(DuckDBParameterCollection parameterCollection, Boolean useStreamingMode, DuckDBNativeConnection connection)
at DuckDB.NET.Data.PreparedStatement.PreparedStatement.PrepareMultiple(DuckDBNativeConnection connection, String query, DuckDBParameterCollection parameters, Boolean useStreamingMode)+MoveNext()
at DuckDB.NET.Data.DuckDBCommand.ExecuteNonQuery()
at System.Data.Common.DbCommand.ExecuteNonQueryAsync(CancellationToken cancellationToken)
--- End of stack trace from previous location ---
at PerformanceMonitorLite.Database.DuckDbInitializer.ExecuteNonQueryAsync(DuckDBConnection connection, String sql)
2026-08-31 08.41.16.776 [WARN ] [DuckDbInitializer] Migration to v48 on cpu_count encountered an error (non-fatal): Dependency Error: Cannot alter entry "server_properties" because there are entries that depend on it.
2026-08-31 08.41.16.776 [ERROR] [DuckDbInitializer] Failed to execute SQL: ALTER TABLE server_properties ALTER COLUMN hyperthread_ratio DROP NOT NULL | DuckDBException: Dependency Error: Cannot alter entry "server_properties" because there are entries that depend on it.
2026-08-31 08.41.16.777 [ERROR] [DuckDbInitializer] Stack: at DuckDB.NET.Data.PreparedStatement.PreparedStatement.Execute(DuckDBParameterCollection parameterCollection, Boolean useStreamingMode, DuckDBNativeConnection connection)
at DuckDB.NET.Data.PreparedStatement.PreparedStatement.PrepareMultiple(DuckDBNativeConnection connection, String query, DuckDBParameterCollection parameters, Boolean useStreamingMode)+MoveNext()
at DuckDB.NET.Data.DuckDBCommand.ExecuteNonQuery()
at System.Data.Common.DbCommand.ExecuteNonQueryAsync(CancellationToken cancellationToken)
--- End of stack trace from previous location ---
at PerformanceMonitorLite.Database.DuckDbInitializer.ExecuteNonQueryAsync(DuckDBConnection connection, String sql)
2026-08-31 08.41.16.777 [WARN ] [DuckDbInitializer] Migration to v48 on hyperthread_ratio encountered an error (non-fatal): Dependency Error: Cannot alter entry "server_properties" because there are entries that depend on it.
2026-08-31 08.41.16.777 [ERROR] [DuckDbInitializer] Failed to execute SQL: ALTER TABLE server_properties ALTER COLUMN physical_memory_mb DROP NOT NULL | DuckDBException: Dependency Error: Cannot alter entry "server_properties" because there are entries that depend on it.
2026-08-31 08.41.16.777 [ERROR] [DuckDbInitializer] Stack: at DuckDB.NET.Data.PreparedStatement.PreparedStatement.Execute(DuckDBParameterCollection parameterCollection, Boolean useStreamingMode, DuckDBNativeConnection connection)
at DuckDB.NET.Data.PreparedStatement.PreparedStatement.PrepareMultiple(DuckDBNativeConnection connection, String query, DuckDBParameterCollection parameters, Boolean useStreamingMode)+MoveNext()
at DuckDB.NET.Data.DuckDBCommand.ExecuteNonQuery()
at System.Data.Common.DbCommand.ExecuteNonQueryAsync(CancellationToken cancellationToken)
--- End of stack trace from previous location ---
at PerformanceMonitorLite.Database.DuckDbInitializer.ExecuteNonQueryAsync(DuckDBConnection connection, String sql)
2026-08-31 08.41.16.777 [WARN ] [DuckDbInitializer] Migration to v48 on physical_memory_mb encountered an error (non-fatal): Dependency Error: Cannot alter entry "server_properties" because there are entries that depend on it.
2026-08-31 08.41.16.777 [INFO ] [DuckDbInitializer] Running migration to v49: query_store_stats interval identity columns
2026-08-31 08.41.16.797 [INFO ] [DuckDbInitializer] Running migration to v50: adding plan_correction table
2026-08-31 08.41.16.797 [INFO ] [DuckDbInitializer] Running migration to v51: adding pvs_stats table
2026-08-31 08.41.16.797 [INFO ] [DuckDbInitializer] Running migration to v52: adding host_object_name to query_stats
2026-08-31 08.41.16.802 [INFO ] [DuckDbInitializer] Running migration to v53: adding the alerted-state memory to config_database_state_expected
2026-08-31 08.41.16.805 [ERROR] [DuckDbInitializer] Failed to execute SQL: ALTER TABLE config_database_state_expected ADD COLUMN IF NOT EXISTS last_alerted_state VARCHAR | DuckDBException: Catalog Error: Table with name config_database_state_expected does not exist!
Did you mean "pg_database"?
2026-08-31 08.41.16.806 [ERROR] [DuckDbInitializer] Stack: at DuckDB.NET.Data.PreparedStatement.PreparedStatement.PrepareMultiple(DuckDBNativeConnection connection, String query, DuckDBParameterCollection parameters, Boolean useStreamingMode)+MoveNext()
at DuckDB.NET.Data.DuckDBCommand.ExecuteNonQuery()
at System.Data.Common.DbCommand.ExecuteNonQueryAsync(CancellationToken cancellationToken)
--- End of stack trace from previous location ---
at PerformanceMonitorLite.Database.DuckDbInitializer.ExecuteNonQueryAsync(DuckDBConnection connection, String sql)
2026-08-31 08.41.16.806 [INFO ] [DuckDbInitializer] Running migration to v54: adding config_incident_occurrences
2026-08-31 08.41.16.809 [INFO ] [DuckDbInitializer] Running migration to v55: adding collection_log fan-out rollup columns
2026-08-31 08.41.16.822 [INFO ] [DuckDbInitializer] Running migration to v56: adding max_size_mb to tempdb_stats
2026-08-31 08.41.17.001 [INFO ] [DuckDbInitializer] Schema initialization created 96 tables
2026-08-31 08.41.17.001 [INFO ] [DuckDbInitializer] Database initialization complete. Schema version: 56
2026-08-31 08.41.19.196 [INFO ] [DuckDbInitializer] Archive-view refresh sees 96 tables
2026-08-31 08.41.20.590 [INFO ] [DuckDbInitializer] Analysis schema initialized at version 5

[erikdarlingdata]

Thanks for the detailed log — it let me pin down two real bugs in the v47→v56 upgrade path, both now fixed in #2750:

1. The v48 migration (making three server_properties columns nullable) fails on any database that's completed at least one prior startup, because a pre-existing index on the table blocks DuckDB's ALTER COLUMN.
2. The v53 migration (adding two columns to config_database_state_expected) fails because that table doesn't exist yet at the point the migration runs, on a database old enough to predate it.

Both match your log exactly. However, I don't think either one is actually why the app fails to start — both are logged as non-fatal and the migration chain completes to v56 either way (as your log shows), and neither failure mode should produce a hard crash on its own.

Your pasted log stops right after Analysis schema initialized at version 5 — could you share what comes after that? Specifically:

• Any further lines in the same lite_*.log file (does it just stop, or is there more?)
• Whether a message box or error dialog appeared, and its exact text
• If nothing else got logged and the window just never appears, a Windows Event Viewer entry (Application log, around the same timestamp) would help — WPF unhandled exceptions sometimes don't make it into the app's own log

That'll help confirm whether #2750 actually resolves your startup failure or whether there's a third bug still to find. Leaving this open until we know for sure.

[H-Engmark]

This is the remaining lines of the log:

2026-08-31 08.41.20.698 [INFO ] [CollectionBackgroundService] Collection background service started
2026-08-31 08.41.20.844 [INFO ] [RemoteCollectorService] Delta calculator seeded from database (baselines from the last 15 minutes)
2026-08-31 08.41.20.881 [INFO ] [QueryStoreSliceRepairService] #1912 one-time Query Store repair starting: 31426 split interval(s) in the hot store, 0 archive file(s) affected
2026-08-31 09.28.52.785 [INFO ] [AppLogger] Logging initialized
2026-08-31 09.28.52.786 [INFO ] [App] Starting PerformanceMonitorLite v3.6.0.0
2026-08-31 09.28.52.786 [INFO ] [App] Data directory: C:\Users\adm-hce\AppData\Local\PerformanceMonitorLite-Data
2026-08-31 09.28.53.478 [INFO ] [ServerManager] Loaded 2 servers from configuration
2026-08-31 09.28.53.494 [INFO ] [ProfileManager] Loaded 0 credential profiles
2026-08-31 09.28.53.965 [INFO ] [DuckDbInitializer] Initializing DuckDB database at C:\Users\adm-hce\AppData\Local\PerformanceMonitorLite-Data\monitor.duckdb
2026-08-31 09.28.54.855 [INFO ] [DuckDbInitializer] Schema initialization created 102 tables
2026-08-31 09.28.54.855 [INFO ] [DuckDbInitializer] Database initialization complete. Schema version: 56
2026-08-31 09.28.55.172 [INFO ] [DuckDbInitializer] Archive-view refresh sees 102 tables
2026-08-31 09.28.57.133 [INFO ] [CollectionBackgroundService] Collection background service started
2026-08-31 09.28.57.220 [INFO ] [RemoteCollectorService] Delta calculator seeded from database (baselines from the last 15 minutes)
2026-08-31 09.28.57.281 [INFO ] [QueryStoreSliceRepairService] #1912 one-time Query Store repair starting: 31426 split interval(s) in the hot store, 0 archive file(s) affected

And from Event Viewer:

Faulting application name: PerformanceMonitorLite.exe, version: 3.6.0.0, time stamp: 0x6a630000
Faulting module name: duckdb.DLL, version: 1.5.5.0, time stamp: 0x6a5f61de
Exception code: 0xc0000409
Fault offset: 0x000000000183c325
Faulting process id: 0x3068
Faulting application start time: 0x01dd3913b472dff1
Faulting application path: C:\Users\adm-hce\AppData\Local\PerformanceMonitorLite\current\PerformanceMonitorLite.exe
Faulting module path: C:\Users\adm-hce\AppData\Local\PerformanceMonitorLite\current\duckdb.DLL
Report Id: 390ae3a6-5d1d-4be4-89d5-7c588358fc31
Faulting package full name:
Faulting package-relative application ID:

There is no message box, the app tries to start, the windows shows and then short after closing.

[erikdarlingdata]

Thanks for the extra log — this is genuinely useful. Confirmed a real lead, though I want to be precise about what's actually established versus what's still a working theory.

What the log shows: right after your last confirmed line, three more get logged at 08:41:20 — collection background service started, delta calculator seeded, and then:

`[QueryStoreSliceRepairService] #1912 one-time Query Store repair starting: 31426 split interval(s) in the hot store, 0 archive file(s) affected`

Then nothing else is logged for ~47 minutes, until a completely fresh app launch begins at 09:28:52.

What I found in the code: that repair is fired fire-and-forget on a background thread (it genuinely doesn't block the app window itself — I confirmed this directly in the source), so if the window appeared but the app seemed frozen/non-functional, this fits. Digging further, I found a real mechanism that would explain exactly that: the repair's survey step (counting up the split rows before doing anything) holds an uncancelable database read lock for its entire duration — a full scan across your hot table plus every archive file — and while that lock is held, every other part of the app trying to WRITE new data (i.e., ordinary live collection) blocks waiting for it. For 31,426 split intervals, that survey could plausibly run long enough to explain a stretch like this, and while it does, the app would look completely stalled — nothing new arriving anywhere — even though the window is technically alive.

I filed that as its own issue (#2761) since it's a real gap regardless of whether it's exactly what you hit, and it needs a careful look given how much locking-related care already went into this code.

What I couldn't do: reproduce this against a store anywhere near your scale, so I can't give you a hard "yes, this is definitely it." One thing that would settle it: when you relaunched around 09:28, did the repair message appear again in the log (same "#1912 one-time Query Store repair starting" line), or did it skip straight past that step? The repair records a completion marker once it finishes successfully — if the second launch's log doesn't repeat that line, it means the first attempt actually finished (just slowly), which would point elsewhere; if it repeats, it strongly confirms the first attempt never completed and this is the cause.

Leaving this open pending that.

[H-Engmark]

This morning I tried opening the app and the same thing happened. It closes again after a short time.

This is the complete log:

2026-09-02 06.53.19.804 [INFO ] [AppLogger] Logging initialized
2026-09-02 06.53.19.807 [INFO ] [App] Starting PerformanceMonitorLite v3.6.0.0
2026-09-02 06.53.19.807 [INFO ] [App] Data directory: C:\Users\adm-hce\AppData\Local\PerformanceMonitorLite-Data
2026-09-02 06.53.20.634 [INFO ] [ServerManager] Loaded 2 servers from configuration
2026-09-02 06.53.20.651 [INFO ] [ProfileManager] Loaded 0 credential profiles
2026-09-02 06.53.21.173 [INFO ] [DuckDbInitializer] Initializing DuckDB database at C:\Users\adm-hce\AppData\Local\PerformanceMonitorLite-Data\monitor.duckdb
2026-09-02 06.53.22.270 [INFO ] [DuckDbInitializer] Schema initialization created 102 tables
2026-09-02 06.53.22.270 [INFO ] [DuckDbInitializer] Database initialization complete. Schema version: 56
2026-09-02 06.53.22.599 [INFO ] [DuckDbInitializer] Archive-view refresh sees 102 tables

This is logged in the Event Viewer:

Faulting application name: PerformanceMonitorLite.exe, version: 3.6.0.0, time stamp: 0x6a630000
Faulting module name: duckdb.DLL, version: 1.5.5.0, time stamp: 0x6a5f61de
Exception code: 0xc0000409
Fault offset: 0x000000000183c325
Faulting process id: 0x4c4c
Faulting application start time: 0x01dd3a96f87f0955
Faulting application path: C:\Users\adm-hce\AppData\Local\PerformanceMonitorLite\current\PerformanceMonitorLite.exe
Faulting module path: C:\Users\adm-hce\AppData\Local\PerformanceMonitorLite\current\duckdb.DLL
Report Id: d547f995-e50e-4500-9621-3a782cdc4329
Faulting package full name:
Faulting package-relative application ID:

Fault bucket 1982067391818764239, type 5
Event Name: BEX64
Response: Not available
Cab Id: 0

Problem signature:
P1: PerformanceMonitorLite.exe
P2: 3.6.0.0
P3: 6a630000
P4: duckdb.DLL
P5: 1.5.5.0
P6: 6a5f61de
P7: 000000000183c325
P8: c0000409
P9: 0000000000000007
P10:

[H-Engmark]

After second attempt to start the app, more lines added to the log:

This is the complete log file:

2026-09-02 06.53.19.804 [INFO ] [AppLogger] Logging initialized
2026-09-02 06.53.19.807 [INFO ] [App] Starting PerformanceMonitorLite v3.6.0.0
2026-09-02 06.53.19.807 [INFO ] [App] Data directory: C:\Users\adm-hce\AppData\Local\PerformanceMonitorLite-Data
2026-09-02 06.53.20.634 [INFO ] [ServerManager] Loaded 2 servers from configuration
2026-09-02 06.53.20.651 [INFO ] [ProfileManager] Loaded 0 credential profiles
2026-09-02 06.53.21.173 [INFO ] [DuckDbInitializer] Initializing DuckDB database at C:\Users\adm-hce\AppData\Local\PerformanceMonitorLite-Data\monitor.duckdb
2026-09-02 06.53.22.270 [INFO ] [DuckDbInitializer] Schema initialization created 102 tables
2026-09-02 06.53.22.270 [INFO ] [DuckDbInitializer] Database initialization complete. Schema version: 56
2026-09-02 06.53.22.599 [INFO ] [DuckDbInitializer] Archive-view refresh sees 102 tables
2026-09-02 07.05.41.980 [INFO ] [AppLogger] Logging initialized
2026-09-02 07.05.41.981 [INFO ] [App] Starting PerformanceMonitorLite v3.6.0.0
2026-09-02 07.05.41.981 [INFO ] [App] Data directory: C:\Users\adm-hce\AppData\Local\PerformanceMonitorLite-Data
2026-09-02 07.05.42.633 [INFO ] [ServerManager] Loaded 2 servers from configuration
2026-09-02 07.05.42.650 [INFO ] [ProfileManager] Loaded 0 credential profiles
2026-09-02 07.05.43.137 [INFO ] [DuckDbInitializer] Initializing DuckDB database at C:\Users\adm-hce\AppData\Local\PerformanceMonitorLite-Data\monitor.duckdb
2026-09-02 07.05.44.060 [INFO ] [DuckDbInitializer] Schema initialization created 102 tables
2026-09-02 07.05.44.061 [INFO ] [DuckDbInitializer] Database initialization complete. Schema version: 56
2026-09-02 07.05.44.397 [INFO ] [DuckDbInitializer] Archive-view refresh sees 102 tables
2026-09-02 07.05.46.183 [INFO ] [CollectionBackgroundService] Collection background service started
2026-09-02 07.05.46.275 [INFO ] [RemoteCollectorService] Delta calculator seeded from database (baselines from the last 15 minutes)
2026-09-02 07.05.46.334 [INFO ] [QueryStoreSliceRepairService] #1912 one-time Query Store repair starting: 31426 split interval(s) in the hot store, 0 archive file(s) affected

[erikdarlingdata]

Found it, and reproduced it. Thank you for the Event Viewer entry and the second log — between them they settled it, and the detail that mattered most was the one you might have thought was redundant: the repair line repeating on the relaunch. That confirmed the first attempt never finished, which is what turned a slow operation into a permanent one.

What is happening

The 0xc0000409 in duckdb.DLL is a fast-fail — the native library aborting the process outright, not a .NET exception. That matters because the repair is deliberately wrapped so that a store which cannot be repaired still lets the app start. A native abort goes around that handler entirely: the process is gone mid-statement, nothing gets recorded, and the next launch re-surveys, finds the same 31,426 split intervals, runs the same statement and dies the same way. That is the loop you are in.

The underlying cost is memory. The repair has to stage every collapsed interval — including query_plan_text, which holds full showplan XML — inside a connection Lite caps at memory_limit=1GB. I reproduced this locally at your exact scale with realistic plan payloads:

Out of Memory Error: failed to pin block of size 256.0 KiB (953.6 MiB/953.6 MiB used)

Same data and same statements at a 6GB limit complete fine, which pins the cause to the budget rather than anything about your particular rows. On my machine it raises a catchable error; on Windows the same pressure aborts the process, which is why you get a crash and no log line.

Unblocking you now

You do not need to wait for a release. The repair is skipped once the store carries its completion marker, so writing that marker by hand gets you straight back in. With PerformanceMonitorLite closed, open your store with a DuckDB CLI:

C:\Users\<you>\AppData\Local\PerformanceMonitorLite-Data\monitor.duckdb

and run:

CREATE TABLE IF NOT EXISTS query_store_slice_repair (
    completed_at TIMESTAMP NOT NULL,
    rows_removed BIGINT NOT NULL
);
INSERT INTO query_store_slice_repair (completed_at, rows_removed) VALUES (now(), 0);

Then start the app normally. I verified this against the exact check the app makes, so it will skip the repair and start.

Two cautions. Use a DuckDB 1.5.x CLI — that is the version the file was written with, and a much newer one may upgrade the storage format underneath the app. And take a copy of monitor.duckdb first, purely so there is an undo.

What you give up by doing this is only the one-time collapse of those pre-#1907 rows. The app collects normally afterwards, and the read side already resolves those split rows deterministically, so nothing is broken — those particular historical Query Store intervals just keep reading the way they do today. If you would rather not touch the file at all, waiting for the next nightly is fine too; the fix below means it will simply start.

What shipped

PR #2770 makes the repair record its attempt before it runs, and stop attempting on startup after two that did not complete. A native abort cannot be caught, so the only protection that survives one is a record that is already durable when it happens.

After that, a store in your situation starts normally on the second or third launch by itself, with a clear log line saying the repair was skipped and why. Dropping the query_store_slice_repair_attempts table re-arms it if a later build can complete it.

I want to be straight about the limit of this: it stops the crash from costing you the application, but it does not yet make the repair itself fit in memory on a store your size. That is a separate fix and I have kept the reproduction harness so it can be measured properly rather than guessed at. Your install will be usable either way.

Sorry this cost you a couple of days.

[H-Engmark]

Thank you so much for investigate this issue!
The workaround with creating a table and running an INSERT statement in a DuckDB CLI did the trick.
Now, the app starts and is running ;-)

This is the log lines created (except all the new Collector lines):

2026-09-02 15.01.11.909 [INFO ] [AppLogger] Logging initialized
2026-09-02 15.01.11.912 [INFO ] [App] Starting PerformanceMonitorLite v3.6.0.0
2026-09-02 15.01.11.912 [INFO ] [App] Data directory: C:\Users\adm-hce\AppData\Local\PerformanceMonitorLite-Data
2026-09-02 15.01.12.741 [INFO ] [ServerManager] Loaded 2 servers from configuration
2026-09-02 15.01.12.760 [INFO ] [ProfileManager] Loaded 0 credential profiles
2026-09-02 15.01.13.288 [INFO ] [DuckDbInitializer] Initializing DuckDB database at C:\Users\adm-hce\AppData\Local\PerformanceMonitorLite-Data\monitor.duckdb
2026-09-02 15.01.14.028 [INFO ] [DuckDbInitializer] Schema initialization created 103 tables
2026-09-02 15.01.14.028 [INFO ] [DuckDbInitializer] Database initialization complete. Schema version: 56
2026-09-02 15.01.14.101 [INFO ] [DuckDbInitializer] Archive-view refresh sees 103 tables
2026-09-02 15.01.16.195 [INFO ] [CollectionBackgroundService] Collection background service started
2026-09-02 15.01.16.289 [INFO ] [RemoteCollectorService] Delta calculator seeded from database (baselines from the last 15 minutes)
2026-09-02 15.01.21.345 [INFO ] [Scheduler] Checking per-server schedules for 2/2 servers (0 offline, skipped)

[erikdarlingdata]

Resolved by #2770, merged to dev. Closing manually: Fixes #N only fires on the dev->main release merge, so completed work otherwise sits open until release.