OSFMount 3.1 caused a bugcheck on Windows 11 25H2

[SundayDIY]

The OFSMount driver osfdisk.sys caused a bugcheck on me on Windows 11 during a large file transfer from a mounted volume.

OSFMount 3.1 (1003)
Windows 11 Pro for Workstations 25H2 build 26200.8457.

Using Arsenal Image Mounter on the same system with the same virtual disk image does not cause a bugcheck. So it's something specific to OSFMount.


SYMBOL_NAME: osfdisk+a8938

MODULE_NAME: osfdisk

IMAGE_NAME: osfdisk.sys

STACK_COMMAND: .process /r /p 0xffffe58dbbac8040; .thread /r /p 0xffffe58e48cf24c0 ; kb

BUCKET_ID_FUNC_OFFSET: a8938

FAILURE_BUCKET_ID: AV_osfdisk!unknown_function

[David (PassMark)]

Isn't really enough information to do much about this.

Totally possible this is a hardware fault.

Did it happen more than once, and was it non random (i.e. always crashed at the same point in the same file).
What were all the settings used in OSFMount?
How large was large?

Somewhat of a generalization, but random faults are more likely to be hardware and reproducible faults are more likely software.

[SundayDIY]

I was too afraid of another bugcheck to continue using the product, so I switched to Arsenal after that initial bugcheck. The system has been rock solid other than the one bugcheck when running OSFMount. Furthermore, I've tested the storage, the RAM (which is ECC) and CPU. ASPM is disabled to avoid any potential power management interference.

Would a full log from WinDBG help your device driver developer? I would not be able to send the crash dump, but I am happy to share the full "analyze -v" output which has the call stack and a bunch of other useful information.

I can try to reproduce the issue again, but I think it would be good for your driver developer to have a look at the WinDBG output which I am happy to send over. It may prove to be useful.

I don't recall the exact settings used, unfortunately. I will have to give it another try and attempt to reproduce the issue.

OK, as I'm writing this I was able to reproduce it again.

Virtual disk file mounted: C:\Users\user\Documents\Virtual Machines\Clone of tw_btrfs_lvm_cleanslate1 (2)\backups-cl1.vmdk
Mount as RAM drive NO
Mount entire image as virtual disk: YES
Removable Media: YES
Read only: YES
Physical disk emulation: YES
Drive type: HDD

system-root.btrfs-ptcl-img.gz.aa --> open with 7zip and attempt to extract --> bugcheck
File size is 3.40 GB (3,658,496,003 bytes)
Also just trying to copy the file leads to a bugcheck.

The virtual disk is from vmware workstation 26H1. No snapshots involved (though it did have a snapshot previously which I removed using the VMWare GUI, as I suspected the snapshot to be causing the issue). The virtual disks contains a single ExFAT volume and on it are a couple of backups made using clonezilla and rescuezilla.

VMWare is able to operate with the virtual disk fine, so I don't believe it's corrupted. 7zip is able to extract the extfat partition too. Running "vmware-vdiskmanager.exe -R" did not produce any output, so presumably it did not find issues. I've also cloned the vmdk to another new vmdk and tried to mount the new vmdk and, upon trying to read that same file mentioned above, it bugchecked too.

Hope this helps.

[David (PassMark)]

the call stack

Stack trace can help sometimes, but without the symbols, it might just be a bunch of hex values. Which won't help.
So the actual dump file would be more useful. But even then we find dump files only help maybe 30% of the time.

From the name of the folder, Clone of tw_btrfs, would I be right to assume this is a "btrfs" file system Linux VM?

Windows doesn't offer any support for the btrfs file system. So it is kind of surprising that you were even able to see any files in the image to even start a copy operation? (no excuse for it crashing however, it should never crash, it should fail politely)

[SundayDIY]

You can ignore the name of the folder. The btrfs system is on another virtual disk. The virtual disk that was causing issues is a simple GPT layout with a single EXFAT partition. I was using rescuezila/clonezilla to back up the btrfs system to this EXFAT drive, which is what created the "system-root.btrfs-ptcl-img.gz.aa" file. I was actually troubleshooting a potential bug in rescuezila/clonezilla when the bugcheck occurred during my workflow. It was all done a little bit in a haste, and the naming is a bit unfortunate. But the vmdk in question does not have anything that Windows should have a problem with (which is why, I think, Arsenal mounts it without an issue).

I understand that the dump file would likely be more useful, but I am concerned about potential privacy implications of sending off a memory dump. I was hoping that the full WinDBG analysis might be of some value. I would also be happy to run a debug build of the driver if that helps and if it's something you are OK with releasing.

[SundayDIY]

Hi, just following up. Is this something that you will be looking at?

[David (PassMark)]

We have only had one report of this issue. VMDK images aren't often used with OSFMount and we also can't rule out is a hardware problem and don't have crash dumps, etc... So isn't our highest priority at the moment.

The issue is in our internal bag tracking system to look at eventually however (Ticket 0000761).

If anyone else has this problem, please post here. If we get a few people finding the same issue we'll bump up the priority.