RED_spring,wowocock,else等各位大侠，进来看一下！

本人在做98下的Filedisk，参考的是else提供的ramdisk，安装后，虚拟出来的磁盘是正确的，也就是那个大镜像文件也是正确的，但一对磁盘进行读写就死机，不知道为什么？

各位大侠给点建议？问题会出在哪里？有哪些地放要注意的？

跟踪一下嘛,执行到哪里死机

需不需要自己注册一个FSD来管理虚拟出来的磁盘？

你说的死机是什么现象？ 程序无反映，还是系统Crash掉了？

偶不是大虾。。。 偶是菜鸟呵呵。 :)

你说的死机是什么现象？ 程序无反映，还是系统Crash掉了？

偶不是大虾。。。 偶是菜鸟呵呵。 :)

你不是做过这个东东吗？
整个系统都没有反应了，只有reset机器了！

使机子处于这种状态的方法很多啊 :P

还是象snowStart说的那样跟踪一下吧。

[编辑 -  12/13/04 by  RED_spring]

我不知道你使用的这个例子是基于什么机制的，但是我知道的是9x的文件系统下，会有死锁，我记得本论坛好象有关于这个方面的描述

我是参考RAMDISK做的，机制一样，但对虚拟出来的磁盘，一写操作就死机！

用这种方法要注意什么？各位还有什么好的方法？

What are the rules for making an R0 read/write call from an IOS port driver?
Conventional IFSMGR_Ring0_FileIO typically will not work when called from within an IOS port driver if attempting to open and use a file located on a local (FAT) drive. This is because of the blocking that can occur in VFAT. VFAT uses IFSMGR_Block to serialize the use of FAT data structures (and to prevent VFAT data structure corruption due to reentrance). Also, there is a flag in VFAT called FullHold, which keeps track of the count of threads in VFAT and establishes a "full critical section" that is VFAT-global (not specific to a single drive letter). Attempts to perform IFSMGR_Ring0_FileIO fail (block) when called from a port driver because the original port request went through VFAT; the subsequent Ring0 file call is blocked by FullHold. However, success has been reported by developers outside of Microsoft in cases where the file is opened as a memory-mapped file under Windows 95 through Windows 98. With memory-mapped files, IFS Manager performs fewer tests for sharing violations. Therefore, you should set up a private memory-mapped file so it is not opened by any program other than yours. Also, all your I/O requests should be page (4K) aligned.

The following code, extracted from VWIN32, is used to read a memory-mapped file on behalf of Kernel32:

    mov    eax,R0_READFILE or (R0_MM_READ_WRITE shl 16) ; (eax) = read/write
    mov    al,byte ptr [function]        ; (al) = read (3f) or write(40)
    sub    al,3fh                ; (al) = read (0) or write (1)
    xor    ecx,ecx
    mov    edx,[fileloc]            ; (edx) = seek position
    mov    ecx,[cbLen]            ; (ecx) = number of bytes in i/o
    mov    esi,[memloc]            ; (esi) = transfer address
    VxDCall IFSMgr_Ring0_FileIO        ; do the i/o
    Trace_OutC    "ReadWritePage: error #EAX from file i/o"
Note that the R0_MM_READ_WRITE flag must be set for every I/O operation, not just when an attempt is made to open a file.

The following describes how PAGEFILE VXD opens the swap file (after it has been determined that the swap file can be safely accessed by 32-bit protected-mode drivers):

;    Open or Create the file

    mov    eax,R0_OPENCREATFILE            ; (eax) = open function code
    mov    bx,0110000010010010b            ; (bx) = flags: r/w, deny all,
                            ;    no inherit, no int 24,
                            ;    no caching
    xor    ecx,ecx                 ; (ecx) = attributes (nothing)
    mov    dl,00010001b                ; (dl) = open mode, open or create
    mov    dh,((R0_SWAPPER_CALL or R0_NO_CACHE or OPEN_FLAGS_NO_COMPRESS) SHR 8)
                            ; (dh) = special flags
    mov    esi, offset32 PF_Our_File_Name    ; (esi) = file name
    VxDCall IFSMgr_Ring0_FileIO            ; do the open  (eax) = handle
    jc    osf110                    ; jump if error

    mov    [PF_File_Handle],eax            ; save file handle
The original Windows 95 DDK did not mention that the flag bits need to be shifted right 8 positions. This shift is shown above. Read and write operations of the swap file are performed using normal R0_READFILE and R0_WRITEFILE functions, with no special flags set.

Here is a reportedly successful implementation of an IOS port driver that uses the above R0_MM_READ_WRITE Ring0_FileIo to access a local FAT file:

Open the file with the following flags: R0_OpenFile(R0_NO_CACHE | R0_MM_READ_WRITE)
CreateSemaphore()
VWIN32_CreateRing0Thread()
Set_Thread_Win32_Pri(16) - other values may work
Set a worker thread running:
Thread()
while not stop
Wait_Semaphore(BLOCK_THREAD_IDLE)
Dequeue IOP
Do R0 file I/O
Do CallBack
endwhile

The IOP Handler:
IOHandler(IOP)
if read or write
Enqueue IOP    
Signal_Semaphore()
return
endif

Also, the developer reported the need to do periodic forced volume flushes to the memory mapped file (virtual drive) when a long file is being copied to it. This is done using IFSMGR_InstallFileSystemApiHook. After write operations to the virtual volume, a data byte counter is incremented and direct calls to volume's flush function through its function table occur if the counter = 1Mb. Without this, the reading of the file from system volume slows down and would ultimately result in being locked up in Ring0_FileIo.

When R0_NO_CACHE is used, the system does not do any buffering during I/O. For example, the buffer address goes directly to the ESDI port driver.

How does Windows 95/98 itself use IFSMGR_Ring0_FileIo?
The following is an abbreviated analysis of how Windows 98's DriveSpace (DRVSPACX) accesses its host Compressed Volume Files (CVF's) located on the physical host volume.

DRVSPACX only uses the IFSMGR_Ring0_FileIo call when it is handling the AEP_MOUNT_NOTIFY event, in order to find and read the beginning part of all the CVF's (Compressed Volume Files) on a CVF host drive. This event is generated by IOS when IRS_MOUNT_NOTIFY is called. When performing these actions, there does not appear to be any special blocking or serialization going on.
Whenever DRVSPACX does use IFSMGR_Ring0_FileIO to read a CVF (see above), it uses the R0_READFILE_IN_CONTEXT flag.
For normal compressed volume file I/O, DRVSPACX sets up an IOP and performs direct sector I/O. DRVSPACX apparently automatically accounts for any fragmentation that the file may have on the disk, and has information about the starting sector for each CVF file.
A global search for IFSMGR_Ring0_FileIO across the Windows 98 source tree reveals the following:

DYNAPAGE.VXD still uses it. It appears to be used when creating, auditing, or resizing the swap file.
IOS uses IFSMGR_Ring0_FileIO during initialization when loading VxDs from the \system\iosubsys directory.
Q183173 BUG: IFSMGR_Ring0FileIO / Level 3 Volume Lock Conflict
There is a bug in IFS that affects VxDs that use IFSMGR_Ring0_FileIo. The corresponding Knowledge Base article (Q183173) is reproduced below. Use the online Knowledge Base to check for later potential updates to this article.

See the Knowledge Base article "BUG: IFSMGR_Ring0FileIO / Level 3 Volume Lock Conflict" for more information.

The information in this article applies to the Windows 95 Device Driver Kit (DDK), version 4.0.

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. For example, a file opened as ACCESS_READ_WRITE does not work after you run DEFRAG. After you run DEFRAG, the file attributes erroneously change to ACCESS_WRITEONLY.

Cause
There 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 reopened. When the file is reopened, the file access mode is erroneously set up with the contents of the file action type. For example, a file opened as follows:

  mov     esi, OFFSET32 R0_szFileName
  mov     ebx, ACCESS_READWRITE    ; 0x0002
  xor     ecx, ecx
  mov     edx, ACTION_OPENEXISTING ; 0x0001
  mov     eax, R0_OPENCREATFILE
  VxDCall IFSMgr_Ring0_FileIO
is reopened with the contents of EDX appearing in EBX. When appearing in EBX, the value ACTION_OPENEXISTING (0x0001) corresponds to ACCESS_WRITEONLY (0x0001).

Resolution
When the level 3 volume lock is released, it reopens 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 detects 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.

Status
Microsoft 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.

References
Windows 95 Device Driver Kit

Win9x 的这些老东东，很少有人感兴趣了。 只是偶尔能用的到。

多谢了！

这些东东从哪里找到的？我在MS　的MSDN上搜了好久也没找到！

在MSDN里搜索 IFSMGR_Ring0FileIO 。

“勤用搜索”， ZN老大的话。 嘿嘿。 :)

在MSDN里搜索 IFSMGR_Ring0FileIO 。

“勤用搜索”， ZN老大的话。 嘿嘿。 :)

谢谢！找到了！为什么我用在线的MSDN总是搜不到呢？最后还是在我的DDK里找到的！