Author Topic: Copy/read of certain (signed) DLLs on write-protected media causes system freeze  (Read 6412 times)

0 Members and 1 Guest are viewing this topic.

MartyMacGyver

  • Guest
Got a problem here, confirmed in Vista Business x86 SP1, Vista Home x64 SP1, and even the Win7 beta.  The copy and/or read of certain (apparently signed) DLLs on write-protected media causes system freeze.

In summary, here's the setup to reproduce this issue:

  • Install Avast Home 4.8
  • On media you can write protect (i.e., a flash drive or software hard disk emulator, NOT CD/DVD media) make a copy of mfc71.dll (usually found in Windows\system32).  Note that other MFC DLLs seem to have the same effect but try this one if you have it available.
  • Now, remove the media, write-protect it using the hardware switch and re-insert it.
  • Attempt to copy that DLL from the media to your desktop (NOT in \Windows or other highly protected areas).  In my setups this copy process hangs tightly.
  • Attempt to read the properties page of that DLL as it sits on the read-only media: it fails silently without even pop up a properties page.  Also cause general Explorer issues unresolvable except by rebooting.

Under Avast Home 4.8 Troubleshooting, while the "Skip checking of digital signatures of infected files" box is unticked this lockup occurs. If the box is then ticked (I followed with another reboot) this operation works fine.   Interestingly, untick it again and it still works after all that (perhaps because info is being cached?)

Turns out that checkbox does NOT help the problem after all, at least not on every machine.  Safe to say that selecting "Stop On-Access Protection" DOES prevent the issue every time, but that defeats the purpose of this.  My x64 installation seems quite happy with all the settings back to where they started, suggesting cached data perhaps (the only other setting I toggled was "Disable the self-defense module" which didn't appear to have any effect on this issue).

Note also that the DLL in question IS signed.  THat might have some bearing on this.

Thanks again!

Your thoughts?

Note: I already took some of Microsoft's time hunting this bug down only to discover Avast is indeed the root cause.  I'm very pleased with Avast thus far and I'm reporting this in order to help improve it a little (having the system lock up tight due to a simple copy or file->properties request on a known-good file is a pretty big problem).
« Last Edit: January 16, 2009, 11:02:14 AM by MartyMacGyver »

doomer

  • Guest
Sounds like a sharing violation to me.

Offline igor

  • Avast team
  • Serious Graphoman
  • *
  • Posts: 11849
    • AVAST Software
I'm afraid this is not reproducible here.

Could you please try to generate a full memory dump after the copying freezes, compress it and upload it to our FTP?
Here is a description on how to generate such dump (the discussed problem is unrelated and very old - but the description is valid). The dump may tell us more about the problem.

The description I linked is for PS/2 keyboards only (i.e. not USB). If you have an USB keyboard, the registry key is different, see e.g. here.
Thanks.

MartyMacGyver

  • Guest
I'll look into the memory dump when I can.

I'm curious what OS you tested this with.  The problem has been readily reproducible on two versions of Vista as well as the Windows 7 beta (which had nothing else BUT this installed as an add-on).  One (a machine with both Vista and Win7) is a brand-new laptop.


MartyMacGyver

  • Guest
I've uploaded the memory dump to the incoming ftp area with an identifiable name.  This test was done during an attempted copy of MFC71.DLL from a locked flash drive to the desktop (the progress box was stuck on "Calculating").  Normal Avast options were active (On-Access protection was running, etc.) and no extra troubleshooting options were enabled during these latest tests (it didn't help matters when they were enabled).

If "On-Access Protection" is disabled and/or if the flash drive is unlocked then this works fine all the time.

Note that I used Win7 x64 beta build 7000 to run this test because I also see the exact same problem in Vista and it was far more straightforward to create a pristine installation this way.  This problem was never seen in XP Pro.

Offline pk

  • Avast team
  • Super Poster
  • *
  • Posts: 2078
Sorry about the delay in reply. Thank you for your fulldump - I've analyzed it and I was able to simulate the problem at Win7 (though not at Vista SP1, but it doesn't matter). The problem was in our XP/Vista+ drivers and both drivers will be fixed within an upcoming weekend update.

MartyMacGyver

  • Guest
Wow!  I'm glad it helped track down the problem!  :)

I look forward to testing the update when it's available.

MartyMacGyver

  • Guest
Out of curiosity, when will that weekend update with this fix in it be coming out?

Offline igor

  • Avast team
  • Serious Graphoman
  • *
  • Posts: 11849
    • AVAST Software
Might appear a few days later.

Offline Vlk

  • Avast CEO
  • Serious Graphoman
  • *
  • Posts: 11658
  • Please don't send me IM's. Email only. Thx.
    • ALWIL Software
There's a beta (pre-release) version already available - and it is very stable.
It would be helpful if you could give it a try to make sure the problem is solved.

For details, please see http://forum.avast.com/index.php?topic=42266.0
If at first you don't succeed, then skydiving's not for you.

MartyMacGyver

  • Guest
Vista Business x86 SP1, Vista Home Premium x64 SP1 and Win7 x64 Beta 7000 all work fine after this update.

If I see anything unusual I'll let you know, but so far so good.  I'm very glad to see it working properly again! :)  Thanks!

Question if you get the time: I assume this involved a general solution to this problem (not something specific to just these few DLLs).  I'm curious what exactly was going wrong in the driver: it certainly was a weird one.

Thanks again!

Offline Vlk

  • Avast CEO
  • Serious Graphoman
  • *
  • Posts: 11658
  • Please don't send me IM's. Email only. Thx.
    • ALWIL Software
Thanks for the confirmation that the problem is now solved.

Quote
Question if you get the time: I assume this involved a general solution to this problem (not something specific to just these few DLLs).  I'm curious what exactly was going wrong in the driver: it certainly was a weird one.

Starting with Vista, it is no longer legal to issue I/O if IRQL=APC or if special kernel APC's are disabled. This may be causing deadlocks e.g. when the underlying filesystem driver takes an error handling code path, scheduling the completion routine to run in the context of an APC. Our filter driver (aswMonFlt.sys) was issuing (in certain very specific cases) I/O while holding a mutex, i.e. at APC level.  ;D


Now, if what I've just said doesn't make any sense to you, let me just say we did something wrong and we're not doing it anymore in this new version. :)


Thanks
Vlk
If at first you don't succeed, then skydiving's not for you.

MartyMacGyver

  • Guest
Thanks for the detailed reply... it's always good to learn something new!

It certainly walked and talked like a deadlock would... I'm surprised it was even possible, but I imagine Avast hooks in pretty deeply to do its job.  I originally thought it was just an unacknowledged bug in Vista itself (wouldn't be the first) but in a way I'm glad it was in Avast... otherwise it might never get fixed. :)

There's an interesting article about IRQL and APC here (along with a link to the more detailed whitepaper):
http://blogs.technet.com/askperf/archive/2008/01/22/what-is-irql-and-why-is-it-important.aspx