如何在TensorFlow C++ API中捕获库加载错误并实现设备自动降级？

可以实现需求，优先推荐前置依赖检查方案，运行时捕获方案作为备选：

方案1：前置依赖检查（最稳定） #

对应你给出的check_tf_libraries()伪代码逻辑，提前验证所有TensorFlow GPU依赖库是否存在，从根源上避免运行到session->Run才触发进程终止。

实现逻辑 #

TensorFlow GPU版本依赖的CUDA、cuDNN等库在运行前就可以通过系统API验证是否可加载：

• Windows平台：调用LoadLibraryEx尝试加载所有依赖的dll文件，加载成功说明路径配置正常
• Linux平台：调用dlopen尝试加载所有依赖的.so文件即可

示例代码 #

// Windows平台依赖检查示例
#include <windows.h>
#include <vector>
#include <string>

bool check_tf_libraries() {
    // 替换为当前使用的TensorFlow版本对应依赖的GPU库文件名
    std::vector<std::wstring> required_gpu_libs = {
        L"cudart64_110.dll",
        L"cudnn_ops_infer64_8.dll",
        L"cudnn_cnn_infer64_8.dll",
        L"cublas64_11.dll"
    };
    for (const auto& lib_name : required_gpu_libs) {
        HMODULE hMod = LoadLibraryExW(lib_name.c_str(), NULL, 
            LOAD_LIBRARY_SEARCH_DEFAULT_DIRS | LOAD_LIBRARY_SEARCH_SYSTEM32);
        if (hMod == NULL) {
            // 依赖库缺失
            return false;
        }
        FreeLibrary(hMod);
    }
    return true;
}

业务逻辑调用 #

bool libraries_ok = check_tf_libraries();
SessionOptions session_opt;
if (libraries_ok) {
    // 依赖正常，允许GPU运行
    session_opt.config.mutable_gpu_options()->set_allow_growth(true);
} else {
    // 依赖缺失，强制禁用GPU，走CPU运行
    session_opt.config.mutable_device_count()->insert({"GPU", 0});
}
// 用上述配置创建Session后直接运行即可，无需额外捕获错误

方案2：运行时异常捕获（备选） #

你无法用标准try...catch捕获错误的原因是：TensorFlow内部检测到GPU依赖库缺失时，会直接调用std::abort()终止进程，不会抛出C++标准异常。需要用系统级的异常捕获机制处理：

• Windows平台：使用结构化异常处理（SEH）的__try __except语法
• Linux平台：注册SIGABRT信号处理函数捕获终止信号

示例代码（Windows平台） #

__try {
    session->Run({{input_name, *input_tensor}}, {"StatefulPartitionedCall:0"}, {}, &predictions);
} __except (GetExceptionCode() == STATUS_FATAL_APP_EXIT ? EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH) {
    // 捕获到TensorFlow触发的终止异常，切换CPU Session重新运行
    SessionOptions cpu_opt;
    cpu_opt.config.mutable_device_count()->insert({"GPU", 0});
    // 重新创建CPU Session后执行推理
    cpu_session->Run({{input_name, *input_tensor}}, {"StatefulPartitionedCall:0"}, {}, &predictions);
}

注意事项 #

该方案存在局限性：进程触发abort后内部状态可能不稳定，仅作为前置检查方案的补充使用。

内容的提问来源于stack exchange，提问作者Fedor Petrov