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.

Hello rz-dienste,

We are setting up the revised laboratory environment today to match your topology as closely as possible, including the Windows Server, MSI installation, Windows Service, remote PostgreSQL connectivity, SSL behavior, and comparative PSU versions.

We expect to complete the primary comparison tomorrow and should then be able to provide either a conclusion based on the reproduced behavior or a precise update describing any remaining environmental differences or tests still required.

Thank you for your patience while we complete this validation.

Best regards,
Ruben Tapia

Hello rz-dienste,

I apologize for the delay in completing the comparative laboratory.

The investigation remains active, and we have completed the main preparation required to test the issue under conditions that more closely match your environment. However, an unexpected operational interruption temporarily prevented us from completing the Windows Server and PostgreSQL comparison as planned.

The previous limited testing did not reproduce the reported exception, but it did not include the full MSI, Windows Service, remote PostgreSQL 17.7, and SSL topology. Therefore, the current result remains inconclusive and does not confirm or rule out the reported behavior.

We will resume the remaining laboratory work as soon as the required environment is available and will provide an update after the comparative tests have been completed.

Thank you for your patience and understanding.

Best regards,
Ruben Tapia

Hello rz-dienste,

Thank you for your patience while we continued expanding the laboratory environment.

During the Windows Server and MSI phase, we identified a separate, reproducible startup and installation behavior that currently prevents PowerShell Universal from reaching the PostgreSQL initialization stage in our matching test environment.

Because of this, the original PostgreSQL `ObjectDisposedException` is still neither confirmed nor ruled out. However, the new laboratory findings are significant enough to warrant Development review, and we are moving forward with that process while continuing the remaining validation.

I will keep this thread updated as soon as we have a meaningful result from the next validation or Development review.

Thank you again for your patience and for the detailed information you have provided throughout the investigation.

Best regards,

Ruben Tapia

Hello rz-dienste,

Thank you again for your patience while we worked through the additional validation.

Based on the evidence collected so far, the case has now been escalated to our Development team for further review.

During our internal testing, we identified reproducible installation and startup behavior that requires product-level analysis. The original PostgreSQL `ObjectDisposedException` remains part of the investigation, but it has not yet been independently confirmed or ruled out in our matching environment because the additional startup behavior prevented PSU from reaching the PostgreSQL initialization stage.

Development now has the relevant findings and evidence from the investigation. I will keep this thread updated as soon as we receive additional guidance or conclusions from their review.

Thank you for the detailed information and logs you have provided throughout the case. They have been very helpful in narrowing down the behavior.

Best regards,
Ruben Tapia

Hi Ruben

Thank you for your posts and for your time.

Best regards

Hello rz-dienste,

I wanted to provide you with a brief update on your case.

Your case is now being reviewed directly by our Development team. Based on the exception details and logs you provided, they have identified a possible correlation with an Npgsql dependency issue involving the same `ManualResetEventSlim` and `NpgsqlConnector.ResetCancellation` behavior seen in your environment.

Development is currently verifying whether this correlation applies to PowerShell Universal and whether a dependency update may be required.

At this stage, this is still under technical review, so I do not want to present the Npgsql dependency as a confirmed root cause or fix yet. However, the investigation now has a specific product-level direction, and the evidence you provided has been useful in narrowing down the issue.

I will keep this thread updated as soon as Development confirms the findings and provides the appropriate next action.

Thank you again for your patience while we work through this.

Best regards,
Ruben Tapia