File system does not work after system reboot

[FrKaram]

From https://groups.google.com/forum/#!topic/winfsp/QgeBoADoJCI

Bug Report

After PC reboot, the drive is mounted but not accessible.
Message is : X:\ is not accessible. Incorrect function (translated from French, I do not know if it's the "official" english error message).
To solve the issue, I have to uninstall and reinstall winFSP.

How to Reproduce

Only happens on some PCs I do not own. I cannot reproduce.

Environment

Attached is WinFSP diag file.
diagResult.txt

[billziss-gh]

Thanks for the bug report. A couple of additional questions:

• Is the file system 64-bit or 32-bit (i.e. does it use winfsp-x86.dll or winfsp-x64.dll)?
• Is the file system a disk file system or network file system?
• How is the system being rebooted? Is "Fast Startup" being used?

[FrKaram]

• 32 or 64 ... euh, I do not know. I use winfsp-msil.dll
• It's a disk file system
• I'm guessing it's a shutdown + powerup with no special mode

I'll ask for more detail on monday

[billziss-gh]

Thanks. We will definitely need more information to resolve this.

• 32 or 64: I think the Task Manager should say whether a .NET app is running in 32-bit or 64-bit mode.
• It has been reported to me that this issue does not happen with a network file system.
• I had a report of this happening when "fast startup" is enabled.

I would love to get access to the machine that exhibits this problem, but I understand that it not under your control.

[FrKaram]

I've sent you an email

[thinkport]

@billziss-gh
I have this problem with Win7 32-bit and 64-bit mode, some computer, Winfsp doesn't work sometimes, reboot computer can solve this problem.

CreateFile returns INVALID_HANDLE_VALUE, error code ERROR_INVALID_FUNCTION, NtCreateFile returns STATUS_INVALID_DEVICE_REQUEST.

I can see Winfsp volume in the WinObj.exe, but can't see it in the FileSpy.exe.

    if (!DeviceIoControl(VolumeHandle, FSP_FSCTL_VOLUME_NAME,
        0, 0,
        VolumeNameBuf, (DWORD)VolumeNameSize,
        &Bytes, 0))
    {
        Result = FspNtStatusFromWin32(GetLastError());
        goto exit;
    }

The operation completes successfully, the return value is nonzero.

diag.txt

[billziss-gh]

@thinkport thanks for the diag report. I will study it and see if I can find something.

This problem has eluded me for a very long time. I have never been able to reproduce it. Any chance we can arrange for a remote desktop session or something like that so I can poke inside this computer?

If you find this possible feel free to ping me at my personal email address. BTW, I am in the Pacific time zone (Seattle, WA).

[billziss-gh]

One thing that I have noticed is that the few reports that I have always seem to come from localized versions of Windows (i.e. non-US). Perhaps this has something to do with where the problem is.

[billziss-gh]

@thinkport sorry for the multiple posts, but here is a list of questions and things for you to try when this fails again:

• This only happens with disk and not network file systems. Correct?
• Does the computer have Fast Startup enabled?
• What does the command fsptool-x64 lsvol report? (Fsptool is located in \Program Files\WinFsp\bin.)
• Does WinObj list \Device\WinFsp.Disk and also \Device\Volume{GUID} as reported by the lsvol command?
• Does WinObj list a correct drive symbolic link pointing to \Device\Volume{GUID} under \Sessions\x\DosDevices\00000000-xxxxxxxx? (You may have to look at multiple subdirs to find the drive.)
• If WinObj shows everything intact, please also check the security descriptor of the various symlinks/devices.
• What filter drivers do you see when you run fltmc?
• Does NtCreateFile fail with STATUS_INVALID_DEVICE_REQUEST when trying to open a file (e.g. root directory) on the target file system?
• Does FileSpy show the IRP_MJ_CREATE IRP sent to the WinFsp FSD from the NtCreateFile above?

I may add to this list in the future.

[thinkport]

@billziss-gh Unfortunately, they can't connect to the internet, I am not beside the computer now, I will answer all the questions on monday.

Does Win7 have Fast Startup? Fast Startup is a feature available from Windows 8. Quick Boot is a feature present in BIOS. Quick Boot?

[billziss-gh]

I think you are right about Fast Startup and Win7 not having it. I only mentioned it because it has been reported to me as potentially connected to this.

I will wait for your answers on Monday. Perhaps we can attempt to debug this via our discussion over GitHub issues.

[thinkport]

1. This only happens with disk and not network file systems. Correct?

I am not sure, I don't reproduce with network file systems.

2. What does the command fsptool-x64 lsvol report?

\Device\Volume{GUID}

3. Does WinObj list \Device\WinFsp.Disk and also \Device\Volume{GUID} as reported by the lsvol command?

Yes

4. Does WinObj list a correct drive symbolic link pointing to \Device\Volume{GUID} under \Sessions\x\DosDevices\00000000-xxxxxxxx?

Others are empty. My command: passthrough-x86.exe -p c:\programdata\test\a -m c:\programdata\test\b

5. If WinObj shows everything intact, please also check the security descriptor of the various symlinks/devices

Sorry, I don't know how I can do it. I compared symlinks/devices security property in the WinObj, There is no difference between normal and abnormal situations.

6. What filter drivers do you see when you run fltmc?

DocPrismService 2 141056 0
luafv 1 135000 0
FileInfo 3 45000 0

7. Does NtCreateFile fail with STATUS_INVALID_DEVICE_REQUEST when trying to open a file (e.g. root directory) on the target file system?

Yes

8. Does FileSpy show the IRP_MJ_CREATE IRP sent to the WinFsp FSD from the NtCreateFile above?

IRP_MJ_CREATE IRP returns status_reparse, but can't see WinFsp FSD.

[thinkport]

@billziss-gh By the way, DocPrismService is my miniFiter Driver, it redirects some files to WinFSP driver.

[thinkport]

I found something interesting, when WinFsp FSD doesn't work, I can't see WinFsp volume in the FileSpy, I use FileSpy feature ‘attach to a device by name', input the WinFsp volume name '\Device\Volume{GUID}', WinFsp FSD works immediately.

[thinkport]

normal

unormal

normal and unnormal

[thinkport]

I found the reason, the WinFsp virtual disk doesn't handle any IRP request from other file system driver, like FastFat.

FastFat code(from WinDDK File:fsctrl.c Function:FatMountVolume):

    Status = FatPerformDevIoCtrl( IrpContext,
                                  IOCTL_DISK_CHECK_VERIFY,
                                  TargetDeviceObject,
                                  NULL,
                                  0,
                                  &ChangeCount,
                                  sizeof(ULONG),
                                  FALSE,
                                  TRUE,
                                  &Iosb );

    if (!NT_SUCCESS( Status )) {

        if (!FlagOn( IrpSp->Flags, SL_ALLOW_RAW_MOUNT ) &&
            Vpb->RealDevice->DeviceType == FILE_DEVICE_DISK) {

            FatNormalizeAndRaiseStatus( IrpContext, Status );
        }

        return Status;
    }

I/O manager sends IRP_MN_MOUNT_VOLUME to FastFat file system, FastFat send IOCTL_DISK_CHECK_VERIFY to WinFsp virtual disk, WinFsp virtual disk returns STATUS_INVALID_DEVICE_REQUEST, FastFat returns STATUS_INVALID_DEVICE_REQUEST too, I/O manager doesn't attempt to ask other file system any more.

If the file system doesn't recognize disk device, the file system need returns STATUS_UNRECOGNIZED_VOLUME, I/O manager will attempt to ask other file system, like WinFsp.MSDN

WinFsp virtual disk can return STATUS_UNRECOGNIZED_VOLUME, I/O manager can work well in this case, but we can not ensure that other file systems can work properly. If WinFsp virtual disk returns STATUS_SUCCESS, WinFsp virtual disk need handles other IRP from other file system, like IOCTL_DISK_GET_PARTITION_INFO_EX, IOCTL_DISK_GET_DRIVE_GEOMETRY, etc.

Dokany handles very well. dokany

[billziss-gh]

@thinkport your work is fantastic, thank you. I will have to study it and see how we can fix this problem.

[billziss-gh]

BTW, any chance that you have steps to help me reproduce? It would be tremendous if I was able to study the problem on my equipment to determine the best course of action.

[thinkport]

MSDN

If the DO_LOW_PRIORITY_FILESYSTEM flag is set on the file system's control device object, the device object is inserted into the next-to-last position in the queue. (The RAW file system occupies the last position in the queue.) If this flag is not set, the device object is inserted at the head of the queue.

Change code

FspFsctlDiskDeviceObject->Flags |= DO_LOW_PRIORITY_FILESYSTEM;
IoRegisterFileSystem(FspFsctlDiskDeviceObject);

You can always reproduce now.

[thinkport]

WinFsp works because the control device object is inserted at the head of the queue, but this is not always the case.

[billziss-gh]

@thinkport your investigation has been invaluable. Thank you!

[thinkport]

I'm glad to be able to help.

[billziss-gh]

@thinkport I have tested this behavior using DO_LOW_PRIORITY_FILESYSTEM and have worked around it by returning STATUS_UNRECOGNIZED_VOLUME as per your suggestion. (I also understand the caveats that you present regarding the use of STATUS_UNRECOGNIZED_VOLUME and will see if there is a better way of doing this.)

I would like to add credit to you in the project source and changelog for your significant contribution. I can use @thinkport, but I can also use your real name if you prefer. Let me know.

[billziss-gh]

This change is now in both the master and release/1.4 branches. It should appear in the next v1.4 release. As such I am closing this.

[billziss-gh]

The latest release includes the fix for this issue:

https://github.com/billziss-gh/winfsp/releases/tag/v1.4B4