OSFMount 3.1 caused a bugcheck on Windows 11 25H2

[Simon (PassMark)]

Was able to reproduce, fixed with build 3.2.1001

[Ajaja]

We have released new build of OSFMount to try and fix the bug:
https://www.osforensics.com/tools/mo...sk-images.html

OSFMount.com does not work in this new version.

c:\Program Files\OSFMount>OSFMount.com -a -t vm -s 4G -o mbr,format:ntfs:RAMDISK
The version of the OSFMount Driver (V1.1.0000) installed on this system is not compatible with the version of this control program (V1.1.0000). Please reinstall OSFMount to make sure that all components of it on this system are from the same install package. You may have to restart your computer if you still see this message after reinstalling.

c:\Program Files\OSFMount>OSFMount.com --version
PassMark OSFMount Command Line Interface.
Version V3.1 (Build 1003) - (Compiled Aug  7 2026)​
...

[Simon (PassMark)]

We have released new build of OSFMount to try and fix the bug:
https://www.osforensics.com/tools/mo...sk-images.html

[daria22]

That's great to hear, thank you for the update. I really appreciate you tracking this down. Just let me know when a test build is ready and I'll be happy to try it out on the affected workstation and report back.

[keith]

Just an update - we made a possible fix to the driver. We'll let you know once we have a build for testing.

[SundayDIY]

Thank you very much for looking at the crash dump and for getting back to me. I will monitor the thread for updates.

[David (PassMark)]

Thanks for sending in the dump file.

Based on the details in the dump, we found a possible bug where we are zeroing a Storport (storport.sys) supplied buffer when the address of the buffer might no longer be valid. Which would mean our driver is writing to an invalid memory address, But at this point we aren't sure if A) it is a real bug and B) it was this bug that caused the behavior you saw.

So we'll have a go at reproducing your problem, then see if the code change fixes it. It might take a few days.

[SundayDIY]

I emailed a link to a downloadable compressed memory dump in 7z format.

[David (PassMark)]

Crash dumps don't always help, but we would take a look at it.

If you can zip it up and if small enough Email it to us.

Otherwise upload it to a shared cloud drive and we can download it.

[SundayDIY]

I am willing to provide a crash dump now after doing a fresh Windows 11 reinstall on the affected workstation. Please let me know what steps to take to provide it to you.

[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.

[SundayDIY]

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

[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.

[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]

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.