My drivers breaks VSS somehow

So with my driver just loaded, VSS (Volume Shadow) appears to stop working, for example;

Before driver:

Writer name: 'System Writer'
   Writer Id: {e8132975-6f93-4464-a53e-1050253ae220}
   Writer Instance Id: {d99b7b4a-caad-4711-bc72-bf27147c5f05}
   State: [1] Stable
   Last error: No error

After

Writer name: 'System Writer'
   Writer Id: {e8132975-6f93-4464-a53e-1050253ae220}
   Writer Instance Id: {d99b7b4a-caad-4711-bc72-bf27147c5f05}
   State: [10] Failed
   Last error: Timed out

Just the first one that times out, a few after do as well. If I run FileSpy.exe;


VSSVC.exe	IRP_MJ_CREATE	\Device\ZFS{0b1bb601-af0b-32e8-a1d2-54c167af6277}	STATUS_SUCCESS	FILE_OPEN CreOpts: 00000060 Access: 00120089 Share:  00000003 Attrib: 00000080 Result: FILE_OPENED
VSSVC.exe	IRP_MJ_FILE_SYSTEM_CONTROL/IRP_MN_USER_FS_REQUEST	\Device\ZFS{0b1bb601-af0b-32e8-a1d2-54c167af6277}	STATUS_NOT_SUPPORTED	FSCTL_QUERY_DEPENDENT_VOLUME (000901F0)
VSSVC.exe	FASTIO_QUERY_BASIC_INFO		\Device\ZFS{0b1bb601-af0b-32e8-a1d2-54c167af6277}	STATUS_SUCCESS	FileBasicInformation CreateTime: 01DB1533-C11CA5CD LastAccTime: 01DB1533-C11CA5CD LastWrtTime: 01DB1533-C11CA5CD ChangeTime: 01DB1533-C11CA5CD Attrib: 00000010
VSSVC.exe	IRP_MJ_CLEANUP	\Device\ZFS{0b1bb601-af0b-32e8-a1d2-54c167af6277}	STATUS_SUCCESS	
VSSVC.exe	IRP_MJ_CLOSE	\Device\ZFS{0b1bb601-af0b-32e8-a1d2-54c167af6277}	STATUS_SUCCESS	
svchost.exe	IRP_MJ_CREATE	\Device\ZFS{0b1bb601-af0b-32e8-a1d2-54c167af6277}	STATUS_SUCCESS	FILE_OPEN CreOpts: 00000060 Access: 0012019F Share:  00000003 Attrib: 00000080 Result: FILE_OPENED
svchost.exe	FASTIO_DEVICE_CONTROL	\Device\ZFS{0b1bb601-af0b-32e8-a1d2-54c167af6277}	FAILURE	IOCTL_VOLSNAP_QUERY_NAMES_OF_SNAPSHOTS (00530018)
svchost.exe	IRP_MJ_DEVICE_CONTROL	\Device\ZFS{0b1bb601-af0b-32e8-a1d2-54c167af6277}	STATUS_NOT_SUPPORTED	IOCTL_VOLSNAP_QUERY_NAMES_OF_SNAPSHOTS (00530018)
svchost.exe	IRP_MJ_CLEANUP	\Device\ZFS{0b1bb601-af0b-32e8-a1d2-54c167af6277}	STATUS_SUCCESS	
svchost.exe	IRP_MJ_CLOSE	\Device\ZFS{0b1bb601-af0b-32e8-a1d2-54c167af6277}	STATUS_SUCCESS	
SrTasks.exe	IRP_MJ_CREATE	\Device\ZFS{0b1bb601-af0b-32e8-a1d2-54c167af6277}	STATUS_SUCCESS	FILE_OPEN CreOpts: 00000060 Access: 00120089 Share:  00000003 Attrib: 0 Result: FILE_OPENED
SrTasks.exe	FASTIO_DEVICE_CONTROL	\Device\ZFS{0b1bb601-af0b-32e8-a1d2-54c167af6277}	FAILURE	IOCTL_MOUNTDEV_QUERY_UNIQUE_ID (004D0000)
SrTasks.exe	IRP_MJ_DEVICE_CONTROL	\Device\ZFS{0b1bb601-af0b-32e8-a1d2-54c167af6277}	STATUS_INVALID_DEVICE_REQUEST	IOCTL_MOUNTDEV_QUERY_UNIQUE_ID (004D0000)
SrTasks.exe	IRP_MJ_CLEANUP	\Device\ZFS{0b1bb601-af0b-32e8-a1d2-54c167af6277}	STATUS_SUCCESS	
SrTasks.exe	IRP_MJ_CLOSE	\Device\ZFS{0b1bb601-af0b-32e8-a1d2-54c167af6277}	STATUS_SUCCESS	

Not sure if has some other way of communicating with the driver, but those are the IRPs that I receive on my mounted filesystem.

It's not that I want to participate with VSS, but I certainly don't want it to no longer work just because my driver is loaded. What is it that it checks that times out?
Did I somehow claim my driver supports it? My reply to FileSystemAttributes looks harmless.

chatgpt is more useless than usual.

The usual thing to do is to see what it does on NTFS? But off the top of my head failing IOCTL_VOLSNAP_QUERY_NAMES_OF_SNAPSHOTS doesn't look good.

However this sounds like you are a file system and I have a suspicion that there is a great deal of hidden handshaking between the FSD and Volsnap. I guess I'd start with seeing what FAT does. Then at least you have scrutability.

That's just it though, both fastfat (and winbtrfs) do not have code for IOCTL_VOLSNAP_QUERY_NAMES_OF_SNAPSHOTS. Searching for it on GH, there is only one hit (on the kernel side of things) in ramdisk.c, which just return error.

So if they (presumably) do not break VSS by not having those handlers, why would my driver need them? What is it that I do that excites VSS in the first place.
I suspect Windows also decides on the VSS situation quite early on when my driver loads, not after I have something mounted. VSS is broken without me having anything mounted after all. That does mean I can not use FileSpy to see what is going on there.

It is surprisingly little documentation on VSS (with regards to filesystem drivers).

I set

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\Settings]
"Timeout"=dword:0000EA60  ; (Decimal value 60000, which is 60 seconds)

and vssadmin list writers no longer complain. So maybe it was just running a bit slow with debug, and verifier attached.

Sadly, there is more to it. Even though I can at least get past "vssadmin list writers", if you try to do a command like

chkdsk /scan C:

Even with just my driver loaded, not other filesystems around it will fail. For some reason it decides that my driver should participate with VSS interactions. I do not want to, or rather, I don't want things to break just because my driver is loaded. There is not much information out there on VSS.

PS C:\Windows\system32> chkdsk /scan C:
The type of the file system is NTFS.
The shadow copy provider had an error. Check the System and Application event logs for more information.

A snapshot error occured while scanning this drive. You can try again, but if this problem persists, run an offline scan and fix.