Vista - Extra-puzzling file copy problem

I've recently upgraded one machine from XP Pro to Vista Business 32-bit, and the other is a brand new laptop with Vista Home Premium x64. Both exhibit the following problem... or is it just me?

The setup:

On media you can write protect (i.e., a flash drive) make a copy of mfc71.dll (usually found in Windows\system32... other MFC DLLs seem to have the same effect but try this one if you have it).

Now, remove the media, write-protect it and re-insert it. Attempt to copy that DLL from the media to your desktop (NOT in \Windows or other highly protected areas). Attempt to read the properties page of the DLL as it sits on the media: doesn't work.

Can someone explain why one cannot copy or even read the properties of such DLLs? I can see if it's replacing something bad or such, but simple copying is disallowed if the DLL is on write-protected media. What's up with that? And how might one get that to work normally? I've never seen anything quite like it.

Why does this matter? Because it causes MAJOR problems when comparing backup media that uses an emulation layer to emulate a drive (e.g., TrueCrypt). In the example above it just doesn't work... in something like TrueCrypt (within a write-protected volume) it locks Explorer up quite thoroughly, requiring a reboot. I presume that's a failure of TrueCrypt but still, what the heck is Vista doing here?

A program called Resource Hacker will yet you read and change some dll. Resource Hacker

That's not the problem though. Any attempt to copy or otherwise open the DLL on the write-protected media fails, either grossly (e.g., explorer hangs up tight) or by refusing to proceed. It doesn't make any sense and it's extremely annoying (any time it fails badly you have to completely reboot). And of course it's all fine and dandy if the media is writable... why does an attempt to *read* a very common DLL require anything to be written to it or its location?

Try reading/copying the write-protected/in use file either by ending the process through task manager first- or by booting into safe mode. Also try removing the write protection.

1. The DLL is not "in use" at the test location. There is no process to end.
2. Even in an exclusive-lock scenario such an action should result in an access denied error, not an (apparent) deadlock deep in the system.
3. This solely depends on the media being writable or not. Unprotecting backup media isn't always an option nor sensible (lest said backup data get overwritten).
4. Bizarrely, problems occur when the media is write-protected. Thus the question: what's going on? This isn't expected behavior and it certainly isn't useful behavior in any respect.

I posted this elsewhere and made headway: in short, it appears to be a weird interaction with Avast Antivirus. If you disable it the problem goes away (which at least narrows it down). Hopefully they can figure out what's going on.

have you tried zipping it before write protecting it? then unzipping and extracting it to a location.

I'm not sure I understand why I'd do that zip/unzip thing except as a temporary workaround - problem is you never know what the next file will be that will cause another hard-stop.

My concern is that this sort of hard-stop shouldn't happen at all: it causes big problems during such tasks as backup verification against write-protected media, where even a DOS-level attempt to read the contents of the file (say, for checksum verification or byte-wise comparison) will cause the system to halt. If it just failed the file gracefully or marked it as unreadable I'd be a little more sympathetic but this failure mode is just plain useless. Hopefully they get to the bottom of this.