[Bug] cppcryptfs -> Thunderbird crash

[dcsITsolutions]

Windows 10 cppcryptfs 1.4.1.4 64bit Dokany 1.3.1.1000

I start cppcryptfs and decrypt my folder. The configuration files for Thunderbird are in this decrypted folder. I can start Thunderbird and do some stuff in it. Earlier or later cppcryptfs crashs and restarts. I couldn't find a definitive trigger for it. How can i generate a log to share it here?

Edit: the encrypted folder sits on the onedrive-folder. So it is synced between different machines. I never used them in parallel to avoid sync-conflicts. Nonetheless it works fine with regular files, config files of mRemoteNG, WinSCP, etc. Problem appears only when i use thunderbird.

[dcsITsolutions]

Any Update here? After installing Thunderbird 78.2.1 cppcryptfs is crashing instantly when opening Thunderbird.

Can i paste any logs to help fixing that problem?

[bailey27]

When you first posted the issue, I was really busy. By the time I had time to work on it, I was basically hoping the problem had gone away. I'm sorry, I should have checked back with you.

I'll get Thunderbird installed in my VM and see if I can reproduce it.

[dcsITsolutions]

Sorry to disappoint you, that it didn't gone away. In the past it was crashing randomly after some time. I arranged with that force closed thunderbird, restart cppcryptfs and started thunderbird again. not great but was ok to work with.

Setting again: Windows 10 Dokany 1.4.0.1000 Bundle cppcryptfs 1.4.3.0 64bit Thunderbird 78.2.1 (64-Bit) [i changed to 64-bit but behaviour didn't changed]

I use OneDrive on C:\OneDrive cppcryptfs mounts C:\OneDrive as B:\ Thunderbird ist installed regularly on C:\ProgamFiles My Thunderbird profile is on C:\OneDrive\Thunderbird...

I start my computer, wait until onedrive sync finished, start cppcryptfs and then start Thunderbird. cppcryptfs immediately crashes and restarts itself.

[bailey27]

Did you maybe misspeak about how this is set up?

You say you have your encrypted filesystem in the root of your OneDrive? I think this isn't a good idea. I think it would be better to make a folder under C:\OneDrive and put your encrypted files there, e.g. C:\OneDrive\encrypted

Normally, OneDrive wants to put a Documents and a Pictures folder in the top-level OneDrive directory.

It's not a good idea to have files in the encrypted filesystem directory that aren't part of the encrypted filesystem. cppcryptfs is supposed to ignore them, but it's better not to have them there.

Also, you said your thunderbird profile is in C:\OneDrive\Thunderbird.

Shouldn't it be in B:\Thunderbird if you want to encrypt your profile?

Another possible issue is that drive letters A: and B: can be problematic. Even though they generally work, Windows treats A: and B: differently from the other drive letters. I guess it goes back to the days when they were reserved for floppy drives. A while back someone had a problem with Windows update, and using drive A: to mount on turned out to be the cause.

I did this to try to reproduce the crash.

I was using my Windows 10 VM which didn't have OneDrive set up or Thunderbird installed initially.

I created an encrypted filesystem in c:\tmp\tbirdtest

Then, I mounted it on K: and I installed the thunderbird software in k:\thunderbird (in the mounted cppcryptfs volume).

I know you didn't do that, but I figured if anything it would make things more likely to fail.

Then I created a profile stored in k:\tbirdprofiles. I configured thunderbird and sent and received a few emails.

Then, to do my best to replicate your setup, set up one drive in my VM with its root in C:\OneDrive and created an encrypted filesystem in C:\OneDrive\test. I DID NOT put it in C:\OneDrive (the root of one drive).

Then I mounted C:\OneDrive\test on drive B: and copied my profile to B:\Thunderbird and ran the thunderbird profile manager again to change the profile to there. It used the files that were already there (my email config still was there and worked).

I started Thunderbird and sent and received some more emails.

I haven't had a crash yet or any complaints from Thunderbird.

I can definitely see (by looking at global-messages-db.sqlite in my B:\Thunderbird directory) that it is really where my profile is. I can find in that file specific phrases I sent in the test messages that I sent after I moved my profile.

I would recommend trying the following things:

1. Create a directory under C:\OneDrive and put your encrypted filesystem there instead of in the root of onedrive. You can just create the directory and move gocryptfs.conf, gocryptfs.diriv, and all the encrypted-looking files from C:\OneDrive to the sub-folder.

2. Mount to a drive letter other than A: or B: and tell thunderbird your profile is there.

3. Try using DropBox instead of OneDrive

[dcsITsolutions]

Sorry for late reply.

cppcryptfs: 1.4.3.0 64bit Dokany: 1.4.0.1000 Thunderbird: 78.2.0.7556

Folder-Location: C:\OneDrive\cppcryptfs Mount-Point at cppcryptfs: Z:\ Thunderbird-Installation: C:\Program Files (x86)\Mozilla Thunderbird Thunderbird-Profile: Z:\Privat\Thunderbird\Profiles\zgp5t2e7.default

At first time thunderbird worked but after a reboot cppcryptfs keeps crashing instantly. Dropbox is not an alternative for me =/

How can i generate a log for you?

Edit: I got following information from event log if it helps: Ausnahmecode: 0xc0000005 Fehleroffset: 0x000000000007cc64

[bailey27]

I'm sorry it still doesn't work.

cppcryptfs has a logging mechanism, but it is completely disabled in release builds.

I'll make a custom build that logs for you soon.

[bailey27]

I created a version that logs to a file and attached it.

To make logging work, you must first create the directory

C:\cppcryptfslogs

cppcryptfs will create a file there based on the current date and time (year, month, day, hour, minute, second) like this

C:\cppcryptfslogs\cppcryptfs-2020-09-20_09.57.19.log

The logging is not totally complete. cppcryptfs logs whatever dokany mirror would plus other debug messages I added while I was developing cppcryptfs.

It logs the UNENCRYPTED FILENAMES of all files it opens or is asked to open.

I think it does not log anything else that might be sensitive, but you should check the log before sending it.

Also, the dokany mirror logging mechanism was printing the username and domain name. I disabled that. It was querying it from the requestor token. This was very expensive, and I've never found that info useful.

I also made it flush the output to the file on every log message it prints, so if it crashes, we'll be able to see the last thing it logged.

Because of how Windows displays file sizes of files that are open and being written to, the log file will appear to be empty until either Windows decides to display the actual file size, or the program exits.

Please run cppcryptfs and reproduce the problem and send me the log file after scanning it for anything sensitive.

cppcryptfs_1.4.3.1_logging.zip

[dcsITsolutions]

Thank you for providing a version with logging enabled. I ran it twice. Once with user privileges and once with admin privileges.

With user privileges the logfile is about 3mb and has a lot of errors with error code 2,80,183 With admin privileges the logfile is about 18mb but has only 1 error at the end with error code 2.

I sent the logfiles to your mail-address.

Interesting side note: After crashing onedrive recognizes a deletion of 700 files and asks to confirm. I always confirm it.

[bailey27]

I think the error code 2's aren't important. It looks like Thunderbird is trying to open the journal file for an sqllite db file and isn't finding it.

I see lots of these when I run it myself with no problems.

Unfortunately, I can't tell why it's crashing from looking at the logs.

It looks to me that some other thread in cppcryptfs is crashing while the last thing in the log is being printed, but I can't tell what it's doing when it crashes.

I think you might want to try going to the settings page and change the per-filesystem threads to 1 and see if that helps.

Another thing I realized was that I am using Thunderbird 78, but you might be using 68. It looks like Mozilla was holding current 68 users back on 68 until recently. They say you can download 78 and do an upgrade if you aren't offered 68 yet by the automatic updates. Maybe 78 will work better for you.

Another thing we could try is generating a crash dump.

The crash dump will enable me to see where in the code cppcryptfs was when it crashed.

I cannot make ANY PROMISES about what sort of SENSITIVE INFORMATION might end up in the crash dump.

One idea would be to make a throw-away encrypted filesystem under your OneDrive directory and create a throwaway Thunderbird profile there and try to reproduce the crash using them.

If you get this tool https://docs.microsoft.com/en-us/sysinternals/downloads/procdump

Then you can do this (in an administrator cmd prompt)

md c:\dumps

procdump64 -ma -i c:\dumps

Then, when cppcryptfs crashes, procdump should generate a file like

cppcryptfs.exe_200927_114204.dmp

in c:\dumps.

The file will be about 150MB. 7-Zip can compress it down to around 30MB, but it will still be too big to attach to gmail. You could use 7-zip to split it into a couple of files and attach them to separate emails.

You MUST use one of the cppcryptfs.exe in the ATTACHED zip file because I saved the debug symbols for those.

Please try to use the one under Debug first, as that will get me a better stack trace.

Also, at least in my setup, procdump causes two .dmp files to be created on each crash. If this happens, I should be able to use either of them (shouldn't need both).

cppcryptfs_for_crash_dump.zip

[dcsITsolutions]

Thank you for your further investigation. I changed the per-filesystem-threads to 1 in your modified debug version.

As said above i am on 78. I also have the latest stable release of thunderbird.

No changes in behaviour =/

I sent the crashdump including the cppcryptfs-log to you. Thanks again.

[bailey27]

Thanks for the crash dump.

cppcryptfs was crashing because I was not checking for a null pointer return from the the function that encrypts the destination path when doing a MoveFile operation. I think the root cause is the gocryptfs.diriv file in the destination directory is either missing or inaccessible (e.g. permissions wrong).

I emailed you some things you might want to try before using the build I'm attaching.

I'm attaching a a build that checks for the null pointer return and also logs every error that might occur in the code path that results in the null pointer being returned.

Here is the build. I did only a debug build because it worked last time.

cppcryptfs_for_crash_dump2.zip

[bailey27]

An update for anybody else watching this issue.

The fix worked. I'll be releasing a new version in the next few days with the fix.

[bailey27]

1.4.3.2 is released with the fix.

https://github.com/bailey27/cppcryptfs/releases