Crash on lockscreen when using Pageant

[Mat2095]

Overview

KeePassXC crashes on Windows after waking up from sleep, on the lockscreen, when using Pageant

Steps to Reproduce

1. Run KeePassXC and unlock database, have Pageant configured
2. Send PC to sleep
3. Wake PC up

Expected Behavior

Nothing, KeePassXC should continue running

Actual Behavior

KeePassXC crashes often in this situation. If it crashes, it might show a message like this, or it might crash silently:

Context

It doesn't crash if the database is locked before sleeping.
I'm using SSH-Agent with both OpenSSH and Pageant (I have some keys that I add to them upon unlocking the database). I found that disabling Pageant (and using either OpenSSH only or none) always prevents the crash. When having Pageant enabled (either with OpenSSH or alone), it "often" (maybe 50-90 percent) crashes.
I'm using Pageant Release 0.81.
As mentioned before, the crash is not completely reliable, so I can't be completely certain that Pageant/Pageant-Integration causes the issue.

Debug-info

KeePassXC - Version 2.7.8
Revision: f6757d3

Qt 5.15.11
Diagnosemodus ist deaktiviert.

Betriebssystem: Windows 11 Version 2009
CPU-Architektur: x86_64
Kernel: winnt 10.0.22631

Aktivierte Erweiterungen:

• Auto-Type
• Browser-Integration
• Passkeys
• SSH-Agent
• KeeShare
• YubiKey
• Schnelle Entsperrung

Kryptographische Bibliotheken:

• Botan 3.1.1

Operating System: Windows

[droidmonkey]

Unfortunately I cannot replicate this at all. Can you provide any additional details or steps?

I did the following:

1. Have Pageant running and OpenSSH running
2. Set an SSH Agent entry to load a key on unlock and remove it on lock
3. Locked database
4. Unlock database, confirm key in pageant and openssh agent
5. Put computer to sleep (and also tried hibernate)
6. Wake
7. Database is locked and key is not in pageant nor openssh agent, no crash

I did this 20 times

[Mat2095]

Thanks for looking into this.
So it seems there is something else required for the crash to occur, that I am unaware of. I'll try to find it, maybe I can reproduce it on another machine.

[Mat2095]

Just a quick update, I haven't managed to find what causes the issues yet. On my second machine I couldn't make it crash.
But I found out two things:

• in cases where KeePassXC does NOT crash, the keys are still present in Pageant, so they were not removed
• both locking and hibernating does not cause any issues; not crashes and keys always get removed there
  I'll continue looking for the cause.

[DirkHeinke]

I also had a few keepassxc crashes after waking up from sleep but I don't use pageant. Is there any logging I can turn on to provide more infos for finding this issue?

[ClenonWolf]

I've also observed the same issue without having pageant configured. Though, I'm accessing the database file from a network drive that is disconnected right after waking from sleep. When the file is located on a local drive that's accessible directly after waking, KeePassXC doesn't crash. My guess is that the crash is caused by KeePassXC trying to access a file that isn't accessible/doesn't exist (yet). The same error prompt (but in English) appears already on the Lock screen.

Although this issue doesn't seem to be caused by Pageant (at least in my case). So I'm not sure if I would need to open a new issue for this.

[droidmonkey]

My guess is that the crash is caused by KeePassXC trying to access a file that isn't accessible/doesn't exist (yet).

That would not cause a crash, we check if the file is valid and won't even load the tab if it is not. You can easily replicate that by opening a local database file, quit keepassxc, rename the local file, start keepassxc.

[ClenonWolf]

That appears to be correct. If I rename a local file, after waking the Database is locked and unlocking gives a "file does not exist" error.

[xtedx]

cannot always reproduce but i also have this problem sometimes with a message box appearing on wake, before logging into windows.
database was at unlocked state when sleeping.
if not crashing then the database will be locked after waking and logging in.

my database file is stored in the OneDrive folder, maybe that plays a part.
my settings that may be relevant to this:
auto save after every change
not lock database after inactivity

after further experiments i found the steps to reproduce a crash but the crash happened after logged in
this makes sense because sometimes i edited an entry and forgot to close, working on other windows
locking the screen without sleep does not crash.

steps to reproduce crash with 2.7.4

1. open a database,
2. create a new entry or edit an existing entry
3. leave the password entry is open, don't save
4. change focus to another application window, or not.
5. sleep the pc
6. wake the pc and login if required
7. the dialog asking to save or discard appears
8. press discard
9. crashes

i then updated to 2.7.9 and cannot reproduce using the above steps, and have not yet crashed at the login screen too.

windows 11 , but the about dialog shows 10
KeePassXC - Version 2.7.4
Revision: 63b2394

Qt 5.15.6
Debugging mode is disabled.

Operating system: Windows 10 Version 2009
CPU architecture: x86_64
Kernel: winnt 10.0.22631

Enabled extensions:

• Auto-Type
• Browser Integration
• SSH Agent
• KeeShare
• YubiKey
• Quick Unlock

Cryptographic libraries:

• Botan 2.19.1

[droidmonkey]

i then updated to 2.7.9 and cannot reproduce using the above steps, and have not yet crashed at the login screen too.

We did fix this crash you described between 2.7.4 and 2.7.9

#10458

I am closing this issue since there is no way to reproduce the original report with the latest version.

[Mat2095]

Seems fair. I am still experiencing the issue (on 2.7.9), but I couldn't find a way to consistently reproduce it.
Also my previous statement, that KeePassXC either crashes or the keys were not removed from Pageant, turned out incorrect. Multiple times everything worked fine (no crash and the keys were removed correctly).
If I find a way to reproduce it consistently (e.g. some third-party program or some random setting), I'll open a new issue, but closing this issue here is probably a good idea.