locked
Reading certain DLLs on write-protected media fails spectacularly RRS feed

  • Question

  • 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?  Here's the setup:
    • On media you can write protect (i.e., a flash drive) 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 the DLL as it sits on the media: fails silently without even pop up a properties page.  Can also cause Explorer issues.
    Can someone explain why one cannot copy or even read the properties of such DLLs? Simple copying is disallowed if the DLL is on write-protected media, and in fact any attempt (from Explorer, a cmd prompt, another app) to read the DLL's data causes a pretty firm hang-up in the system requiring a reboot.  It seems Microsoft DLLs are particularly susceptble, perhaps because somewhere else in the system they are considered "special" (e.g, by WFP).

    Mind you, if the media or partition is NOT write-protected it works just fine, so I don't buy that it's some intended feature of WFP or such: it's nonsensical that one could easily read and copy a DLL but it causes system lockups only when said DLL is on read-only media.  Turn off write-protection on the media - no problem.  Turn it on and too bad, so sad, your system needs a reboot ASAP.

    So what's going on, and how might one get that to work normally? I've never seen anything quite like it... can anyone reproduce this behavior?

    Why does this matter? Because it causes big problems when comparing / verifying stored data (i.e., backups) on read-only media (so far I've tested this on a flash drive with a hardware R/O switch and a software drive emulator, but I suspect this is a general problem - haven't tried CDs yet but they seem to be treated differently by Vista, unlike other removable media or removable media emulators).  It's not a trivial issue or an extreme boundary case either.  A bug as serious as this merits discussion if it is indeed reproducible.  Thanks in advance if you can help! :-)

    Sunday, January 11, 2009 11:47 AM

Answers

  • Well, that stinks: it's apparently Avast.  That stinks on a whole new level since I've depended on it for a long time versus more bloated and buggy alternatives.  I'll work it out with them - I've narrowed down where the error occurs though it's not clear why it happens.

    I gather from all this that you never actually tried my quick little test.  Out of curiosity, how long does it take *you* to install a pristine test copy of Vista or Win7 for that matter?  Hours, minutes, or do you just pull a ready-to-run image from somewhere, perhaps into a virtual machine?  I ask because so often it is suggested to end-users to "reinstall" and spend many hours performing such activities, and I wonder just how difficult it really is for someone there to reproduce an issue to the extent of saying, "no, we tried it and we don't see it here" (in terms of setup time).

    Don't get me wrong: I very much appreciate the diagnostic info - it led me to the source of the problem.  I just know that most people would give up in frustration after being told once too often "reinstall the system" and go elsewhere.  I'm rather persistent, but that's the exception not the rule when it comes to regular end-users.






    Friday, January 16, 2009 9:07 AM

All replies

  • Hi Marty,

     

    I have never experience this kind of cases before. I suspect that this issue is caused by the hard drive. Have you tried other devices?

     

    If any other devices that have write-disabled function have the same issue, please let us know:

     

    1. How it works if you turned on write-protect and turn off again.

    2. Before it hangs if the copy of the process starts.

    3. If this issue occurs after copying other kind of files, for example, *.exe files, documents, etc. If so, how does it work when you launch these files.

     

    I suggest that you boot in Safe Mode and check if the issue occurs. Please restart computer, press the F8 key when the boot menu pops up, select [Safe Mode], and boot up.

     

    If the issue does not occur, I suggest that you try to remove filter drivers.

     

    Delete filter driver

    =====================

     

    1. Click "Start", in the Start Search box type "regedit" and press Enter. 

    2. Navigate to the following key:

     

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E965-E325-11CE-BFC1-08002BE10318}

     

    3. Right click on "Class", click "Export"; please name the file as "RegBackup" (without quotation marks) and then save it to the C:\ drive as a backup.

     

    Note: In case we need to undo the modification, we can double click this RegBackup.reg file to restore the registry key.

     

    4. Highlight this key, on the right pane, check if the "Upperfilters" and "Lowerfilters" values are present. If so, please right click on the values and select "Delete" to remove them.

     

    After deleting filter drivers, please reload the drivers.

     

    Reinstall driver

    =====================

    1. Insert the drive. Click "Start", in the Start Search box type "devmgmt.msc" and press "Enter".

    2. Expand "Disk Drives".

    3. Right click the entry of the flash drive, and click "Uninstall". Please uninstall all devices.

    4. Restart the computer.

     

    The drivers will be loaded automatically.


    Arthur Xie - MSFT
    Monday, January 12, 2009 8:27 AM
    Moderator
  • Safe mode test: very intersting - the copy and props page read worked without problems.  Not terribly useful though for regular use but it narrows things down to 50-odd services that normally run (is WFP one of them?)

    In normal mode, I originally saw this in a software emulated drive (via TrueCrypt) but I then tested this using two different flash drives (with write-protect switches).  Same exact problem.  Thinking maybe it's a system thing, I tried it on the Windows 7 beta I downloaded and installed (clean install) earlier today.  Same exact problem. Explorer locked up solid and the only recourse was to reboot (only took about 5 minutes for the watchdogs to finish timing out and the Logging Off icon is still spinning... 10 minutes so far, finally had to power-cycle it).  The only add-on for my Win7 install is Avast antivirus and the usual display drivers.  I only mention Win7 because it should be very similar to Vista at this level (and indeed it experienced the same issue).

    Whatever is going on I strongly suspect it's Windows itself, mainly because this only affects particular Microsoft DLLs, ones that Windows apparently protects extra-carefully.  I'm seeing this issue (logged in as an adminstrator) on two versions of Vista on two different types of hardware and in Win7 as well.  I never had any such issue in XP or prior OSes, and Avast has been on my systems for a couple of years now so again, not related.

    When media is RO the problem occurs.  When it is RW it has no problems at all.  Toggling doesn't change that.

    The copy process starts but it never goes anywhere - it doesn't even create an empty destination file.  It just never ends and cannot be canceled.  If you try to read the DLL from Perl or another app, the app or apps involved hang up tight and cannot be terminated even as admin.

    The filters you mention are for CD/DVD drives and shouldn't even apply to removable USB flash drives and the like. I haven't bothered trying CD/DVD media because they are handled very differently by the system anyway.  I only saw Lower filters set: Afc and PxHelp20, but those (and that key) are specifically for CD/DVD burners.

    Again, this is very easily and quickly reproducible:
    Copy MFC71.dll from system32 to a flash drive that can be WPed, then plug it in and try dragging and dropping said DLL to your desktop.  It might work in safe mode but is doesn't work in normal operation when the media is write-protected.  If you or someone else can reproduce this issue it'd be a step in the right direction.  Thanks again! :)

    Monday, January 12, 2009 11:26 AM
  • Followup: On the Win7 Ultimate x64 installation (being the cleanest one and reproducing this issue on it) I ran a different test.  Except for the services used in Safe Mode, I manually disabled all the other running services.  A few intrinsic ones could not be disabled, but I did what I could.  Same problem was seen as before.

    I wonder, then, what else is different when one is in Safe Mode?

    ...

    After all that, I did break down and create a CD with the same test files on it (including the problematic MFC71.dll).  As I pretty much expected it didn't exhibit the same problem (it's not mounted like flash drives and other disk drives are, thus my lack of surprise).

    Also note the two flash drives I tested this with were quite different (one, very old generic USB drive and one a very new SD card, in a USB carrier, both with hardware write-protect switches).

    Reproducing this using the same DLL will help immensely.  In detail, I am seeing this issue with MFC71.dll v7.10.3077.0, MD5sum = f35a584e947a5b401feb0fe01db4a0d7 (pristine).  I've observed with with other MFC DLLs but that's the one I keep testing against.

    Thanks again!
    Monday, January 12, 2009 12:39 PM
  • Hi Marty,

     

    Thank you for your reply. From your description, I find the following facts.

     

    1. The issue does not occur in Safe Mode.

    2. The issue occurs in a newly installed Windows 7 Beta system which only has Avast installed.

    3. The issue occurs after you disable all the system services that are not enabled in Safe Mode.

    4. The issue occurs with multiple USB devices.

     

    From the above situations, I suspect that the culprit is the Avast anti-virus. Programs, process or explorer add-ons from this program may block the copy. I suggest that you temporary clear the anti-virus and then check if the issue still occurs.

     

    Additionally, you may reinstall Windows 7 Beta on a different partition on the same computer, and then do not install anything. Then check if the issue occurs on this fresh system.

     

    If it is convenience, you may also make parallel installation on the Windows Vista computers and test the issue on the clean system. To do so, we could confirm if this issue is caused by any system services.


    Arthur Xie - MSFT
    Friday, January 16, 2009 8:08 AM
    Moderator
  • Well, that stinks: it's apparently Avast.  That stinks on a whole new level since I've depended on it for a long time versus more bloated and buggy alternatives.  I'll work it out with them - I've narrowed down where the error occurs though it's not clear why it happens.

    I gather from all this that you never actually tried my quick little test.  Out of curiosity, how long does it take *you* to install a pristine test copy of Vista or Win7 for that matter?  Hours, minutes, or do you just pull a ready-to-run image from somewhere, perhaps into a virtual machine?  I ask because so often it is suggested to end-users to "reinstall" and spend many hours performing such activities, and I wonder just how difficult it really is for someone there to reproduce an issue to the extent of saying, "no, we tried it and we don't see it here" (in terms of setup time).

    Don't get me wrong: I very much appreciate the diagnostic info - it led me to the source of the problem.  I just know that most people would give up in frustration after being told once too often "reinstall the system" and go elsewhere.  I'm rather persistent, but that's the exception not the rule when it comes to regular end-users.






    Friday, January 16, 2009 9:07 AM
  • Hi Marty,

    Apologize that we did not help. I hope that the new system works fine. If there is any trouble I will try my best to help.

    Thursday, January 22, 2009 9:29 AM
    Moderator