Well, huh

But it is clear the error happened elsewhere :(

OK, the address of failure is DokanInstance->DokanOperations->Unmounted. Which makes sense since I'm running DokanNet on .NET 9, and if there was a CLR exception that causes CLR to stop, it could have unloaded jitted code. Although I am not sure about that. There are threads that seem to be executing CLR code at that time.

Hm

This sounds a little like dokan-dev/dokan-dotnet#370 Could you check and see if that helps ?

As I said, I believe it is because I dropped all references to a DokanInstance without disposing it. Holding on to it and disposing it explicitly before exiting seems to resolve the issue (it does not reproduce anymore).

But it should not be crashing regardless. My guess is that the main mistake is native Dokan code accesses .NET instance methods without holding a CLR reference directly or via a strong GCHandle. It should either hold a strong reference thus preventing finalization altogether or hold a weak reference and check if it is null on every call.

The native dokan2.dll only knows about function pointers. It has no knowledge of who "owns" these pointers, if they are actually .NET instance methods or a pointers to a native implementation or whether anything else needs to be "kept alive" to keep the function pointers valid. It has no references to .NET runtime at all. The caller (implementing library) needs to ensure that the function pointers supplied to the native DLL remain valid as long as the file system is mounted.

Therefore, if the implementation that calls the native dokan2.dll is a .NET library, it needs to hold a reference to the instance where methods are implemented, or allocate a GCHandle to that instance and free that when the file system is dismounted.

I'd argue https://github.com/dokan-dev/dokan-dotnet needs to take care of that.