rz-dienste

Hi Ruben

Thank you for your posts and for your time.

Best regards

Hi Ruben,

I haven't give you the right information before, sorry for that:

• PSU is running on Windows Server 2022 Standard; Version 21H2; OS build 20348.5256

• PostgreSQL is running on Red Hat Enterprise Linux release 9.8 (Plow)

• the attached logfile from yesterday (systemLog20260722.txt) was with the entry '"RunMigrations": true' in appsettings.json because of troubleshooting reason. Now I attached the logfile without that entry.

My connection string in appsettings.json looks like this: "ConnectionString": "Host=hostname.domain.com; Database=postgres_db; User Id=db_user; Password=*********; Port=5432"

(btw. I used the same connection string for PSU 5.6.12, and it worked.)

When I connect to the postgreSQL DB via pgAdmin 4, it looks like: "...\psql.exe" "host=hostname.domain.com port=5432 dbname=postgres_db user=db_user sslmode=prefer connect_timeout=10"

For your other questions:

• Whether PostgreSQL requires SSL or only supports it

  • PostgreSQL requires SSL

• Whether the certificate is self-signed, internally issued, or publicly trusted

  • on the Windows Server we have an internally issued certificate for PSU

  • but there is also existing an self-signed certificate "PowerShell Universal Development Certificate"; and because in the appsettings.json there is the entry "DevelopmentCertificate": true I think PSU uses for the moment the self-signed certificate.

• PostgreSQL server log entries matching the PSU failure timestamp

  • There are entries with the same timestamp but only info not errors

• Confirmation whether PSU 5.6.12 was tested using this same remote SSL topology

  • From the database site nothing changed and also used the equal connection string as written before when I was installing PSU 5.6.12. That is why I thought that there is a bug with .NET 10 because the older PSU version with .NET 9 didn't had the error

Thank you for your help,

Kind regards,

Lindi

Hi Ruben,

Thank you for your reply, hope this information will help you:

* Exact PostgreSQL version and operating system

--> psql (17.5, server 17.7), runs on Windows Server

* PSU installation method

--> MSI installation

* Clean installation or upgrade, including the previous PSU version

--> Clean installation on a new Windows Server

* Whether PSU and PostgreSQL are on the same server

--> No, PSU and PostgreSQL are on different server

* Whether SSL, GSS, SSPI, Kerberos, PgBouncer, or another proxy or pooler is involved

--> Only via SSL

* Whether the affected environment is production

--> No, we try at first to install it on a DEV environment, if everything is working we install it in PROD environment.

* Whether PSU 2026.2.1.0 shows the same behavior

--> I havent tested it with 2026.2.1.0, but neither 2026.2.0.0 nor 2026.2.2.0 is working. Both versions shows the same behavior

* The complete exception stack and the log entries immediately preceding it

--> What do you mean with exception stack? The logfile is attached.

Now I see in appsettings.json I have the connection string to the DB like the one in the docs: Persistence | Devolutions PowerShell Universal | Devolutions Documentation

Maybe I try it with "ssl=true"

Thank you for your time.

Best reagards

PowerShell Universal 2026.2.2.0 fails to start with a self-hosted PostgreSQL database. The service crashes with:

System.ObjectDisposedException: Cannot access a disposed object.

Object name: 'System.Threading.ManualResetEventSlim'.

at Npgsql.Internal.NpgsqlConnector.ResetCancellation()

This happens on a fresh, empty database, whether starting the Windows service or running `psu db schema` via CLI.

This matches known open issues in the Npgsql project

(npgsql/efcore.pg#3699, npgsql/npgsql#6415), tied to Npgsql.EntityFrameworkCore.PostgreSQL under .NET 10.

As a test, I installed PowerShell Universal 5.6.12 (version before the .NET 10 upgrade) against the same empty database - the schema was created successfully with no errors. After uninstalling 5.6.12 and reinstalling 2026.2.2.0 against that same, now fully-migrated database, the service still crashes with the same exception, just at a different point during startup.

This suggests the issue isn't limited to schema creation - it affects Npgsql more broadly under 2026.2.2.0/.NET 10, and makes PostgreSQL unreliable as a backend for this version.