Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
BSOD when AvastAV is installed #97
As discussed in https://forum.rclone.org/t/rclone-v1-37-release/3194/16 am currently receiving a BSOD error when attempting to access the mount point created by RCLONE in Windows. This fault can be replicated easily in both Windows 7 and in Windows 10 (Replicated fault on 2 different systems)
Error states that there is an issue with module "aswsnx.sys" and the entire system crashes.
Full process workflow:
1> Install rclone 1.3.7 + winfsp + avast AV (latest version of all)
As requested, I have obtained minidump files (3 in total inside this archive - https://www.dropbox.com/s/qrv29kalw8s3gzr/Minidump.7z?dl=0)
Please let me know if any further information is required in order to troubleshoot.
@zapoklu I finally took a look at the minidumps you have sent.
All minidumps indicate a
Unfortunately this is not a lot of information to go by. I list potential things that may help below:
From my perspective I will see if I can install Avast and try to reproduce the problem. It may also be worthwhile trying to report this problem to the AvastAV product people.
Interesting. I am back from vacation and will install one of these antivirus products and see for myself.
It might be that WinFsp responds to some file system request in a way that confuses these products. BTW, I am wondering why not use Windows Defender (which does not exhibit any such issues)? Do these third party products provide additional protections?
Good Morning Bill, Sorry but I don't understand your question or, the problem you are having. Can you please be more specific? Warmest regards, Bob =============================== [image: --] Norbert (Bob) Gostischa [image: http://]about.me/bob3160 <http://about.me/bob3160> Free Security Seminars available.Here's a sample: <http://www.authorstream.com/Presentation/bob3160-1425909-protecting-yourself/> *Protecting Yourself, Your Computer and, Your Identity <http://www.authorstream.com/Presentation/bob3160-1425909-protecting-yourself/>* Absolutely free, ask me for details. *(505) 250-1089* *See where I've done Presentations lately: * *http://bob3160.blogspot.com/ <http://bob3160.blogspot.com/>* * Proud Member* Speakers Bureau…
On Fri, Sep 1, 2017 at 5:18 PM, Bill Zissimopoulos ***@***.*** > wrote: Interesting. I am back from vacation and will install one of these antivirus products and see for myself. It might be that WinFsp responds to some file system request in a way that confuses these products. BTW, I am wondering why not use Windows Defender (which does not exhibit any such issues)? Do these third party products provide additional protections? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#97 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALq49gLSsOZ28CQWnV9JvyGSkzsFnOcxks5seHS0gaJpZM4OjZ0y> .
How to reproduce
I am able to reproduce this problem on a Win8 VM with debugger attached and full WinFsp debug logging enabled.
The file system used is MEMFS running under the SYSTEM account. This makes the created drive accessible from all accounts.
The commands to reproduce (once the file system is running):
The (elided) WinFsp log shows just before the crash:
This shows the root directory
The stack trace reported by WinDbg at the time of the crash confirms that this is due to a directory listing operation:
So what happens is that
WinFsp may switch the process context from the process issuing the
While this is a peculiarity of WinFsp I note that Microsoft's own FSD's may not always complete
I now note that this theory may be incorrect because the current process during the bugcheck is actually
I finally have an update regarding this issue. Petr Kurtin of Avast has been very helpful in explaining to me some of the internal workings of the Avast filter. Thank you Petr!
It is not clear why the Filter Manager fails to copy the
It seems clear to both of us that Avast is not at fault here. It uses a documented Filter Manager interface to fetch directory data. Therefore the only place that this can be fixed is WinFsp.
Currently WinFsp uses
Are you using buffered I/O? (DO_BUFFERED_IO bit in the Flags field of the device object)? The norm is neither, in which case the I/O manager expects you to write into the user buffer (which in this case would be the kernel address from the other filter). I’ve never used buffered I/O, always neither, so I’m not sure how heavily used that path is (for example, security has always been neither, regardless of the device object flags because no other file system supported security other than NTFS. I suppose someone could have implemented it.)…
On Oct 12, 2017, at 10:31 PM, Bill Zissimopoulos ***@***.***> wrote: I finally have an update regarding this issue. Petr Kurtin of Avast has been very helpful in explaining to me some of the internal workings of the Avast filter. Thank you Petr! During IRP_MJ_DIRECTORY_CONTROL preoperation, the Avast filter may issue an FltQueryDirectoryFile and process the results. Petr has found that under WinFsp he receives "empty" results (i.e. the response buffer he passes to FltQueryDirectoryFile does not get filled). We speculate that this is because FltQueryDirectoryFile fails to copy the Irp->AssociatedIrp.SystemBuffer into Irp->UserBuffer (as for example happens when issuing NtQueryDirectoryFile). It is not clear why the Filter Manager fails to copy the SystemBuffer to the UserBuffer in this particular case. It should be noted that this behavior is different from the default IO Manager behavior. It seems clear to both of us that Avast is not at fault here. It uses a documented Filter Manager interface to fetch directory data. Therefore the only place that this can be fixed is WinFsp. Currently WinFsp uses Irp->AssociatedIrp.SystemBuffer to report an IRP_MJ_DIRECTORY_CONTROL / IRP_MN_QUERY_DIRECTORY result. I intend to change this to use Irp->MdlAddress which should resolve this issue. However the IRP_MN_QUERY_DIRECTORY handler is quite complicated and this change is not trivial. It will take me some time find the best way to resolve this. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
WinFsp does not use buffered I/O. It uses "neither".
As you well know, @fsgeek, under the IO Manager if you set the IRP bits
[WinFsp sets the
I am suspecting that
So we now have two Windows components that dislike how WinFsp handles
Yes. This is a problem with components that build their own IRPs - filter drivers and in kernel file servers. They only test what's used not what's specified. I've always done this with the user buffer pointer. It shouldn't be logically different other than the need to use try/except and probe the buffer for proper access.…
On Oct 13, 2017, at 9:27 AM, Bill Zissimopoulos ***@***.***> wrote: WinFsp does not use buffered I/O. It uses "neither". Under the IO Manager if you set the IRP bits IRP_BUFFERED_IO | IRP_DEALLOCATE_BUFFER and also set Irp->AssociatedIrp.SystemBuffer, the IO Manager will dutifully copy the SystemBuffer into Irp->UserBuffer and then deallocate the SystemBuffer during IRP completion (and during the special kernel APC in the context of the originating thread). [WinFsp sets the IRP_BUFFERED_IO | IRP_DEALLOCATE_BUFFER bits and Irp->AssociatedIrp.SystemBuffer during IRP_MN_QUERY_DIRECTORY processing.] I am suspecting that FltQueryDirectoryFile does its own completion processing and does not expect an FSD to ever set the SystemBuffer. In a somewhat similar case, discussed here, SRV2 was unable to handle IRP_MN_QUERY_DIRECTORY responses from WinFsp and I had to work around the problem. So we now have two Windows components that dislike how WinFsp handles IRP_MN_QUERY_DIRECTORY even if the IO Manager is ok with it. This means that I must bite the bullet and change this handling. ― You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
Commit 07f15c2 should fix this issue.
This commit passes
This is a MAJOR change in how WinFsp handles
One of my goals is to incorporate Avast into the WinFsp test suite to avoid such issues in the future. More commits towards this goal will follow. Such commits will appear in the
This change should appear in