Introduction
Welcome to CBFS Direct, an easy-to-use toolkit for gaining low-level direct access to disks and memory in Windows.
| Library | Supported Runtimes | Comments |
| lib\callback.CBFSDirect.dll | .NET Framework 4.0 and up | This is the default library which maintains a familiar API in line with previous versions of the product. |
| lib\netstandard2.0\callback.CBFSDirect.dll | .NET Standard 2.0 and up | The .NET Standard library maintains the same API as the default library and can be used in projects that are based on .NET Core and .NET 5 and later. |
| lib\net20\callback.CBFSDirect.dll | .NET Framework 2.0 and up | This library targets .NET Framework 2.0 and is maintained for legacy projects. |
| CBDirect | The CBDirect component provides applications with low-level, direct access to disks and memory in Windows. |
Additional Information
You will always find the latest information about CBFS Direct at our web site: www.callback.com. We offer free, fully-functional 30-day trials for all of our products, and our technical support staff are happy to answer any questions you may have during your evaluation.
Please direct all technical questions to support@callback.com. To help support technicians assist you as quickly as possible, please provide an detailed and accurate description of your problem, the results you expected, and the results that you received while using our product. For questions about licensing and pricing, and all other general inquiries, please contact sales@callback.com.
Thank You!
Thank you for choosing CBFS Direct for your development needs. We realize that you have a choice among development tools, and that by choosing us you are counting on us to be a key component in your business. We work around the clock to provide you with ongoing enhancements, support, and innovative products; and we will always do our best to exceed your expectations!
Deployment
The topics in this section provide information regarding the deployment of applications built with CBFS Direct. The information in these topics should be reviewed carefully when designing a deployment strategy, since CBFS Direct's kernel mode drivers and other supplementary DLLs must be distributed along with the application in order for it to function correctly.
Topics
Driver Installation
At a high level, CBFS Direct consists of a kernel mode driver and a user mode library which work together in tandem to provide the product's functionality. Therefore, it is necessary to install the CBFS Direct kernel mode driver when deploying an application built with the CBFS Direct user mode library.
The functionality needed to install the above-mentioned modules is included in the user mode library itself, as well as in a separate installer DLL. The drivers directory, located within the product's installation directory, contains the following files:
| {ComponentName}.cab | Contains the component's drivers and the supplementary installation/uninstallation files. |
| installer/{ComponentName}Inst.h | A header file for the installer DLL. The installer DLL may be used on the target system to install (or uninstall) the items within {ComponentName}.cab. |
| installer/x64/{ComponentName}Inst.dll | The C/C++ installer DLL for the x64 (AMD64) processor architecture. |
| installer/x86/{ComponentName}Inst.dll | The C/C++ installer DLL for 32-bit x86 processor architecture. |
| installer/ARM/{ComponentName}Inst.dll | The C/C++ installer DLL for 32-bit ARM processor architecture. |
| installer/ARM64/{ComponentName}Inst.dll | The C/C++ installer DLL for 64-bit ARM processor architecture. |
NuGet Notes
If CBFS Direct is installed using NuGet, the drivers directory described above will be located within NuGet's global-packages directory at the following path (assuming NuGet's global-packages directory has not been changed): %USERPROFILE%\.nuget\packages\callback.cbfsdirect\22.0.xxxx\contentFiles\any\any\drivers.
Installation and Uninstallation via User Mode Library Methods
The component includes the following methods to install and uninstall the required files; please refer to their documentation for more information:
Important: Uninstall must only be used when completely removing the driver. When updating the driver, this method must not be used as it may cause the OS to incorrectly remove the driver on reboot. Please refer to the "Updating the Driver" section, below, for more information.
Installation and Uninstallation via Installer DLL Functions
The installer DLL is a lightweight, stand-alone library that contains only the functionality required for installing and uninstalling the required files. It is available in both 32-bit and 64-bit versions (each of which is capable of installing both 32-bit and 64-bit drivers and helper DLLs); and may be used as desired in installation scripts, setup applications, or any other executable capable of loading dynamically-linked libraries (DLLs).
The functions exposed by the installer DLL mirror the component methods listed above. Each function is available in two forms: those with an *A suffix, which can be used with ANSI/UTF8 strings; and those with a *W suffix, which can be used with Unicode (UTF16) strings.
Updating the Driver
To update the driver, call the Install method. The new version of the driver will replace the older version. Please do not call the Uninstall method when updating the driver.
Uninstalling the Driver
To uninstall the driver completely, call the Uninstall method. If the driver cannot be immediately uninstalled, it will be marked for removal and uninstalled on the next reboot.
Use caution when calling Uninstall ; if it gets called and the driver cannot be uninstalled immediately, and then Install is subsequently called to install a new version, then upon reboot, the OS will end up uninstalling the newly-installed driver.
Important: The driver should only be uninstalled when the intent is to completely remove it from the system. Do not uninstall the driver to update it.
Reboot Requirements
Depending on the current state of the system, as well as the options chosen when installing or uninstalling the driver, the OS may need to reboot to complete the operation.
Always check the return value of the Install and Uninstall methods/functions; it will indicate whether a reboot is required .
Additional Notes
The OS treats major versions of the driver as separate products; they can operate in parallel and do not share any resources. Old major versions may optionally be removed from the system when calling Install by passing the appropriate value for its Flags parameter.
For each major version of the product, only one copy of the driver can be installed at any time. When the driver is being installed, its version is checked, and one of the following three things occurs:
- If no driver with the same major version is currently installed, then the install procedure installs the driver as a new product.
- If a driver with the same major version and an older minor version is currently installed, then the install procedure updates the existing driver with the new one.
- If a driver with the same major version and a newer minor version is currently installed, then the install procedure leaves the existing driver unchanged.
When deploying files to a target system, the CAB file must remain present on the system. This file is required for uninstallation of the driver at a later time.
The product's installation code maintains a ProductGUID-based record of driver installations in the Windows Registry, creating a separate registry entry for each different ProductGUID. When the driver is "uninstalled", the corresponding registry entry is removed. The driver is only removed from the system if there are no entries left in the registry that reference the driver.
Windows 7 and Windows 2008 Server R2
Kernel-mode drivers are signed using the SHA2 algorithm. The original releases of Windows 7 and Windows 2008 Server R2 didn't support SHA2. To be able to load the newest versions of the drivers, the system needs to have certain updates installed. The updates are KB976932 (Service Pack 1 of the mentioned systems) and KB4474419 (Security Update).
Required Permissions
By default, Windows only allows installation and uninstallation of the CBFS Direct system files (kernel mode driver) to be performed from a user account which is a member of the Administrators group.
On systems where UAC is enabled, the process responsible for installing or uninstalling the system files must run with elevated permissions. Detection of current privileges and elevation of permissions is not within the scope of the component itself.
Some examples of obtaining the required permissions for driver installation and uninstallation are below.
- Starting the application which uses the component with the "Run as administrator" option.
- Modifying the Load and unload device drivers setting in the Local Security Policy under the User Rights Assignment section.
- Including a manifest alongside the application indicating the requirement for elevated permissions. For instance, if a file MyApp.exe.manifest with the content below exists next to the application MyApp.exe, it will prompt for elevated permissions when started (if required).
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="ExeName" type="win32"/> <description>elevate execution level</description> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2"> <security> <requestedPrivileges> <requestedExecutionLevel level="requireAdministrator" uiAccess="false"/> </requestedPrivileges> </security> </trustInfo> </assembly>
User Mode Library
Note : The user-mode library must be deployed to end-user systems together with the kernel-mode drivers; the version of the kernel-mode drivers on the end-user systems must be equal or newer to the version of the user-mode library. Thus, when the user-mode library is installed or updated on end-user systems, it is required to ensure that the kernel-mode drivers already present in the system are updated to match the version of the installed user-mode library.
The user mode library comes in two pieces, both of which must be deployed along with the application:
- A .NET assembly (managed), named callback.cbfsdirect.dll (or callback.cbfsdirect.NetStd.dll, for .NET Standard).
- A native dynamic library (unmanaged), named cbfsdirect22.dll, available for both 32-bit (x86) and 64-bit (x64, ARM64) processor architectures.
When deploying the application, copy both the .NET assembly and the native library to the target system and place them next to the application's .exe file .
The .NET assembly may alternatively be deployed to the Global Assembly Cache (GAC).
Alternatively, the native dynamic library may be placed into one of directories, pathes to which are contained in the PATH environment variable, such as C:\Windows\System32 (or C:\Windows\SysWOW64 when deploying a 32-bit application on a 64-bit Windows system).
NuGet Notes
After the NuGet package is added to a project, both the managed .NET assembly and the unmanaged native library will be copied to the project's output directory anytime the project is built. However, the exact files copied to the output directory for the native library will vary based on the project type:
- For .NET Core projects, a runtimes directory will be created in the output directory (if it does not already exist), and versions of the native library for each supported runtime identifer (RID) (e.g., win-x64) will be placed in the appropriate subdirectories. When the .NET Core application is distributed, the entire runtimes directory should be deployed alongside it.
- For other types of projects (.NET Framework, UWP), only the native library version specific to the currently-selected platform target (e.g., x64) will be copied to the output directory.
- For .NET Framework projects specifically, please note that the project's platform target (Project > Properties > Build Tab > Platform target) must be set to a real architecture. If it is set to "Any CPU", no native library will be copied to the output directory.
The native library may alternatively be installed to the Windows System directory. This approach allows deploying both the 32-bit and 64-bit versions of the native library simultaneously, since each gets placed into the system directory that corresponds to the appropriate processor architecture.
Remember to deploy the drivers too, as they are an integral part of CBFS Direct.
General Information
The topics in this section provide general information about various aspects of the product's functionality.
Topics
Driver Signing
Callback Technologies does not sign the CBFS Direct system driver due to the nature of the product; instead, the driver is provided in an unsigned form. Since modern versions of Windows refuse to load unsigned drivers under normal circumstances, this effectively prevents casual abuse or misuse of the product.
Currently, all driver signing is performed by Microsoft (see the instructions below). Microsoft Partner Center accepts submissions, and when submitting the package, you need to sign it using your own code-signing certificate. More specifically, you will need to have an Extended Validation Code Signing certificate issued by a Certificate Authority (CA).
Getting Started
NOTE: By default, the product is installed into the Program Files directory. As a result, the scripts and instructions listed below must be run in an elevated command-line interface (CLI). To start cmd.exe (or another shell) with elevated privileges, run it using Windows Explorer's Run As Administrator command.
After installing CBFS Direct, you'll find the cbdirect.cab file in the drivers directory, which is located in the product's installation directory. This file contains the unsigned drivers and supplementary files for CBFS Direct, arranged in a directory structure suitable for use with the Install method.
In order to distribute properly signed driver files to your users, you'll need to unpack the cbdirect.cab file, sign the driver files that it contains as described below, and then re-create cbdirect.cab, placing the now-signed files into it. The sign_drivers.cmd script included with the product helps automate this task; its usage is described below.
The tools mentioned in this topic (i.e., inf2cat.exe and signtool.exe) are included in the Windows Kit, which is installed with Visual Studio and many other development tools. Also, it can be downloaded for free from the Microsoft's website. makecab.exe is the Windows system utility.
Scripts and Supplementary Files
Within the INSTALL_DIR\drivers\scripts directory, you'll find a number of files used in the signing process. The *.ddf and *.inf files are used in the process of creating a CAB file for submission, as described in "Signing Driver Files" section, below. The various *.cmd scripts help automate the signing procedures and the creation of the final CAB File.
In order to use the scripts, you'll first need to specify certain paths and certificate properties in the set_env.cmd script so that all files and certificates are found correctly by external tools (i.e., inf2cat.exe, signtool.exe, and makecab.exe). Specifically, you'll need to set the following variables in set_env.cmd:
- CBTBASE: the path to the product's files. The default value should be sufficient unless the scripts have been moved, or the product's directory structure has been modified.
- SIGN_SHA1_HASH and SIGN_SHA256_HASH: the SHA1 hashes of your SHA1 and SHA256 code signing certificates, respectively.
- CERTPATH: the path of the root certificate file used to countersign your code signing certificates.
- WINKITDIR: the path to the Windows SDK. By default, this variable is set to the path to the Windows 10 SDK on 64-bit machines.
- SIGNTOOLDIR: the path to the signtool.exe utility. The signtool.exe utility is included in Windows 10 SDK, but the exact path will differ depending on the build number of the SDK that you have installed; the script will warn you if the default path must be changed.
- INF2CATDIR: the path to the inf2cat.exe utility. The inf2cat.exe utility is included in Windows 10 SDK, but the exact path will differ depending on the build number of the SDK that you have installed; the script will warn you if the default path must be changed.
- SEVENZIPPATH: the path to the 7zip executable (including the EXE name). 7zip is used to extract the signed driver files from the ZIP file that Microsoft provides for download. You can use another unzip utility if you wish, but you will likely need to modify the relevant commands in the prepare_sign_new.cmd script if you do.
The sign_drivers.cmd script is designed to do everything for you. It unpacks the provided CAB file (i.e., the one with the unsigned driver files), and then calls the other scripts in the correct order. The other scripts are:
- prepare_sign_new.cmd: performs the new-style signing process. See the "Signing Driver Files" section, below, for more information (please note that this process includes manual steps).
- prepare_cab.cmd: builds the final CAB file (i.e., the one containing the signed driver files) suitable for use with the Install method. The final CAB file will be named cbdirect_signed.cab.
- sign_distro_drv.cmd: is called by the other scripts to actually sign files using your certificates; it should not be called directly.
Signing Driver Files
To sign the drivers, you'll need to obtain an Extended Validation (EV) code signing certificate and register it with Microsoft for kernel-mode signing; please, refer to Microsoft's Driver Signing Policy article for more information. Then, either use the provided scripts, or follow these steps (adapted from Microsoft's Attestation Signing a Kernel Driver for Public Release article):
- Ensure that your code signing certificate is imported to Windows Certificate Store. If the certificate is stored on the hardware device, the drivers and/or supplementary software for that device should map the certificates contained in the device into Windows Certificate Store. If you have the certificate as a file or several files with a private key (this is important), you need to import it to Windows Certificate Store manually.
- Ensure that the cbdirect.cab file's contents have been unpacked into the INSTALL_DIR\drivers directory.
- Create a new CAB file for submission (this is different from the CAB unpacked in step 1).
To do this, run the prepare_sign_new.cmd script in the INSTALL_DIR\drivers\scripts directory; it performs the following steps:
- Creates a CAB File for submission to Microsoft:
makecab.exe /V3 /D "ver"="22" /F sign.ddf - Signs the newly-created CAB file with your EV certificate using the following command (any recent version of signtool.exe will work):
%SIGNTOOLDIR%\signtool.exe sign /T http://timestamp.globalsign.com/scripts/timstamp.dll /n "your-cert-subject" cbdirect.cab - Opens the Microsoft Partner Center, and then pauses so that you can do steps 4-8 manually:
- On the opened page, create a driver signing submission by filling in the form fields as follows:
- File: Upload the cbdirect.cab file created in step 2 (not the one included with the product).
- Product name: A name of your choosing which is used to identify this driver signing submission.
- Perform test-signing ...: Leave unchecked.
- Requested Signatures: All checkboxes must be checked.
- The signing process will be displayed at the top of the page.
- In the "Distribution" section, none of the actions are required.
- After signing is complete (i.e., when the progress reaches the "Finalize" stage), a Signed_XXXXXXX.zip file will be available for downloading. This ZIP file will contain the signed driver files for all architectures. To download the ZIP file, click the "More" link in the "Packages and signing properties" section of the page, then click the "Download signed files" button.
- Save the ZIP file to the same directory where the previously-submitted CAB file is (i.e., INSTALL_DIR\drivers\scripts\Sign), then continue the script.
- The script will finish by unpacking the downloaded ZIP file's contents.
- Creates a CAB File for submission to Microsoft:
- After the ZIP file is unpacked, you may proceed with preparation of the final CAB file (i.e., the one that will be distributed to end-users). Refer to the "Creation of Installation CAB File" section, below.
Creation of Installation CAB File
The final CAB can be prepared by running the prepare_cab.cmd script in the INSTALL_DIR\drivers\scripts directory. The sign_drivers.cmd script will make this call for you automatically.
Error Reporting and Handling
Error Codes
The CBFS Direct communicates errors using the Win32 error codes defined in WinError.h, which is part of the Windows Platform SDK. The CBFS Direct system drivers, however, use NT native error codes, which don't have one-to-one mappings with Win32 error codes. The component 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 Direct uses use in a special manner. For more information about such error codes, please refer to the Error Codes page.
Reporting Errors to the Component 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 component. The ResultCode parameter is set to 0 by default, which indicates the operation was successful.
If an unhandled exception occurs in the event handler, it will be caught by the component, which will fire the OnError event.
In some events, the OS doesn't expect the error code to be returned and either the component 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 Component
If an error occurs, the component will throw an exception. The Code property of the exception object will contain an error code, and the Message property will contain an error message (if available).
Extended Logging in Windows
Some component methods in CBFS Direct 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 component 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 Direct system drivers, or while using the component, please do the following:
- Enable extended logging (see below).
- Replicate the issue.
- 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 Direct).
- Submit an issue report that includes the exported file.
There are two ways to toggle extended logging for a component:
- By toggling the component's LoggingEnabled configuration setting.
- By adding a DWORD-typed value named Enabled to the HKEY_LOCAL_MACHINE\SOFTWARE\Callback Technologies\{ComponentName}\EventLog registry key and setting it to 0 (disabled) or 1 (enabled).
- Replace the {ComponentName} part of the registry key path with the name of the applicable component.
- If this registry key, one of its parents, or the value itself does not exist, please create it manually.
The system must be rebooted anytime extended logging is enabled or disabled to make the changes take effect.
Troubleshooting
CBFS Direct is a complex product that operates in both user mode and kernel mode simultaneously; so when a serious issue occurs, it's critical that we are able to obtain sufficient information about the circumstances of the failure.
In order to help us assist you in a more expedient manner, please collect the information described in the instructions below when reporting a serious issue (i.e., one that causes the system to crash or hang). Our development team cannot effectively diagnose such issues without this information.
Also, please note that these sorts of issues commonly involve environmental differences and other factors that are either unforeseen or otherwise out of our control. It is also not unheard-of for a crash to appear attributable to one thing while in fact being caused by something completely different. Rest assured that we are committed to assisting you as best we can, and we thank you ahead-of-time for your patience and understanding throughout the support process.
System Crashes (BSODs)
If you encounter a consistently-reproducible system crash (BSOD) that you suspect may be due to CBFS Direct, please obtain a crash dump and include it when reporting the issue to us. Our development team is unable to diagnose system crashes without the information these dumps contain.
Ensure that your system is set up to generate crash dumps, and to not restart automatically after a crash, by following the steps found in Microsoft's Enabling a Kernel-Mode Dump File article. The options available in the memory dump dropdown vary depending on your version of Windows; please choose the first one from the following list that is present in yours:
- Complete
- Full
- Automatic
- Kernel
Once your system is set up to generate crash dumps, perform the same action that caused the BSOD originally to trigger the crash again. When it occurs, be sure to copy the information on the BSOD screen exactly so that it can be included in your submission (a picture of the screen in which all of the information is legible is also acceptable). Here are some examples of the specific information we're looking for:
Recent versions of Windows:
What failed: cbfs***22.sys
Stop Code: FILE_SYSTEM
Older versions of Windows:
STOP: 0x00000022 (0x00240076, 0xF7A07AA8, 0xF7A077A8, 0xF7800C82)
cbfs***22.sys - Address F7800C82 base at F77CD000, DateStamp 447d6975
After you've copied this information, reboot and check that the memory dump file was created at %SYSTEMROOT%\MEMORY.DMP (typically this is C:\Windows\MEMORY.DMP; if you changed the dump file location in the crash dump settings, check the location you specified instead). It will be a very large file that is too big to attach to an email, so please upload it to a file sharing site of your choice and generate a sharing link that our development team can use to download it.
Finally, submit a support issue to us that includes the link to your dump file, all of the information from the BSOD screen (if you took a picture, attach it or provide another sharing link), a description of how the BSOD was triggered, and any other information that you feel is relevant.
System Hangs
If you encounter a consistently-reproducible system hang that you suspect may be due to CBFS Direct, you'll need to collect the same information as described above. But in order to obtain a crash dump, you'll first need to configure your system so that you can trigger a crash from the keyboard once it hangs. To make this possible, follow these steps (adapted from Microsoft's Forcing a System Crash from the Keyboard article):
- First, using the instructions provided in the section above, configure your system to generate crash dumps, and to not restart automatically after a crash.
- Next, you must enable keyboard-initiated crashes in the registry by creating a new value named CrashOnCtrlScroll, and setting it equal to a REG_DWORD value of 0x01, in all of the following registry keys:
- HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\i8042prt\Parameters
- HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\kbdhid\Parameters
- HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\hyperkbd\Parameters
- Finally, you must restart the system in order for these settings to take effect.
After these steps are complete, you'll be able to trigger a keyboard-initiated crash by using the following hotkey sequence: hold down the Right CTRL key, and press the SCROLL LOCK key twice.
At this point, you can perform the same action that caused the system to hang originally to trigger the hang again. Once the system hangs, use the hotkey sequence to force it to crash, and then follow the rest of the instructions from the section above to collect and submit the necessary information.
Application Crashes
Sometimes, an application crashes while the OS continues to operate, and the name of one of the modules of CBFS Direct is present in the crash information. A crashing application can be the one that uses CBFS Direct or some third-party process. If the crash occurs repeatedly, it is possible to make use of a User-Mode Crash Dump to locate or narrow down the source of the crash. Generation of crash dumps is disabled by default. Before you reproduce the crash, you need to Enable Collecting User-Mode Crash Dumps.
After you enable the crash dump, you don't need to reboot, you can proceed to reproduction of the crash immediately. After the crash re-occurs, you can pick the dump file from its location. The default locations of user-mode dump files are:
- For regular applications: %LOCALAPPDATA%\CrashDumps
- For System services: %WINDIR%\System32\Config\SystemProfile
- For Network and Local services: %WINDIR%\ServiceProfiles
A crash dump can be a large file (depending on the settings) that is too big to attach to an email, so please upload it to a file sharing site of your choice and generate a sharing link that our development team can use to download it.
Finally, submit a support issue to us that includes the link to your dump file, a description of how the BSOD or a manual crash was triggered, and any other information that you feel is relevant.
Constants
All constants are accessible through the callback.CBFSDirect.Constants class.
Install Flags |
||
| INSTALL_REMOVE_OLD_VERSIONS | 0x00000001 |
Uninstall drivers and helper DLLs from previous component versions (e.g., 2017).
|
| INSTALL_KEEP_START_TYPE | 0x00000002 |
Keep the driver's current start type setting in the registry.
If this flag is not set (default), the installation logic will reset the driver's start type setting in the Windows registry to the default value. Setting this flag causes the installation logic to preserve the current value, which may be necessary if the user (or the application itself) set it previously. |
| INSTALL_OVERWRITE_SAME_VERSION | 0x00000004 |
Install files when their version is the same as the version of already installed files.
If this flag is not set (default), the installation logic will overwrite the existing file only if the version number of the file being installed is larger than the version of the file being overwritten. Setting this flag causes the installation logic to overwrite the file even when it has the same version. |
Uninstall Version Flags |
||
| UNINSTALL_VERSION_PREVIOUS | 0x00000001 |
Uninstall modules from previous product versions.
|
| UNINSTALL_VERSION_CURRENT | 0x00000002 |
Uninstall modules from the current product version.
|
| UNINSTALL_VERSION_ALL | 0x00000003 |
Uninstall modules from all product versions.
|
Module Status Flags |
||
| MODULE_STATUS_NOT_PRESENT | 0x00000000 |
The specified module is not present on the system.
|
| MODULE_STATUS_STOPPED | 0x00000001 |
The specified module is in the Stopped state.
|
| MODULE_STATUS_RUNNING | 0x00000004 |
The specified module is loaded and running.
|