Repository navigation
[QUESTION] Meaning of Error-message in log after start up in installation updated to 3.7.1 #3501
Description
Which component is your question about?
Lite
Performance Monitor Version
3.7.1
Is your question about how it works, or the results?
Setup / installation
What's your question?
I just updated to 3.7.1 and noticed some messages on SOME of the monitored servers in the logfile:
2026-09-17 13:56:03.186 [INFO ] [DarlingWorker] [SERVER-NAME] Cannot set blocked process threshold via sp_configure (may require platform config): User does not have permission to perform this action.
You do not have permission to run the RECONFIGURE statement.
User does not have permission to perform this action.
You do not have permission to run the RECONFIGURE statement.
Wondering what can be the reason for this. I do not see any collectors failing after the upgrade.
Additional Context
Seen for both sql server 2019 and 2025 on the monitored server. On prem servers.
Activity
erikdarlingdata commentedon Sep 17, 2026
Claude posting for Erik Darling
Short version: this is benign — nothing is broken and you can safely ignore those lines. Here is exactly what they mean.
When Lite/Darling sets up its blocked-process-report Extended Events session, it runs a one-time bootstrap: if the server's
blocked process threshold (s)is still0, it tries to set it to5viasp_configure+RECONFIGURE(that is what makes the blocked-process-report event fire).RECONFIGUREneeds theALTER SETTINGSserver permission. Your monitoring login does not have it on those servers, so the statement is denied — and we catch that, log it at INFO, and carry on. No collector fails.Why only some servers: only servers whose threshold is still
0attempt the bootstrap. Servers where it is already set never try, so they never log it. The doubled error text is just the batch containing twoRECONFIGUREstatements.What you lose — and what you don't: blocking is still captured either way by the always-on DMV blocking snapshot, so the Blocking grid and the block-chain viewer stay populated. The only thing that stays off until the threshold is set is the richer blocked-process-report XE (the detailed blocked/blocking capture).
To make it stop, do either one on the affected servers:
ALTER SETTINGS(the bootstrap then succeeds on its own), orblocked process threshold (s)to5yourself. On AWS RDS use a parameter group; on Azure SQL Database it is fixed at 20 seconds and cannot be changed.You were right that the message was confusing — it framed this as an RDS/Azure platform issue and never said it was harmless. We have reworded it at the source, in both Lite and Darling, to name the permission cause and state plainly that it is benign; that will be in an upcoming build. Thanks for the clear report.
Clarify the blocked-process-threshold bootstrap log so it reads as be…