The information in this article applies to:
SYMPTOMS
If you are using IFSMGR_Ring0FileIO services, you might encounter file
access problems when you run utility programs, such as DEFRAG, while
IFSMGR_Ring0FileIO files are open.
CAUSEThere is a bug in IFSMGR_Ring0FileIO that becomes apparent only when a level three volume lock is released and, as a result, the volume release automatically causes the ring 0 file to be re-opened. When the file is re- opened, the file access mode is erroneously set up with the contents of the file action type. For example, a file opened as follows:
is re-opened with the contents of EDX appearing in EBX. When appearing in
EBX, the value ACTION_OPENEXISTING (0x0001) corresponds to ACCESS_WRITEONLY
(0x0001).
RESOLUTIONWhen the level 3 volume lock is released, it re-opens the temporarily- closed files using FS_OPEN calls down to the target FSD (typically VFAT). You can hook IFS using IFSMgr_InstallFileSystemApiHook to correct "reopen" FS_OPENs on the fly before the FSD sees it. To see if a given FS_OPEN is actually a reopen due to a level 3 volume lock release, check for (ir_options & OPEN_FLAGS_REOPEN). In the Windows 95 Device Driver Kit, see header file IFS.h for flag details. When you find one of these, you can further test for ir_pid = -1, which corresponds to a file opened using the ring 0 functions. Change ir_flags to the correct file access method. For example, if ir_flags erroneously contains ACCESS_WRITEONLY, change it to ACCESS_READWRITE. Then let the file-system I/O proceed normally to complete the (corrected) file open. STATUSMicrosoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article. We are researching this bug and will post new information here in the Microsoft Knowledge Base as it becomes available. REFERENCESWindows 95 Device Driver Kit Additional query words: level3 IFSMGR
Keywords : |
Last Reviewed: October 12, 1999 © 2000 Microsoft Corporation. All rights reserved. Terms of Use. |