Access violation writing 0x0000000000000000 when connecting

[Algorytm]

Access violation writing 0x0000000000000000 when connecting to PostgreSQL server in pgAdmin 9.18 on Windows 10

Steps to reproduce the behavior:

1. Start pgAdmin 4 9.18 in Desktop mode on Windows 10.

2. Select an existing registered PostgreSQL server.

3. Attempt to connect to the server.

4. Enter the password in the "Connect to Server" dialog and click "OK".

5. The connection fails and the following error is displayed:

   exception: access violation writing 0x0000000000000000

The issue started after upgrading to pgAdmin 4 version 9.18.

The connection worked correctly on pgAdmin 4 9.17

Error message

Full error message displayed by pgAdmin:

exception: access violation writing 0x0000000000000000

The same message is also visible in the Query Tool "Messages" tab.

Desktop (please complete the following information):

• OS: Windows 10 22H2, build 19045
• pgAdmin version: 9.18
• Mode: Desktop
• Package type: Windows x64 installer
• Python Version: 3.13.14
• Electron Version: 44.3.0
• Chromium/Chrome Version: 152.0.7977.78
• Commit: f09776c

Additional context

The issue appeared after installing/upgrading to pgAdmin 4 9.18.

The error occurs when pgAdmin attempts to establish a PostgreSQL connection. Instead of receiving a normal PostgreSQL connection/authentication error, pgAdmin reports a native access violation:

exception: access violation writing 0x0000000000000000

"Save Password" is not enabled.

The registered PostgreSQL server configuration already existed before the upgrade.

[3rnie87]

Hey,
issue seems identfied and solved
#10440

[dev-hari-prasad]

This issue will be resolved in the next version. PR fixing this is already in place, as pointed out by @3rnie87 (thanks).

There is a temporary workaround for this:

• In the Object Explorer, right-click your server and select Properties (or configure it when registering a new server).
• Go to the Parameters tab.
• Click the + button to add a new parameter:
• Name: GSS encmode (or gssencmode)
• Value: disable
• Click Save and reconnect.

Or by downgrading to 9.17.

Thanks for reporting. Do close it once it's fixed for you.

[novaecho256]

I got the same issue, so now I am going to downgrade to 9.17 for now.

[darthnic02]

Same here on 9.18, working on 9.17 and 9.16.

Regression when using " Password execution command " in advanced tab.

Possible to reproduce by using a script as simple than : cmd.exe /c echo test

Received error message : exception: access violation writing 0x0000000000000000

@dev-hari-prasad work's arround works :)

Thanks you

[lsebe]

Hi,
Had the same as everyone else after upgrading to 9.18. Fixed using @dev-hari-prasad's workaround, however: PSQL Tool did not work; the command lines just exited in cmd prompt, without any visible error.
I thought it is important to notify you/future others that psql.exe is also affected, not only the pg_dump.exe.
Thank you!

[dev-hari-prasad]

Hi, Had the same as everyone else after upgrading to 9.18. Fixed using @dev-hari-prasad's workaround, however: PSQL Tool did not work; the command lines just exited in cmd prompt, without any visible error. I thought it is important to notify you/future others that psql.exe is also affected, not only the pg_dump.exe. Thank you!

Pls share logs that would be really helpful.

[dpage]

@lsebe Thanks for flagging that, though it turns out to be the same root cause rather than a second problem, which is why the gssencmode workaround does nothing for it.

PostgreSQL 18 and later are built with GSSAPI support, so the libpq.dll we ship in the runtime directory now has a load-time dependency on gssapi64.dll where it previously had none. In 9.18 we staged the Kerberos runtime into the python directory only, and psql.exe lives in runtime next to libpq.dll, so it fails in the Windows loader before it ever parses a connection parameter. The loader error goes to a console that we don't capture, hence a window that simply closes with nothing in it.

If you want to unstick it before the next release, copy gssapi64.dll, krb5_64.dll, comerr64.dll and k5sprt64.dll from the python directory of your pgAdmin installation into the runtime directory alongside psql.exe. Keep the gssencmode: disable parameter in place whilst you do, because 9.18 never shipped krbcc64.dll at all and libpq will otherwise ask for a credential cache that it cannot provide. Inelegant, but it will get you a working PSQL tool, and the same applies to backup and restore.

The proper fix is #10440, which stages the whole Kerberos runtime into runtime so that the client binaries and libpq both find it, and adds the two files we were missing. That will be in 9.19.

[dev-hari-prasad]

@lsebe Thanks for flagging that, though it turns out to be the same root cause rather than a second problem.

In that case this is a duplicate we can consider closing this issue @dpage.