SearchPathW заморозка - PullRequest
       5

SearchPathW заморозка

2 голосов
/ 02 апреля 2020

Я пытаюсь написать функцию, которая сможет найти произвольный исполняемый файл, расположенный в пути поиска исполняемых файлов в моей системе. Я сталкиваюсь с проблемой, когда некоторые входные данные приводят к зависанию 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();
}

Когда имя равно L"--autoruns" (что не является текущим файлом в моем пути поиска), код останавливается при первом вызове SearchPathW, и вызов никогда не возвращается.

Очевидное решение здесь было бы "О, ну просто не ищите файлы, которые не существуют!" К сожалению, это не вариант, поскольку одно из предполагаемых применений этой функции - определить, действительно ли файл присутствует в пути поиска. Поскольку я могу поместить файл с именем --autoruns.exe в каталог C: \ Windows, я могу отфильтровать его не просто.

Что я могу сделать, чтобы предотвратить это зависание полностью исключить вызов SearchPathW или перехватить и исправить это зависание?

Я уже пытался создать новый поток для обработки вызова SearchPathW и WaitForSingleObject с задержкой 1000 мс. По какой-то причине это тоже зависло.

После запуска procmon, похоже, проблема в том, что он продолжает повторный поиск пути.

Я нашел несколько других имен файлов, которые также вызывают такую ​​же проблему, из-за чего я сомневаюсь, что есть какая-то символическая / жесткая ссылка, вызывающая это. Я также проверил свой PATH по проверяемым путям к файлам, и перед повторением он проверяет каждое место в моем PATH.

1 Ответ

0 голосов
/ 02 апреля 2020

Проблема была вызвана функцией более высокого уровня, вызывающей эту функцию в al oop с недостижимым условием прерывания, и отладчик всегда отображал ее зависание в SearchPathW. Решено.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...