我正在尝试编写一个函数,该函数将能够找到位于系统上可执行文件搜索路径中的任意可执行文件。我遇到一个问题,其中某些输入将导致SearchPathW无限期冻结,并且我不确定到底发生了什么。

std::optional<std::wstring> SearchPathExecutable(const std::wstring& name){
    auto size = SearchPathW(nullptr, name.c_str(), L".exe", 0, nullptr, nullptr);
    if(!size){
        return std::nullopt;
    }

    std::vector<WCHAR> buffer(static_cast<size_t>(size) + 1 );
    WCHAR* filename{};
    if(!SearchPathW(nullptr, name.c_str(), L".exe", size + 1, buffer.data(), &filename)){
        return std::nullopt;
    }

    return buffer.data();
}

当name为L"--autoruns"(这不是我的搜索路径中的当前文件)时,该代码在首次调用SearchPathW时冻结,并且该调用永不返回。

显而易见的解决方案是“哦,好吧,不要搜索不存在的文件!”不幸的是,这不是一种选择,因为此功能的预期用途之一是确定文件是否确实存在于搜索路径中。由于我可以在C:\Windows目录中放置一个名为“--autoruns.exe”的文件,因此它不仅可以过滤掉。

我该怎么做才能防止此挂起,完全避免调用SearchPathW或捕获并修复此挂起?

我已经尝试创建一个新线程来处理对SearchPathW的调用,并以1000 ms的延迟对其进行WaitForSingleObject编码。由于某种原因,那也挂了。

运行procmon后,似乎问题在于它一直在重新搜索路径。
c&#43;&#43; - SearchPathW卡住-LMLPHP

我发现其他一些文件名也导致相同的问题,这使我怀疑是否有某些符号链接(symbolic link)/硬链接(hard link)导致了此问题。我还对照要检查的文件路径检查了PATH,并在重复之前检查了PATH中的每个位置。

最佳答案

问题是由更高级别的函数在循环中以无法到达的中断条件调用此函数引起的,而调试器恰好总是显示它卡在SearchPathW上。解决。

关于c++ - SearchPathW卡住,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/60982658/

10-09 02:14