[BUG] memory_grant_stats_collector error at installation proces

[AleksanderKruecken]

Component

Full Dashboard

Performance Monitor Version

2.4.1

SQL Server Version

MSSQL server 2022 develope

Windows Version

Windows server 2022 standard

Describe the Bug

I tried to install Performance monitor full edition and got this error:
[WARN] Validation complete: 45 collectors succeeded, 2 failed
[ERROR] memory_grant_stats_collector: Error in memory grant stats collector: The current transaction cannot be committed and cannot support operations that write to the log file. Roll back the transaction.
[ERROR] memory_grant_stats_collector: The current transaction cannot be committed and cannot support operations that write to the log file. Roll back the transaction.
Installation report saved to: C:\Users\sa.ak\PerformanceMonitor_Install_T-ADI-DBMIG_TADIDBMIG_20260329_191130.txt

Steps to Reproduce

Reproducebly only in my above environment.

Expected Behavior

Expected behaviour installs Performance monitor without the memory_grant_stats_collector.

Actual Behavior

I got the following error:
[ERROR] memory_grant_stats_collector: Error in memory grant stats collector: The current transaction cannot be committed and cannot support operations that write to the log file. Roll back the transaction.
[ERROR] memory_grant_stats_collector: The current transaction cannot be committed and cannot support operations that write to the log file. Roll back the transaction.

Error Messages / Log Output

Screenshots

PerformanceMonitor_Install_T-ADI-DBMIG_TADIDBMIG_20260329_191130.txt

Additional Context

Installer log in the attachment

[erikdarlingdata]

Thanks for the report and the install log — that was very helpful.

We found a bug in our error handling. When calculate_deltas or ensure_collection_table hit an error inside a caller's transaction, the CATCH block was trying to write to the error log before rolling back the doomed transaction. That write fails with the "cannot be committed" error you saw, and it also swallows the real underlying error message.

We've fixed the error handling so the original error propagates correctly. That said, we'd love to know what the actual underlying failure is on your server. Could you run this after installing and let us know what comes back?

USE PerformanceMonitor;
GO

-- Check for recent errors from memory_grant_stats
SELECT TOP 10
    collection_time,
    collector_name,
    collection_status,
    error_message
FROM config.collection_log
WHERE collector_name LIKE N'%memory_grant%'
ORDER BY collection_time DESC;
GO

-- Run the collector manually with debug on
EXECUTE collect.memory_grant_stats_collector @debug = 1;
GO

Also — the validation reported "2 failed" but the log only shows memory_grant_stats_collector. The error count query uses SUM not COUNT DISTINCT, so the same collector erroring twice (once in the CATCH chain) counted as 2 failures. It's not a second collector.

Fix will be in the next release.

[AleksanderKruecken]

T-SQL returns the following:

[AleksanderKruecken]

---

EXECUTE collect.memory_grant_stats_collector @debug = 1;
GO

returns:
WITH
current_collection AS
(
SELECT
mgs.*,
row_number =
ROW_NUMBER() OVER
(
PARTITION BY
mgs.resource_semaphore_id,
mgs.pool_id
ORDER BY
mgs.collection_time DESC
)
FROM collect.memory_grant_stats AS mgs
WHERE mgs.timeout_error_count_delta IS NULL
),
previous_collection AS
(
SELECT
mgs.collection_id,
mgs.resource_semaphore_id,
mgs.pool_id,
mgs.timeout_error_count,
mgs.forced_grant_count,
mgs.collection_time,
row_number =
ROW_NUMBER() OVER
(
PARTITION BY
mgs.resource_semaphore_id,
mgs.pool_id
ORDER BY
mgs.collection_time DESC
)
FROM collect.memory_grant_stats AS mgs
WHERE mgs.timeout_error_count_delta IS NOT NULL
OR mgs.collection_id IN
(
SELECT
MIN(mgs2.collection_id)
FROM collect.memory_grant_stats AS mgs2
GROUP BY
mgs2.resource_semaphore_id,
mgs2.pool_id
)
)
UPDATE
cc
SET
timeout_error_count_delta =
CASE
WHEN cc.server_start_time >= pc.collection_time
THEN cc.timeout_error_count /Server restart/
WHEN cc.timeout_error_count >= pc.timeout_error_count
THEN cc.timeout_error_count - pc.timeout_error_count
ELSE cc.timeout_error_count /Counter wrapped or restart/
END,
forced_grant_count_delta =
CASE
WHEN cc.server_start_time >= pc.collection_time
THEN cc.forced_grant_count /Server restart/
WHEN cc.forced_grant_count >= pc.forced_grant_count
THEN cc.forced_grant_count - pc.forced_grant_count
ELSE cc.forced_grant_count /Counter wrapped or restart/
END,
sample_interval_seconds =
DATEDIFF(SECOND, pc.collection_time, cc.collection_time)
FROM current_collection AS cc
LEFT JOIN previous_collection AS pc
ON cc.resource_semaphore_id = pc.resource_semaphore_id
AND cc.pool_id = pc.pool_id
AND pc.row_number = 1
WHERE cc.row_number = 1
AND pc.collection_id IS NOT NULL /Exclude first collection where no previous exists/
OPTION(RECOMPILE, HASH JOIN, HASH GROUP);
Updated 2 rows with delta calculations for memory_grant_stats

Completion time: 2026-03-30T00:38:22.6342076+02:00

[AleksanderKruecken]

Run the installer again with 'Perform clean install' and now the instalation succedded without errors.
Executing 98_validate_installation.sql...
[OK] 98_validate_installation.sql - Success
Running validation (this may take a moment)...
Running initial collection to validate installation...
Executing master collector...
[OK] Master collector completed
[OK] Validation complete: 45 collectors succeeded, 0 failed

Installation report saved to: C:\Users\sa.ak\PerformanceMonitor_Install_T-ADI-DBMIG_TADIDBMIG_20260330_004311.txt

================================================================================
Installation Summary

[OK] Installation completed successfully!

[erikdarlingdata]

Great news — thanks for testing the clean install and confirming everything passes (45/45).

The underlying failure was likely leftover state from a previous install attempt. The real problem was that our error handling in calculate_deltas and ensure_collection_table swallowed the actual error and replaced it with the generic "cannot be committed" message, making it impossible to diagnose.

The fix is committed and will be in the next release. Closing this one out — appreciate the detailed logs!