When a problem does occur, we need good data with which to work so we can fix the problem expeditiously. We need to know the specific versions of the OS, including updates. We need to know everything that’s running on the systems where the problem is being observed, and the versions of any third-party file system related products.
Also, we will always need problems described to us in terms of observed and expected behaviors at the Windows file system level. It will almost never be enough to say, “we have a client who can’t copy a file to a share on a server where FESF on the server is set to encrypt the file.” Of course, if that’s all you have, we’ll take it. But what we really need is an analysis of the behavior. What particular file system operations are failing? What errors are reported? A ProcMon trace can go a long way towards collecting this information. See Appendix B of the FESF Solution Developers’ Guide for details about getting useful ProcMon traces.
We usually will also need one or more Windows crash dumps taken when the problem is being experienced. This has been, is now, and will always be the gold standard for documentation.
In FESF V1.6, we introduced a new and very comprehensive internal logging feature as well. You are now able to enable and collect these logs, with minimal performance impact, from running customer systems without rebooting. We expect this logging feature to help us quickly diagnose interoperability issues.
Recommended Strategy: When you experience an interoperability issue, collect as much relevant data for us as you can up front. Always send us a description of the behaviors you’re seeing at the Windows file system level. Send us multiple crash dumps.