How can I debug a crash inside dokan2.dll in a userspace program?

[lostmsu]

My FS crashes with access violation in dokan2.dll, so either bug in my implementation, or bug in Dokan userspace lib. How can I debug it? Is there any way to download symbols for dokan2.dll? I've got a crash dump and I can reproduce the issue consistently.

Can I build my own copy of dokan2.dll only for userspace (but keep kernel driver using the release)?

For the search engines: the error was 0xC0000005 "Access violation executing location"

[Liryna]

Hi @lostmsu ,

The dokan.zip of each release has the pdb next to each library for all architectures. You should be able to use it with the crash dump to symbolize the callstack. Please share it here!

[lostmsu]

Well, huh

But it is clear the error happened elsewhere :(

[lostmsu]

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.

[lostmsu]

Hm

[lostmsu]

I believe this happened because I let GC finalize DokanInstance in .NET

Probably can be considered a bug in .NET binding

Should be able to repro by dropping all references to an instance, and calling GC.Collect() and GC.WaitForPendingFinalizers().

[Liryna]

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

[lostmsu]

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.

[Olof-Lagerkvist]

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.

[lostmsu]

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