[BUG]

[jovon44]

Component

Darling

Performance Monitor Version

3.2.0

SQL Server Version

SQL Server 2022 CU 25

Windows Version

Windows 2019

Describe the Bug

Good morning,
I am trying to get your Performance monitor tool and keep getting the following error after install.
darling.json could not be read: darling.json uses the managed Postgres (postgres.managed = true), but the credential file for the 'admin' role (C:\ProgramData\Performance MonitorDarling\pg-admin- credential.dpapi) does not exist yet. Start the Performance Monitor Darling service once - its first run initializes the bundled Postgres and provisions the least-privilege roles and their credentials.
here is what's in the log file:
8-11 10:07:22.798 [INFO ] [Lifetime] Application started. Hosting environment: Production; Content root path: C:\Users\username\Desktop\PerformanceMonitorDarling-3.2.0
2026-08-11 10:07:22.879 [INFO ] [DarlingWorker] Loaded configuration from C:\Users\Username\Desktop\PerformanceMonitorDarling-3.2.0\darling.json: 2 server(s)
2026-08-11 10:07:22.894 [INFO ] [DarlingWorker] Initializing managed Postgres cluster in C:\ProgramData\PerformanceMonitorDarling\pg (first run)
2026-08-11 10:07:23.096 [CRIT ] [DarlingWorker] Managed Postgres bootstrap failed: initdb failed (exit code -1073741515) for C:\ProgramData\PerformanceMonitorDarling\pg. Output:

Steps to Reproduce

installed app from powershell .\install-darling.ps1

Expected Behavior

service and app to install properly

Actual Behavior

darling.json could not be read: darling.json uses the managed Postgres (postgres.managed = true), but the credential file for the 'admin' role (C:\ProgramData\Performance MonitorDarling\pg-admin- credential.dpapi) does not exist yet. Start the Performance Monitor Darling service once - its first run initializes the bundled Postgres and provisions the least-privilege roles and their credentials.

Error Messages / Log Output

8-11 10:07:22.798 [INFO ] [Lifetime] Application started. Hosting environment: Production; Content root path: C:\Users\username\Desktop\PerformanceMonitorDarling-3.2.0\
2026-08-11 10:07:22.879 [INFO ] [DarlingWorker] Loaded configuration from C:\Users\Username\Desktop\PerformanceMonitorDarling-3.2.0\darling.json: 2 server(s)
2026-08-11 10:07:22.894 [INFO ] [DarlingWorker] Initializing managed Postgres cluster in C:\ProgramData\PerformanceMonitorDarling\pg (first run)
2026-08-11 10:07:23.096 [CRIT ] [DarlingWorker] Managed Postgres bootstrap failed: initdb failed (exit code -1073741515) for C:\ProgramData\PerformanceMonitorDarling\pg. Output:

Screenshots

Additional Context

first time installing to monitor on prem SQL Servers

[erikdarlingdata]

Thanks for the log — that one line is enough to identify it, and the message you led with is a symptom rather than the fault.

Read it bottom-up. The causal order is:

1. initdb failed (exit code -1073741515) — this is the actual failure.
2. initdb failing means the bundled Postgres cluster was never created.
3. No cluster means the least-privilege roles were never provisioned.
4. No roles means pg-admin-credential.dpapi was never written.
5. Which produces the "credential file ... does not exist yet" message you saw.

So nothing is wrong with your darling.json, and starting the service again won't help until step 1 is fixed.

What that exit code is. -1073741515 is 0xC0000135, which is STATUS_DLL_NOT_FOUND — Windows killed initdb.exe in the loader because a DLL it needs couldn't be loaded. That also explains why Output: is empty: the process died before it could write a single line, so there's no Postgres error to read. It is not a Postgres problem at all.

Why it's probably not a missing Visual C++ redistributable. That's the usual cause, and the product already handles it: since 3.2.0 the packaging step bundles vcruntime140.dll, vcruntime140_1.dll and msvcp140.dll beside postgres.exe inside pg-runtime.zip precisely so you don't need the redistributable installed. So on your build the normal cause should already be covered — which points somewhere else.

The top suspect is where you installed it. Your log shows the content root as:

C:\Users\username\Desktop\PerformanceMonitorDarling-3.2.0\

The installer deliberately creates the service under the NT SERVICE\PerformanceMonitorDarling virtual account rather than LocalSystem, because the bundled PostgreSQL refuses to run with administrative privileges. That account is not you, not SYSTEM, and not Administrators — and a folder under C:\Users\<you>\Desktop grants read access to exactly those three. The installer's ACL hardening only applies to darling.json and its backups, not to the install tree, so pg-runtime keeps whatever the Desktop location gave it. A service account that cannot read initdb.exe's dependencies gets STATUS_DLL_NOT_FOUND from the loader, which is what you're seeing.

Try this: reinstall to a machine-scoped path rather than a user profile — C:\PerformanceMonitorDarling is what I run on my own monitoring box:

# from an elevated prompt, after extracting to C:\PerformanceMonitorDarling
.\install-darling.ps1

Two things that would confirm it either way, if you want to check before reinstalling:

1. Does ...\pg-runtime\pgsql\bin\ contain vcruntime140.dll, vcruntime140_1.dll and msvcp140.dll? If those are missing, it IS the runtime and installing the VC++ 2015-2022 x64 redistributable fixes it.
2. From an elevated prompt: & '...\pg-runtime\pgsql\bin\initdb.exe' --version. If that prints a version as you but the service still fails, it's the permissions path above. If it fails for you too, it's the runtime.

Also worth upgrading — you're on 3.2.0 and current is 3.4.0 — but I don't think that's your fix, so do it after you're running.

On my side, two things here are product faults regardless of which of the two it turns out to be:

• The service should decode 0xC0000135 instead of printing a raw Win32 status with an empty Output:. It already does exactly this decoding for a related case elsewhere in the managed-Postgres bootstrap, so this path is just missing it.
• The installer should refuse, or at minimum warn loudly, when the install directory sits under a user profile, because the virtual service account it creates can never read it. Right now it happily builds a service that cannot start.

I'm filing both. Let me know which of the two checks above it is and I'll tailor the fix to what you actually hit.

[erikdarlingdata]

Filed the two product-side faults from my previous comment so they're tracked independently of your diagnosis: #2186 (decode the loader status instead of printing a raw code with an empty Output:) and #2187 (the installer should not build a service that cannot read its own install tree).

Neither blocks you — the reinstall to a machine-scoped path should get you running today. Still interested in which of the two checks it turns out to be, since it decides which of those two I prioritise.

[jovon44]

I have moved it to the c:\PerformanceMonitorDarling drive as requested
all 3 dll's from above are in the folder
postgress db version
initdb (PostgreSQL) 18.4

Same error occurs

[erikdarlingdata]

That's a decisive test and it kills both of my hypotheses. Thank you — that's more useful than a fix would have been at this stage, because I was about to send you down the wrong path twice.

What your result rules out:

• Not the install location / service-account-can't-read-a-profile. You moved it to C:\PerformanceMonitorDarling and it still fails.
• Not a missing Visual C++ redistributable, and not a broken bundle. All three DLLs are present, and — the important part — initdb --version ran and printed initdb (PostgreSQL) 18.4. A process that dies in the loader can't print its own version, so initdb.exe and its direct dependencies load fine in your shell.

I also checked the packaging on my side rather than assuming: the build copies EDB's entire bin, lib and share directories, so it isn't pruning a required DLL either.

So the failure is specific to how the service invokes it, not to the files being absent. Two candidates, and one diagnostic that would settle it outright.

The diagnostic that names the DLL

Windows usually records the missing module even when the process produces no output. Right after reproducing the failure, check:

Event Viewer → Windows Logs → Application, at the failure timestamp, for an Application Error or SideBySide event. Those events typically name the faulting module directly. If you see one, paste it here — that single line likely ends this.

The two candidates

1. postgres.exe, not initdb.exe. initdb --version only prints and exits, but a real initdb run spawns postgres.exe in bootstrap mode to build the template database. So a dependency missing for postgres.exe would let --version succeed and the real run die. Worth running:

   & 'C:\PerformanceMonitorDarling\pg-runtime\pgsql\bin\postgres.exe' --version

   If that one fails where initdb --version succeeded, we've found it.

2. The service account's load context. The service runs as the NT SERVICE\PerformanceMonitor Darling virtual account, not as you, and the installer does not ACL the install tree (it only hardens darling.json). A dependency that resolves for you via your PATH may not resolve for the service. You can test that cheaply and reversibly:

   icacls 'C:\PerformanceMonitorDarling' /grant '*S-1-5-80-0:(OI)(CI)(RX)' /T

   (S-1-5-80-0 is NT SERVICE\ALL SERVICES — broader than needed, but it's a five-second test of the theory. If that fixes it, the real fix is mine to ship in the installer, not yours to keep.)

One more thing that would help me narrow it: which Windows Server 2019 build/patch level (winver, or [Environment]::OSVersion plus the latest cumulative update)? vcruntime140_1.dll depends on a reasonably current Universal CRT, and an unpatched 2019 image with an incomplete api-ms-win-crt-* set is now on my suspect list — that would also produce 0xC0000135 with no output.

On my side

This has taken three exchanges to not-diagnose, which is itself the bug: the service tells you a signed Win32 integer and an empty Output: field. #2186 is open to decode the loader status and say what it means, and I'm raising its priority — your case is the argument for it. #2187 covers the installer half.

Sorry for the two wrong turns. The Event Viewer entry is the highest-value thing to grab next.