encfs.exe in verbose "-v" mode causes system instability

[gh223682]

encfs.exe in verbose "-v" mode without any other options causes system instability.

Specifically, encfs.exe either crashes without useful myeasylog.log logging information or occasionally takes down the whole system with UNEXPECTED_KERNEL_MODE_TRAP. So I can't get far enough to debug.

I experienced this with at least encfs.exe 1.10.1-RC4+ on Windows 10. I think the problem might be that the filesystem can't keep up with the logging, even though I am using plenty-fast enterprise-grade hardware and SSDs.

[jetwhiz]

@gh223682 -- I've noticed this, but I'm not sure what can be done to fix it (other than piping the data into a file). The issue is that there is so much debugging info that it bogs down the system (especially for intensive operations, like writing files).

I'll try to come up with something -- maybe cutting down the amount of info that is output?

[gh223682]

I'll try to come up with something -- maybe cutting down the amount of info that is output?

@jetwhiz How about different verbosity/logging levels?

[jetwhiz]

The bulk of the issues were caused by unnecessary logging in compatwin.cpp (which doesn't exist upstream, of course). Commenting out these logs (as well as a few others) fixes the issue.

The logs causing the issue were called way too often (e.g., log every time a block is written or read) to be useful anyways.
patch.txt

I'll roll this patch out in RC6.

[Zero3]

Just for reference: encfs4win 1.10.1-RC6 just took down my whole system with a BSOD today too. I was running with verbose logging, so I guess it might be the same issue as this one.

@jetwhiz As far as I understand, you did not fix the underlying issue, right? From my point of view, logging should not be able to cause a BSOD, regardless of volume. Something much more serious must be going on.

[gh223682]

@jetwhiz Logging in background/daemon mode for 1.10.1-RC6 no longer works. Is this by design?

[gh223682]

@jetwhiz I'm trying out 1.10.1-RC6, and I'm not able to mount a virtual drive once I run encfs.exe in verbose mode.

All subsequent invocations of encfs.exe--with and without the verbose switch--just hang without completing the mount of the virtual drive, and I have to reboot to get things working again.

I am killing encfs.exe after each attempt.

[jetwhiz]

@gh223682 @Zero3 Is this issue only occurring with Windows 10? And the issue started with RC4? The BSOD only happens when you guys are running in verbose daemon mode? I haven't experienced any BSOD issues with Windows 7.

Daemon-mode logging is now sent to %TEMP%, so you should be able to find the logs there.

When you kill encfs.exe, it is not possible to properly clean up after itself. Try to use "dokanctl.exe /u MOUNTPOINT" (provided by Dokan) to cleanly unmount the volume, and then encfs.exe should close itself.

[gh223682]

Is this issue only occurring with Windows 10? And the issue started with RC4?

@jetwhiz I've only tested RC4+ on Windows 10. I have not had any BSOD issues thus far with RC6 in verbose mode.

I have access to a Windows 7 machine if you need extra testing, but will be upgrading to Windows 10 soon.

Daemon-mode logging is now sent to %TEMP%, so you should be able to find the logs there. When you kill encfs.exe, it is not possible to properly clean up after itself. Try to use "dokanctl.exe /u MOUNTPOINT" (provided by Dokan) to cleanly unmount the volume, and then encfs.exe should close itself.

Okay, got it. Prior to RC6, I was just using taskkill or running in foreground mode and terminating with Ctrl-C without any problems. Now that I better understand what is going on under the hood, I do think that not being able to mount the volume is something that encfs.exe should complain about.

All I see in the log file is:

2016-05-29 06:13:49,525 VER [main.cpp:534] Closing stderr 2016-05-29 06:13:49,525 VER [openssl.cpp:47] Allocating 41 locks for OpenSSL

[Zero3]

@jetwhiz Windows 7 64-bit here. First BSOD I ever got with encfs4win, so I have no idea whether verbose logging was a deciding factor or in which version the issue was introduced. I was in the middle of a developing session for my tray manager thingy, so I had opened/closed encfs4win many times. Both with and without verbose mode, sometimes cleanly shutdown and sometimes forcibly killed. So I'm afraid I can't be of much more help other than noting that you can indeed still trigger a BSOD :(.

Thanks for the hint about unmounting via Dokan. I will try that instead of forcibly killing encfs4win in the future.

[gh223682]

@jetwhiz Would it be feasible to include Dokan debugging information with encfs.exe's verbose logging (in conjunction with Dokan debug libraries)?

[jetwhiz]

@gh223682 Unfortunately the Dokan debugging information isn't very useful right now with the FUSE API (see Issue 247), but this would definitely be useful as soon as better debugging output is coming from Dokan FUSE. I'll open a new issue to fulfill this request.

[jetwhiz]

I'm wondering if this could be related: https://github.com/dokan-dev/dokany/issues/230

It appears to happen after lots of concurrent mounts+unmounts with Dokan

[gh223682]

@jetwhiz I'm experiencing the aforementioned non-mounting issues running encfs.exe in NON-verbose mode, so whatever is causing this problem could be something completely unrelated to verbose mode.

When I start encfs.exe, the virtual drive is created, but the mounting of the EncFS volume never completes. If I try to execute a dokanctl.exe /u <mountpoint> unmount either before or after killing encfs.exe, dokanctl.exe will often either hang indefinitely or give me an error indicating the mountpoint does not exist:

DokanError: Ioctl failed with code 122

I haven't yet figured out a way to reliably reproduce this issue. I think that Dokan and Dokan FUSE information would be helpful.

[jetwhiz]

@gh223682 @Zero3

The latest encfs4win release (1.10.1-RC8) is now built against Dokany 1.0.0-RC4 (we had to skip over RC3, since it had compatibility issues with encfs). Can you test to see if these BSOD and instability problems still exist? I believe this Dokany release should take care of many of the issues you were experiencing.

[Zero3]

@jetwhiz I don't know how to reproduce, but I will let you know if I run into them again.