Windows 9.18: GSSAPI-enabled libpq causes "access violation writing 0x0" on connect, and a missing gssapi64.dll for pg_dump

[RobertoAtEpoca]

The Bug:

Upon upgrading to version 9.18 from 9.17, all the database connections stopped working.
When trying to expand the database's entry in the Object Explorer, I get the "Connect To Server" dialog box with an error message:
exception: access violation writing 0x0000000000000000
Entering the password and clicking "OK" closes the box and re-opens it immediately.
Uninstalling 9.18 and re-installing 9.17 gets rid of the issue.

To Reproduce:

Install pgAdmin 9.18 and run it.
Click on any database in the Object Explorer:

Expected behavior:

It should immediately expand the database's node in the Object Explorer or
ask for the password without showing an error, accept the password and expand the node.

Version info:

OS: Windows 11 Pro
pgAdmin Version: 9.18

[sduffy77]

I just installed pgAdmin4 for the first time on my windows 11 machine and attempting to Register a new server and met with the same error code.

[nandfer881-spec]

Tengo el mismo error al actualizar a la versión 9.18

[nandfer881-spec]

exception: access violation writing 0x0000000000000000

[dev-hari-prasad]

Thanks everyone for reporting the issue.

I'm Starting a investigation now. I will update my findings soon. Meanwhile if anyone else is facing the same issue please provide more context when possible.

Update: There is no error when it is a fresh install of pgAdmin. Works perfectly fine and as expected. Checking the upgrade behaviour, I'll update in a while.

[carlostorresoaxaca]

exception: access violation writing 0x0000000000000000

igual tengo ese problema con esa actualizacion...ciertamente cada actualizacion la he instalado y si funciona correctamente... pero esta 9.18 me sale exception: access violation writing 0x0000000000000000. he borrado la configuacion de mi servidor y la he vuelto a hacer y me sale lo mismo...

[robe2]

Update: There is no error when it is a fresh install of pgAdmin. Works perfectly fine and as expected. Checking the upgrade behaviour, I'll update in a while.

I tried uninstalling and even wiping out my profile, it still gives the same access violation writing error after I reinstall 9.18.
One observation it seems to work fine with the windows servers (even my remote ones) I have registered, but not the Linux ones.

[RobertoAtEpoca]

One observation it seems to work fine with the windows servers (even my remote ones) I have registered, but not the Linux ones.

In my case, my server is a Linux instance in AWS, so you might be onto something.

[dev-hari-prasad]

One observation it seems to work fine with the windows servers (even my remote ones) I have registered, but not the Linux ones.

In my case, my server is a Linux instance in AWS, so you might be onto something.

@RobertoAtEpoca

Please don’t get me wrong or take this the wrong way. I’m not venting at you. I just want to point out that I have already spent a pretty significant amount of time and tokens investigating this based on the information in the original report.

Finding out only now that the affected server is a Linux instance in AWS changes the entire diagnosis workflow. The issue title and description make this look like a Windows 11 issue, when the latest comments suggest that the server OS may actually be a major part of what’s going on.

This also confuses the other users since they think to have the same problem here in this thread.

It would really help if as much relevant environment and reproduction information as possible could be included upfront, especially details that can completely change the direction of an investigation.

Given this new information, I'd also suggest updating the issue title and description to mention the Linux/AWS aspect and provide more context and information and possibly non sensitive/retracted logs. That should make the scope of the issue much clearer for anyone else looking into it and for me to diagnose this.

Again do not take this as a vent full message (it is not).

[dev-hari-prasad]

Investigation Update 2:

I tried upgrading from 9.17 to 9.18 myself and didn’t run into any issues, everything worked as expected.

This suggests it’s probably not a straightforward Windows client upgrade issue, but something specific to certain environments (possibly the backend server OS/version or local machine config).

@RobertoAtEpoca @sduffy77 @nandfer881-spec @carlostorresoaxaca @robe2 (and anyone reporting the same issue) could you share a bit more about your setup? Would be helpful if you shared:

• Is pgAdmin running on Windows only, or Linux/Mac too?
• What OS/version is the database server running (Windows, Linux, AWS RDS, etc.)?
• Any non-default config like SSH tunnels, SSL, or specific auth methods?

This should help narrow down what’s actually triggering the access violation so we can solve the issue.

[RobertoAtEpoca]

pgAdmin: 9.18 on Windows 11 Pro.
Server: Aurora PostgreSQL (AWS)

Worked perfectly on 9.17
Stopped working after upgrade to 9.18
Started working again after reverting to 9.17

[robe2]

On further inspection, I think the issue might be with GSS, mode.
I noticed on the Linux ones that weren't working, if I set GSS encode mode = disable, then it works..
I tried this with 3 Linux that weren't working and fixed in all cases.

1. Uses standard connection - Debian 13
2. One uses SSL Tunnel - Debian 13
3. One on CrunchyData Dbaas

* Is pgAdmin running on Windows only, or Linux/Mac too?

I'm on Windows 11, 9.18

* What OS/version is the database server running (Windows, Linux, AWS RDS, etc.)?

I have a mix as mentioned the Windows ones all work and they are running PostgreSQL 15 or 18.
The Linux ones are on VMs or Crunchy and don't work

* Any non-default config like SSH tunnels, SSL, or specific auth methods?

As mentioned adding the GSS encmode = disable fixes the issue

[dev-hari-prasad]

Thanks for updating the title of the issue @RobertoAtEpoca. Would you please update the description to reflect the same issue. This would leave no scope of confusion for anyone visiting the issue.

[dev-hari-prasad]

Yes, I was thinking along the same lines too. Thanks a lot @robe2 for testing and confirming this!

Technical breakdown for later

Why this happens

1. The protocol handshake

   PostgreSQL 12+ libpq defaults to gssencmode=prefer. Before authentication, it sends an 8-byte GSSENC_REQ packet (80877104).

   • Windows PostgreSQL servers, which are typically built without GSSAPI encryption, reply with N (declined). Libpq then falls back to standard SSL/password authentication, which explains why connections to Windows-hosted servers work fine.
   • Linux and cloud-hosted PostgreSQL servers, such as Debian, Ubuntu, CrunchyData, and AWS Aurora/RDS, are often built with GSSAPI support and reply with G (accepted).

2. Where the crash occurs

   When the server replies with G, libpq enters CONNECTION_GSS_STARTUP and calls gss_init_sec_context through the Kerberos DLLs.

   On Windows, MIT Kerberos tries to locate the default credential cache (API: / CCAPI). However, the Windows installer stages the Kerberos DLLs in Make.bat (lines 201–206) without bundling ccapi64.dll.

   This seems to leave the CCAPI dispatch table uninitialized. Eventually, krb5_64.dll makes a call through a null function pointer, resulting in the access violation.

   Since pgAdmin on Windows uses pq_ctypes in this setup, CPython catches the access violation and raises:

   OSError: exception: access violation writing 0x0000000000000000

   The error then bubbles up through servers/__init__.py:1718. Since conn.connect() only catches psycopg.Error, the OSError reaches the broader exception handler, which treats it as an HTTP 401 challenge and displays it in the password modal.

Thanks again @robe2!