Error reporting and handling
Callback File System API operates with error codes defined by Win32 API. These error codes are listed in WinError.h header file in Windows Platform SDK.
If your application needs to report some error when processing the callback, it should throw ECBFSError exception (CBFSError in .NET) exception. The application must pass the error code with the exception by passing the error code as a parameter to ECBFSError constructor. Callback File System API will catch ECBFSError exception and extract the error code. The error code will be reported to the operating system.
Note that the error code reported by the callback is translated by Callback File System API to "NT Native" error code by the driver, which then passes this code to the OS. The OS performs opposite conversion of the error code to Win32 error code (the algorithm of this conversion is unknown and out of developers control). Due to lack of one-to-one mapping between NT Native error codes and Win32 error codes some codes can be converted incorrectly.
If some exception occurs when the callback is executed, the application must catch this exception and throw an instance of ECBFSError instead. If you don't catch some exception in your code, the API will catch it for you. But in this case it will report "Internal error" error to the OS, and this doesn't look well for the OS and for the user.
Methods of CallbackFileSystem class either return a boolean value of success or throw an exception (this depends on API used and details of function implementation). For functions that return the boolean value of success you can call GetLastError() Windows API function in VCL and C++ API or Marshal.Marshal.GetLastWin32Error (in System.Runtime.InteropServices) for .NET API. To handle exceptions you need to wrap your calls with try/catch (try / except) and handle any exception that is reported.
Several methods of CallbackFileSystem class (namely Install(), CreateStorage() and MountMedia() methods and Install function of the installer DLL) write extended information about the reasons of the reported error to Windows event log. User-mode part of Callback File System writes records to "Windows events \ Applications" folder of Windows event log. Kernel-mode part of Callback File System writes records to "Windows events \ System" folder of Windows event log.
The information written to the event log has meaning for EldoS Corporation developers, not for the users. So if you or your customers have problems with installing CBFS drivers, please export the event log records related to CBFS in native format and send us the resulting filefor analysis.
Since build 5.1.156 logging to system event log is disabled by default. In order to enable it you need to create the value "Enabled" of type "dword" in "HKEY_LOCAL_MACHINE\SOFTWARE\EldoS\EventLog" and reboot the system. To disable logging, delete the created "Eanbled" value from "HKEY_LOCAL_MACHINE\SOFTWARE\EldoS\EventLog".