Error Reporting and Handling

Error Codes

On all supported platforms, errors are communicated using negative Unix/Linux system error codes (e.g., the absence of some file, normally indicated in Linux using the ENOENT error code, will be reported as -ENOENT and so on).

Reporting Errors to the Class from Event Handlers

If the event has a ResultCode parameter, the event handler can use it to return the result code of the operation to the class. The ResultCode parameter is set to 0 by default, which indicates the operation was successful. On all supported platforms, please use negative Unix/Linux system error codes to report errors.

Event handler functions should return a non-zero value only to indicate that an unexpected or catastrophic error prevented the event handler from executing properly. Doing this will likely disrupt further operations of the class. In the case of the "possible" errors (e.g. file not found, access denied), the actual return value of the event handler function must be 0 and only ResultCode should be set to the error code.

In some events, the OS doesn't expect the error code to be returned and either the class or the OS ignores the returned error code. Please, refer to the description of a particular event for more information.

How to Handle Errors Reported by the Class

The GetLastErrorCode and GetLastError functions can be queried to determine if an error occurred.

Extended Logging

Some class methods in CBFS FUSE are capable of writing extended information about reported errors to the Windows event logs, which can be viewed using the system's eventvwr.exe tool. The user mode part of the class writes to the "Windows Logs \ Application" folder, while the kernel mode part writes to the "Windows Logs \ System" folder.

The information written in the extended logs is meaningful to the Callback Technologies development team, but not to end-users, so extended logging is disabled by default. If issues occur during the installation of the CBFS FUSE system drivers, or while using the class, please do the following:

  1. Enable extended logging (see below).
  2. Replicate the issue.
  3. Using Event Viewer (eventvwr.exe), export the event log entries from the locations mentioned above in native format (please restrict the scope of the export to just those entries related to CBFS FUSE).
  4. Submit an issue report that includes the exported file.

There are two ways to toggle extended logging for a class:

  1. By toggling the class's LoggingEnabled configuration setting.
  2. By adding a DWORD-typed value named Enabled to the HKEY_LOCAL_MACHINE\SOFTWARE\CallbackTechnologies\{ClassName}\EventLog registry key and setting it to 0 (disabled) or 1 (enabled).
    • Replace the {ClassName} part of the registry key path with the name of the applicable class.
    • If this registry key, one of its parents, or the value itself does not exist, please create it manually.
    Note that if your code runs in emulated mode (x86 mode on x64 or ARM64 architecture), you need to add the value to the HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\CallbackTechnologies\{ClassName}\EventLog registry key in addition to the "main" registry key.

The system must be rebooted anytime extended logging is enabled or disabled to make the changes take effect.

Copyright (c) 2022 Callback Technologies, Inc. - All rights reserved.
CBFS FUSE 2020 Qt Edition - Version 20.0 [Build 8348]