cppcryptfs sometimes randomly quits in the first ~minute after launch

[eugenesvk]

I've been having an issue where cppcryptfs would intermittently quit/crash within the first minute or so after launch. Sometimes this happens 2-3 times in a row if I launch it again right away, but then on the 4th time it's all fine and then the volume stays mounted for the rest of the day. It's been just a tad bit annoying, but not that big of a deal, so I unfortunately don't remember when it started.

After discovering a WinLogs flooding bug in Dokany I thought it might've been the culprit, but after fixing it I've still encountered the same issue on next reboot.

Don't really know how to troubleshoot it, so let me know how I could help pin it down.

Here is some info that might help:

1. A copy of Diagnostic Data Viewer description for the last 3 crashes (only info I have as I've cleaned it recently), latest is for my custom built, previous two were for your latest version, though I don't remember whether this was before or after I installed a pre-released Dokany

2. crash dump for the latest crash (don't have previous versions)

[bailey27]

Hi. Since you're building cppcryptfs yourself, I think the best way to troubleshoot this is if you could run in in the Visual Studio debugger and see if it happens when running in the debugger.

The project is set up so that both the release and debug builds are built with full debug information (or at least the 64bit ones are).

But I think it would be better to change the configuration from Release to Debug and build and run the debug version because we might get better information that way.

Either way, if you load the project into Visual Studio and press F5 to run in the debugger, then if it crashes the debugger will stop it at the crash site and display an exception message.

Make sure cppcryptfs isn't already running before you do this, otherwise the new instance inside the debugger will just exit.

The "Call Stack" pane in Visual Studio will show where the crash happened and how it got there.

If you could do this and send me a screenshot like the one I'm attaching, I think that would help me figure out what's happening.

Here is the screenshot I made after changing the code to crash on purpose.

[eugenesvk]

Ok, thanks for a prompt response! Unfortunatley I've removed Visual Studio while troubleshooting some SFC file permission issues that google blamed on, but I'll reinstall it some time later and follow your instructions to debug it from within VS By the way, just to try to be as close to my actual use case as possible, is there simple way to run the VS debugger in a way that would allow it to accept command line options for auto-mounting (i.e. to accept the .conf file and password)?

[eugenesvk]

Update: this might've been an issue of messages taking too long to get through (resolved in https://github.com/bailey27/cppcryptfs/releases/tag/1.4.3.4), hopefully no more hangs on logins, but will need to wait for a while to confirm

Question: Could this issue be because cppcryptfs needs the console to persist for some time to mount properly? I've noticed that if I close a console windows too soon after trying to launch cppcryptfs from a command line (but always after the new prompt line is already shown) cppcryptfs just quits

Details on how I got to this question: The challenge with this issue was that I couldn't reproduce the issue when launching via Visual Studio debugging as it's not the launch vector that has a bug (neither does the issue present itself in a regular launch of cppcryptfs.exe with subsequent manual mounting with a typed password)

Current launch mode fails: to allow auto-mounting on startup without any elevation prompts, I launch cppcryptfs via a task scheduler (with "Run with highest priviledges" enabled) that runs this command: Start a program: "path/to/cppcryptfs.exe" Add arguments (optional): --config="path/to/EncryptedFolder.conf" --mount="path/to/EncryptedFolder" --drive=S --saved-password --tray --exit

If this fails on login, I run a link with with this task manually C:\Windows\System32\schtasks.exe /run /TN "CppCryptFS-Test"

Alternative launch mode with some success: Today I had an idea of testing it differently and tried to launch the same command ("path/to/cppcryptfs.exe" --config="path/to/EncryptedFolder.conf" --mount="path/to/EncryptedFolder" --drive=S --saved-password --tray --exit) via an elevated command prompt and noticed that it works just fine and doesn't quit. Trying to find the difference between this command prompt launch and the task scheduler launch of the same command, I've also noticed that the following tray icon difference:

• task scheduler launch: tray icon option is not responsive the whole time until I get a timed out error, even after the drive is mounted (I can open it in a file explorer) and I get a confirmation of that via a USB Safely Remove addon
• command line launch (console persists for some time): tray icon is not responsive for the first few seconds (even after the mount is complete and I can open it in a file explorer), but works just fine after I get confirmation via that addon
• command line launch (console is closed after a second after launch, BUT it's not like I'm intentially interrupting the cppcryptfs process or anything, I can see a new > prompt line): the tray icon disappears right away

Do you have an idea why that might be? What makes the launch of the same command via the task scheduler so unstable that it can't persist and makes the tray icon permamently unresponsive? Is it somehow connected to the fact that you need to keep the console longer than a few seconds after launch?

Thanks, would love to finally be able to use cppcryptfs without any of these inconveniences