BSOD when AvastAV is installed #97
Comments
|
Thank you. I am going on vacation in a couple of days, but I am nevertheless hoping to find some time to look at this soon. |
billziss-gh
changed the title
|
@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. |
|
I wonder if disabling the self-defense module in Avast prior to creation would solve the problem ??? |
|
I get the same issue when using AVG Anti Virus. The same PAGE_FAULT_IN_NONPAGED_AREA error is shown on the BSOD but the file is an AVG file and not an AVAST file. I had AVAST before AVG and swapped because of the error. I do not get this error with neither installed. |
|
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>
.
|
|
@billziss-gh Historically, Windows Defender has been very poor at identifying Windows threats. Avast has been great at doing it (And is free). |
How to reproduceI 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): AnalysisThe (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 SpeculationWinFsp 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 Update I now note that this theory may be incorrect because the current process during the bugcheck is actually Full
|
|
I have contacted the Avast people with a link to this issue. Hopefully we will hear from them. |
|
Thank you so much @billziss-gh for taking the time to look at this. Much appreciated. |
|
@zapoklu, you are welcome. Let's hope we will also hear from the Avast people, because we might need their help to figure out why this is failing. |
|
As of 2017-10-03 I have not received any response from Avast on this. I just emailed them again and plan to also ping them on Twitter. Does anyone know any solid contact that we can use to gain traction on this issue? |
|
I have no idea of a solid contact for Avast. I personally believe that if a lot of people keep telling them about the issue, they will do something about it. |
|
Did you try disabling the Self Defense Module as suggested in my original (first) reply? |
|
Some good news as I have finally heard from Avast on this. Will keep you posted on the progress. |
|
@MLPAA I think the intent is to fully solve the problem rather than simply work around it. I personally do not use Avast, but people who do may try your suggestion. |
|
@billziss-gh The suggestion isn't to work around it but to solve it. You obviously don't use the product or you would have known why the suggestion was made. |
|
@MLPAA If you have found that disabling the "Self Defense Module" resolves the problem, then I am happy to promote this as a solution/workaround until we fully resolve the issue. |
|
@MLPAA FWIW I tried disabling the "Self Defense Module" as per your suggestion and the BSOD still appeared. |
|
Thanks for the effort invested so far @billziss-gh . Really appreciate it mate. |
|
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 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 NOTE: The UPDATE: Latest commit (1a02438) in pvt-avast branch passes all tests on AppVeyor. |
|
Commit fa388e5 adds regular Avast testing in AppVeyor. |
|
Closing this as it is now resolved. The fix will be included in the |
Hi there,
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)
2> Copy existing rclone.conf file from linux system to windows system into default configuration directory (in my case "C:\Users\respe.config\rclone\rclone.conf")
3> Using this config file, Mount an encrypted remote (In my case, The base remote was a google drive backend referenced as google:/ , encrypted mount point cloud:/) -- Full command syntax : rclone.exe mount cloud: g:
4> Mount drive letter appears in Windows Explorer. Navigating to it via WE and attempting to access the contents causes the fault listed above.
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.
Thanks!
Z
The text was updated successfully, but these errors were encountered: