PostgreSQL: ObjectDisposedException (ManualResetEventSlim) prevents 2026.2.2.0 from starting

Hello,

Thank you for your feedback.

I moved your thread to the PowerShell Universal Bug Report section.

Best regards,
Maxime

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.

@rz-dienste

Dear rz-dienste,

Thank you for providing the detailed reproduction steps and comparison with PowerShell Universal 5.6.12.

We will reproduce this behavior in our internal lab using PowerShell Universal 2026.2.2.0 with a fresh PostgreSQL database. We will also validate the `psu db schema` command and compare the results with an earlier PSU version to determine whether this is a regression affecting PostgreSQL connectivity or schema initialization.

To help us match your environment as closely as possible, could you please share the following information?

• Operating system and installation method
• PostgreSQL server version
• Sanitized connection string
• Complete PSU startup log
• Complete stack trace from the `psu db schema` command
• Confirmation whether you tested PowerShell Universal 2026.2.1

Once we complete the lab validation, we will provide an update with our findings and determine whether the issue needs to be escalated to the development team.

Best regards,
Ruben Tapia

Hello rz-dienste,

Thank you again for the detailed report.

We completed the first viable phase of our internal testing using PowerShell Universal 2026.2.2.0 with PostgreSQL 16.14. Under this configuration, we were not able to reproduce the reported exception.

Our results were:

* 3 of 3 schema migrations completed successfully with the default pooling configuration.
* 3 of 3 schema migrations completed successfully with `Pooling=false`.
* 30 of 30 repeated database operations completed successfully.
* We did not observe `ObjectDisposedException`, `ManualResetEventSlim`, or `NpgsqlConnector.ResetCancellation`.

This does not invalidate your findings. Our current environment does not yet fully match yours, particularly regarding the Windows Service installation path, PostgreSQL configuration, networking, authentication options, and upgrade history.

Could you please confirm the following?

* Exact PostgreSQL version and operating system
* PSU installation method
* Clean installation or upgrade, including the previous PSU version
* Whether PSU and PostgreSQL are on the same server
* Whether SSL, GSS, SSPI, Kerberos, PgBouncer, or another proxy or pooler is involved
* Whether the affected environment is production
* Whether PSU 2026.2.1.0 shows the same behavior
* The complete exception stack and the log entries immediately preceding it

Because this is a public forum, please sanitize all evidence before posting. Remove credentials, tokens, license keys, cookies, private keys, full connection strings, email addresses, usernames, customer data, tenant or account identifiers, internal domains, hostnames, IP addresses, and private URLs. Please do not upload unredacted HAR files, memory dumps, database backups, or complete configuration files to this public thread.

We will continue testing with an isolated Windows VM, the MSI installation, Windows Service startup, and comparative PSU versions.

Best regards,
Ruben Tapia

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

Hello rz-dienste,

Thank you for the additional environment details and for attaching the log.

The attached file includes the exception stack we were requesting. It shows that the first failure occurs during PowerShell Universal startup while attempting to acquire a PostgreSQL advisory lock. Additional PostgreSQL queries then fail through the same NpgsqlConnector.ResetCancellation path, and the unhandled exception causes the Windows Service host to stop.

This confirms that the behavior is not limited to schema creation. It also affects PostgreSQL access during the PSU startup process.

Your environment differs from our initial lab in several important ways:

• PostgreSQL 17.7 on Windows Server
• PostgreSQL hosted on a separate server
• SSL-enabled connection
• PSU installed through MSI and running as a Windows Service
• PSU 2026.2.0.0 and 2026.2.2.0 both affected

We will continue testing with a closer match to this topology, including PostgreSQL 17.7, SSL, MSI installation, Windows Service startup, and remote database connectivity.

Before changing the connection string, please do not add ssl=true yet. We would first like to review the existing SSL-related parameters. Could you please provide:

• The Windows Server versions used by the PSU and PostgreSQL servers
• A sanitized connection string that preserves only the parameter names and non-sensitive SSL values
• Whether PostgreSQL requires SSL or only supports it
• Whether the certificate is self-signed, internally issued, or publicly trusted
• PostgreSQL server log entries matching the PSU failure timestamp
• Confirmation whether PSU 5.6.12 was tested using this same remote SSL topology

Best regards,

Ruben Tapia

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,
Thank you for the additional details. We’ll adjust the lab to match this topology as closely as possible: Windows Server 2022 build 20348.5256, remote PostgreSQL with sslmode=prefer and connect_timeout=10, and the same connection behavior.

We’ll compare PSU 5.6.12 with 2026.2.2.0 and test both RunMigrations absent and explicitly enabled, while correlating PSU and PostgreSQL logs.

We’ll share the results once the comparison is complete.