Error Reporting and Handling

Error Codes

The CBFS Vault class APIs communicate errors using the Win32 error codes defined in WinError.h, which is part of the Windows Platform SDK. The CBFS Vault system drivers, however, use NT native error codes, which don't have one-to-one mappings with Win32 error codes. The class includes logic for converting between the two as necessary, and that logic can be updated if there are any codes that are not covered.

Additionally, there are certain error codes which CBFS Vault uses in a special manner. For more information about such error codes, please refer to the Error Codes page.

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.

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 Vault 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 Vault 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 Vault).
  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 Vault 2020 Qt Edition - Version 20.0 [Build 8145]