WiseFs64.sys denies directory enumeration on a locked folder with no way to recover while the driver is loaded

[kgursu]

Wise Care 365 version: 8.0.5.733 PRO
OS: Windows 10 22H2, build 19045.7663
Driver: C:\Windows\WiseFs64.sys, FileVersion 3.1.1.433, file date 2026-01-04
Also installed: Wise Folder Hider 5.11.244

SUMMARY

A folder on my system is being denied by WiseFs64.sys in a way that gives no indication of
what is blocking it. Standard Windows diagnostics all report the folder as healthy,
different APIs return different and contradictory errors, and the only way I found to
regain access was to disable the filter driver in the registry and reboot.

I was unable to find the rule that causes this. The folder is not listed in any Wise
application UI I could open, and an exhaustive search of the file system and registry found
no stored reference to it. Details are in the section on rule storage below.

SYMPTOM

The folder E:\kerem\Desktop\Programlama appears in its parent directory listing but its
contents cannot be enumerated.

    dir /a "E:\kerem\Desktop\Programlama"
    -> "File Not Found", with no "." or ".." entries listed

    [System.IO.Directory]::EnumerateFileSystemEntries("E:\kerem\Desktop\Programlama")
    -> UnauthorizedAccessException

Two different APIs report two different failures for the same folder. Neither message
points to an access-control product, so the natural reading is file system corruption.

WHAT WAS RULED OUT

icacls          MINIPC\kerem has Full Control, both explicit and inherited. No DENY ACE.
attrib          returns no flags. Not hidden, not system, not read-only.
fsutil          "not a reparse point". Not a junction or symlink.
Get-Item        Attributes = Directory only. No encryption flag.
chkdsk E: /scan 0 bad file records, 0 unindexed files, index verification clean,
                "Windows has scanned the file system and found no problems"
whoami /groups  BUILTIN\Administrators enabled, session is elevated

The folder entry itself is present in the parent directory. Comparing full recursive
listings taken with the driver disabled and enabled showed the folder path present in both;
only its 15 child entries disappear when the driver is loaded.

PROCESS MONITOR

    Operation:              QueryDirectory
    Result:                 ACCESS DENIED
    Path:                   E:\kerem\Desktop\Programlama\*
    Duration:               0.0000261
    FileInformationClass:   FileFullDirectoryInformation

Call stack (symbols not loaded, nearest-export names):

    0   FLTMGR.SYS
    1   FLTMGR.SYS
    2   FLTMGR.SYS
    3   FLTMGR.SYS
    4   ntoskrnl.exe   IofCallDriver
    5   ntoskrnl.exe
    6   ntoskrnl.exe   NtQueryDirectoryFileEx
    7   ntoskrnl.exe
    8   ntdll.dll      NtQueryDirectoryFileEx
    9   KERNELBASE.dll FindFirstFileExW
    10+ cmd.exe

Two observations. Ntfs.sys does not appear in the stack, so the request is completed inside
the filter manager and never reaches the file system. The failing operation is
QueryDirectory, not CreateFile, so the directory handle was opened successfully and only
the enumeration is refused. The 26 microsecond duration is consistent with a preoperation
callback completing the request immediately.

IDENTIFYING THE DRIVER

fltmc filters listed six third-party minifilters. Process Monitor installs at altitude
385200 and observed the operation, which excludes every filter above that altitude
(bindflt 409800, mbamchameleon 400900, ngscan 389310, UCPD 385250.5). WiseFS at 370051 is
the highest remaining candidate.

Detaching it is refused:

    fltmc detach WiseFS E:
    -> detach failed with error: 0x801f0010   (STATUS_FLT_DO_NOT_DETACH)

Turning off protection from the application UI has no effect on the driver. After doing so,
fltmc instances -f WiseFS still reported all 8 instances attached, including E:.

The only method that worked:

    reg add "HKLM\SYSTEM\CurrentControlSet\Services\WiseFS" /v Start /t REG_DWORD /d 4 /f
    (reboot)

After the reboot the folder was fully accessible. No other change was made, which isolates
WiseFs64.sys as the source.

WHERE THE RULE IS STORED: NOT FOUND

Since the UI could not be opened, I tried to locate the rule that causes the denial. I did
not find it anywhere a user can inspect.

Searched, no match for the folder name or its full path:

    HKLM\SYSTEM\CurrentControlSet\Services\WiseFS and all subkeys
      contains only the standard minifilter registration: ImagePath, Altitude 370051,
      Flags 0x0, SupportedFeatures 0xf. No path list.
    %APPDATA%\Wise Folder Hider\Config.ini
      diskPath is empty, Encrypt=0, no path entries at all
    %APPDATA%\Wise Care 365\  (all files, ASCII and UTF-16 byte scan)
    %LOCALAPPDATA%
      no Wise directories exist
    C:\Program Files (x86)\Wise\ and C:\Program Files\Wise\  (all files, recursive,
      ASCII and UTF-16 byte scan)
    HKLM, HKCU, HKU, HKCR searched for both the folder name and the full path,
      in key names and value data

C:\Program Files (x86)\Wise\Wise Care 365\protect.db looked like the obvious candidate by
name, but its last write time is 2024-04-18, while the affected folder was created
2026-07-24 and the driver file dates from 2026-01-04. The folder's NTFS object ID
(8e7b62f7f72ef0118cd0d8c0a62fca84) does not appear anywhere in that file either.

I also checked whether the folder is tracked by object ID rather than by path. It is not
distinctive: 19 of the 20 folders in the same parent directory carry an object ID, so the
IDs come from normal Windows link tracking, not from your product.

The practical consequence is that a user who cannot open the UI has no way to find out what
is blocking the folder, no way to release it, and no way to confirm the rule even exists.

WHY THE UI COULD NOT BE USED

The Wise Care 365 main window could not be opened to manage the protection entry, because
of the window placement bug reported separately: maximizing on a secondary monitor with a
negative X origin puts the window outside the virtual desktop, with no taskbar button and
no Alt+Tab recovery.

The two defects compound. When the UI cannot be reached, the driver keeps enforcing the
lock, and there is no supported way to release it. A user without kernel-level
troubleshooting experience would conclude the folder is corrupted.

For completeness: folders hidden through Wise Folder Hider behave differently on this
system. They disappear from the parent directory listing entirely, including on the
desktop. The affected folder stays visible and only refuses enumeration, which suggests a
different code path. Reinstalling the current version of Wise Folder Hider did not change
the behaviour.

REQUESTS

1. Make the denial identifiable. Returning ACCESS DENIED with no indication of the source
   is indistinguishable from file system damage. Consider an entry in the application log
   recording which path was refused and when.

2. Provide a recovery path that does not require the GUI. A command-line utility, or a
   documented procedure to list and release protected entries, would avoid the registry
   workaround entirely.

3. Tell me where the rule lives. If WiseFs64.sys is enforcing a rule I cannot find in any
   file or registry key, and the folder is not shown in any product UI, then either the
   storage location is undocumented or the rule is stale and no longer has a matching
   entry. Both cases are worth investigating.

4. Document the shadow copy attachment behaviour. fltmc instances -f WiseFS shows the
   driver attached to \Device\HarddiskVolumeShadowCopy4 and
   \Device\HarddiskVolumeShadowCopy7. In my case a backup taken with Acronis True Image
   was able to read the protected folder and its contents, so the denial does not apply
   to that path. This is the desirable outcome for data safety, but it also means
   protected content is readable from a backup image, which users may not expect from a
   feature presented as protection.

5. Correct the driver version metadata. WiseFs64.sys reports FileVersion 3.1.1.433 with
   ProductVersion 1.0.0.1 and an empty CompanyName. The file is also installed directly in
   C:\Windows rather than C:\Windows\System32\drivers, which is unusual for a kernel driver
   and complicates identification.

SCOPE OBSERVED

Comparing recursive listings before and after re-enabling the driver:

    E drive:   1 folder affected, 15 shortcut files inside it
    C drive:  no protected entries (all differences were transient log and telemetry files)
    F drive:   no differences
    P drive:   not tested (network drive)

I can reproduce this on demand and test a build.

[Lily]

Thank you for your very detailed feedback. I have reported it to our development department. Once there is a reply, I will inform you promptly.

[Lily]

We've got a possible solution. 

Run Command Prompt as Administrator, then enter:

sc stop wisefs

This stops the WiseFs driver. After the driver is stopped, the affected folder and its files should become accessible and can be operated normally again.

[kgursu]

Yes, we (me and my AI companion) know that. Would there be a fix in the future? 

[Lily]

When WiseFs runs, the files you hided are not allowed to open. So there won't a "fix".

Did you get any error code when this happens?

[kgursu]

I don't think I did hide this directory or can control its hiding mechanism anywhere, maybe accidentally this can occur, but there is no clue to do that inside the menus of Wisecare 365 or even on Wise Folder Hider. 

[Lily]

Perhaps a reinstallation might be helpful.