RAM FS hangs when manually mounting a disk

RAM File System 2.8.1 hangs when manually mounting a disk.

I create a 512MB disk. Then I wait a few minutes and then unmount/mount it in the interface. The program hangs, and so does Windows. I'm doing this on a VMWare virtual machine with 8GB of memory, Windows 10 22H2 10.0.19045.6456. If I do the same with RAM Disk 26.7, there's no hangs.

Thank you for the report - the detail that RAM Disk 26.7 is fine on the same machine was particularly useful.

We could not reproduce it here: on a VMware virtual machine running Windows 10, a 512 MB volume left idle for several minutes and then unmounted and remounted completed in well under a tenth of a second every time, empty or populated. So something on your machine appears to be involved, and we would like to identify it.

One difference is relevant. RAM Disk presents an ordinary NTFS volume, whereas RAM File System is itself a file system, so security, backup and virtualisation software attaches to its volumes differently - and our mount waits for Windows to finish mounting before it returns. A third-party filter driver that is slow when the volume appears would delay the mount, which would explain why only RAM File System is affected.

Next time you can reproduce it, could you try two things?

1. Open RAM File System Console from the Start menu and run:

ramfsctl create R 512M

Does it complete immediately, or does it freeze the way the interface does?

2. In the same window:

fltmc filters > %USERPROFILE%\Desktop\filters.txt

and attach the resulting file - it lists the components that attach to our volumes.

It would also help us to know whether the machine recovers on its own after a minute or two, and how many processor cores the virtual machine has.

ramfsctl create R 512M

It freeze the way the interface does.

fltmc filters > %USERPROFILE%\Desktop\filters.txt

Filter Name                  Number of Copies     Height    Frame
---------------------------- ----------------- ------------ -----
bindflt                                 0       409800         0
SIFSDI                                  6       401950         0
FSRegFlt                                6       389110         0
UCPD                                    6       385250.5       0
CSAgent                                 8       321410.77715   0
storqosflt                              0       244000         0
wcifs                                   0       189900         0
CldFlt                                  0       180451         0
FileCrypt                               0       141100         0
npsvctrig                               1        46000         0
Wof                                     3        40700         0
FileInfo                                6        40500         0

The virtual machine won't recover. Only a reboot helps. 4 processor cores.

Thank you - that narrows things down a great deal.

At this point the fastest way for us to fix this is to see the failure ourselves. We have been unable to reproduce it on any of our machines, and your filter list shows why: your system runs three third-party file system filters (CrowdStrike Falcon, what appears to be Flexera software-management, and one we cannot identify), while ours run none. Since RAM File System is itself a file system, those filters attach to it in a way they never do with RAM Disk, and one of them appears to be blocking while the volume is being mounted.

Two ways forward, and the first would be far more useful if it is possible for you.

1. A copy of the virtual machine. Since this is a VMware virtual machine, and it reproduces the problem reliably, a copy of it would let us debug the fault directly instead of guessing from the outside. We would only ask for this if your machine contains no confidential, personal or business data - for example if it is a scratch test system you built for evaluation.

If that is possible, let us know and we will send you a private upload link. The files compress well, and we would use the copy solely to investigate this fault and delete it once the matter is resolved.

2. Otherwise, a memory dump taken while it is frozen. Run these two commands in an admin command prompt and restart the virtual machine:

reg add HKLM\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters /v CrashOnCtrlScroll /t REG_DWORD /d 1 /f
reg add HKLM\SYSTEM\CurrentControlSet\Services\kbdhid\Parameters /v CrashOnCtrlScroll /t REG_DWORD /d 1 /f

Then reproduce the freeze, and while it is frozen hold the right-hand Ctrl key and press Scroll Lock twice. Windows will stop with a blue screen and write C:\Windows\MEMORY.DMP. Please upload that file and send us a link - it will show us precisely which component is stuck and what it is waiting for.

Lastly, whichever route you take, it would help to identify that third filter. In the same console:

sc qc SIFSDI

If it returns nothing, right-click C:\Windows\System32\drivers\SIFSDI.sys, choose Properties, and the Details tab will show the company and product name.

Thank you for your cooperation - the problem is clearly real, and with either of the above we should be able to pin it down.

Unfortunately, I cannot send a copy of the virtual machine, since I only have remote access to it.

I also can't do a memory dump because the Ctrl + Scroll Lock + Scroll Lock combination doesn't work through the RDP.

The C:\Windows\System32\drivers\SIFSDI.sys file does not exist. I was only able to disable CrowdStrike Falcon antivirus, but that didn't help either.

First of all, our apologies - we know this has already taken a good deal of your time. We would not do so if we had been able to identify the fault.

We took your report very seriously and build a test machine around it. Since your system runs security software that ours do not, we installed four different products in turn and repeated your exact sequence with each. Between them they cover every layer of the filter stack from your list, including the topmost one occupied by SIFSDI:

• ESET Internet Security — filter at layer 328700, alongside where CrowdStrike sits
• Bitdefender Total Security — six filters at 320770–320832
• Avast Free Antivirus — filters at 137600, 320700 and 388401, next to your FSRegFlt
• Malwarebytes — filter at 400900, the same layer as your SIFSDI

In each case we confirmed the security software attached itself to our volume, and in each case the mount finished in under a tenth of a second. Two of those products replaced Windows Defender exactly as CrowdStrike does on your machine. We could not make it freeze once - which is frustrating for us, and unfortunately means we cannot find this from our side alone. It does fit with your own finding that disabling CrowdStrike changed nothing.

That points to something specific to your machine, so we would be very grateful if you could run the tests below. Each takes about two minutes and needs nothing installed. Please reboot first and use RAM File System Console from the Start menu. If the disk reappears on its own after the reboot, unmount it before starting. If you only have time for one test, please make it Test B.

Test A - does a mount work at all?

ramfsctl create R 512M

Please note whether this completes, before running anything else. Then:

ramfsctl dismount R
ramfsctl create R 512M

Does the second one freeze, with no waiting involved?

Test B - a different drive letter (the one we deeply wish you can try)

ramfsctl create R 512M
ramfsctl dismount R
ramfsctl create S 512M

If S: mounts instantly while R: freezes, then the fault is in RAM FS — its reuse of the drive letter — and your security software is not involved at all.

Test C - with the wait, as you originally described

ramfsctl create R 512M

Wait a few minutes, then:

ramfsctl dismount R
ramfsctl create R 512M

Test D - Safe Mode
Start the machine in Safe Mode with Networking (Remote Desktop works there, and third-party filters are not loaded) and repeat Test A.

And whenever convenient, three small commands:

fltmc filters
driverquery /v /fo csv > "%USERPROFILE%\Desktop\drivers.csv"

Please run the first while CrowdStrike is disabled. Most security products keep their filter loaded even when the product is switched off, and if that is the case here it would explain why disabling it made no difference.

The second writes a complete list of every driver on the machine to your Desktop, including the file path of each. If you could attach that file, it should tell us what SIFSDI is and where it lives - it is not in the drivers folder where we expected it, and it is not a component we recognise. It will also show us anything else on that system we have not accounted for.

There is also a small batch file attached, which writes a list of installed programs to your Desktop. If you can run it and send us the result it would help us work out which product SIFSDI belongs to - it is not a component we recognise.

What happens next

Whichever way the results come out, they tell us where to go, and we will take it from there rather than coming back to you repeatedly:

• If Test B works (S: mounts while R: freezes) - the fault is in our own handling of a reused drive letter. We would fix it and send you a corrected build to confirm.
• If Test D works (Safe Mode is fine) - the interaction with your security software is confirmed. We would look at what we can change on our side to avoid it, and approach the vendor with the specifics.
• If everything still freezes - we will prepare a special build that records how far the mount gets before it stops, and writes that to a file. That would give us what a memory dump would have told us, without needing one.

Thank you again for your patience. The tests above should tell us in a few minutes what a full day of testing here could not. It's better to send us all the details in a private ticket here.