Winpk filter driver is not installed or failed to load что делать
Обновлено: 05.07.2024
Решили мы как-то перевести свой проект на Visual Studio 2015 — там ведь столько захватывающих фич! Вчера вот только решили, а уже сегодня утром я запустил её инсталлятор. Небо было безоблачным, ничто не предвещало беды. Ну что, в самом деле, может пойти не так? Сколько уже этих Visual Studio переставлено — не счесть (я, помнится, ещё 6.0 когда-то ставил). Кто бы мог подумать, что эта тривиальнейшая задача может вылиться в весьма неожиданный забег по граблям длинной почти в целый рабочий день.
Хм. Не поставился значит, Team Explorer и ещё пару минорных пакетов. Ну ок. Закрываем, переустанавливаем. Не помогает. Удаляем студию, перезагружаемся, устанавливаем — та же ошибка. Лезем в Гугл с вопросом об ошибке установки Visual Studio 2015 на этапе инсталляции компонента Team Explorer и понимаем, что проблема это массовая — десятки ссылок с тем же описанием:
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17
Отвечают на все эти вопросы специалисты первой линии техподдержки Microsoft, советы которых сводятся к «отключите антивирус», «проверьте чексуму образа со студией», «проверьте диск на ошибки». Ничего из этого, конечно, не помогает, о чём им и рассказывают, после чего они пропадают и больше не отвечают. Очень дружелюбная пользовательская поддержка, ничего не скажешь.
Ну что же, пора включать голову, брать в руки инструменты и разбираться. Поехали.
Итак, всё что у нас есть, это входная точка ошибки — проблема с Team Explorer. И ссылочка на лог-файл на приведённом выше скриншоте. Ну ок, давайте пойдём почитаем что там лог-файл думает о нашей ошибке.
Всё, что можно понять из этого лога, это то что компонент ставился-ставился, да что-то не поставился. Бывает, мол, чего уж там. Ну, спасибо большое за информацию!
Ладно, давайте зайдём с другой стороны. Team Explorer это (как и почти всё в современных версиях Visual Studio) — VSIX (компонент, расширение). Ставится отдельно от ядра студии специальной программой VSIXInstaller.exe, которая живёт в C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE и умеет при установке этих самых VSIX-компонентов писать во временную папку (ну, ту, которая %TEMP%) логи о том, как всё прошло. Идём в %TEMP%, находим по времени ошибки из лога выше файлик, соответствующий установке Team Explorer. Вот он:
Ну, тут уже побольше всякого интересного написано, конечно. Нас интересует первый момент, когда что-то пошло не так. Вот он:
26.11.2015 17:31:06 - System.TypeInitializationException: The type initializer for 'VSIXInstaller.SupportedSKUs' threw an exception. ---> System.BadImageFormatException: Could not load file or assembly 'Microsoft.VisualStudio.Settings.14.0.dll' or one of its dependencies. is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)
Хм, произошла ошибка при попытке загрузить сборку Microsoft.VisualStudio.Settings.14.0.dll. Первой моей мыслью было то, что студия как-то запуталась в порядке установки своих компонентов и пытается использовать при установке что-то, что ещё не установилось куда надо. Так, есть у нас в системе такая библиотека?
Оказалось — есть. Лежит в GAC, там где ей и положено лежать:
Так, что же получается? Сборка есть, она находится там, где нужно, но не загружается. Может быть, битая? Берём IL DASM, загружаем — всё ок.
Может быть умельцы из Microsoft сумели написать такой инсталлятор, у которого иногда получается не найти сборку в GAC? Берём Process Monitor, добавляем в него фильтр на открытие файлов и снова запускаем инсталлятор студии. Доходим до ошибки, смотрим логи.
Ага, vcruntime140.dll загружается. Это redistributable-библиотека от Visual Studio 2015. Ну, она-то точно должна была поставиться на одном из первых этапов установки! Но давайте проверим, чем уже чёрт не шутит.
Проверка раз — в списке установленных программ:
Проверка два — в папке C:\Windows\SysWOW64\:
Проверка три — это, собственно, «SUCCESSS» в логе Process Monitor:
Последняя проверка — вообще железобетонный аргумент: видите, поискали, попробовали открыть, открылось успешно — значит файл найдён. Всё, подозрения снимаются, идём дальше. Так, какую-же библиотеку инсталлятор VSIX пытается подгрузить следующей по логами Process Monitor?
Как это опять vcruntime140.dll уже в другой папке?! Получается, найдя vcruntime140.dll в папке C:\Windows\SysWOW64\ и успешно её открыв (а мы знаем что так и было по логам выше!) загрузчик зависимостей всё-же почему-то счёл её недостаточно хорошей и отбросил. Как же так?! Это что — не майкрософтовская библиотека? Смотрим свойства:
Да нет, нормальная библиотека. Почему же не загрузилась? Давайте посмотрим на неё внимательнее. Для этого в составе любой версии Visual Studio есть отличная утилита dumpbin. Запускаем её с вот такими ключами:
и смотрим на результаты:
Подождите-подождите… А почему это ты, библиотечка, 64-битная?! Ты же лежишь в папке C:\windows\SysWOW64\, где вообще-то место только 32-битным библиотекам! А ну-ка давайте посмотрим, что же тогда лежит в C:\Windows\System32?
А то же самое (кто не верит в размер — можете проверить каким-нибудь WinMerge, они идентичны). Вы уже уловили, в чём суть? Ошибка закралась в инсталятор Redistributable-компонентов, входящий в инсталятор Visual Studio 2015 — он просто ставит 64-битные версии рантайм-библиотек и в папку для 64-битных библиотек (C:\Windows\System32) и в папку для 32-битных (c:\windows\SysWOW64\). В итоге при дальнейшей попытке использования 64-битной версии всё будет ок, а вот при попытке загрузки 32-битной версии будет то, что мы увидели при установке Team Explorer — загадочные ошибки вообще без упоминания библиотеки vcruntime140.dll и Redistributable-пакета. И делай, что хочешь.
А что же мы хотим делать? А удалить x86-часть Redistributable-пакета Visual Studio 2015, скачать её отдельно с сайта Microsoft и переустановить. Сюрприз — на сайте Microsoft версия правильная, она установит 32-битную версию библиотеки в C:\windows\SysWOW64, после чего можно перезапустить установку Visual Studio 2015 и она успешно дойдёт до конца!
Осталось как-то объяснить начальству почему это я целый день устанавливал Visual Studio, если с этим дети в третьем классе за час справляются. В общем-то ради этой цели и была написана данная статья, а уж зачем вы её прочли — я не знаю :)
Лог дописывается следующим:
При этом компонент WinpkFilterчтототам в компонентах сетевого подключения появляется, но при попытке как либо работать с сетевыми интерфейсами, например запустить стандартный listadapters.exe интерфейсов не видно:
Ошибка 0x80070002 гуглится как связанная с проблемами обновления винды, при чем здесь winpkfilter, непонятно.
Собственно, при деинсталяции winpkfilter в логе видна все та же ошибка:
Попытка установки/удаления драйвера через snetcfg.exe приводит к все той же ошибке
Возможно WinpkFilter устанавливался по разным путям, система запомнила первый и теперь не может найти драйвер. Я бы удалил драйвер стандартными средствами, а затем нашел бы INF файлы в папке Windows/INF которые содержат строку ndisrd. В случае с LWF нужно удалить пару файлов вида oemXXX.inf и oemXXX.pnf. Я бы еще перегрузил систему на всякий случай.
Спасибо за ответ.
Снес драйвер, удалил oem47.inf (где упоминался ndisrd) и oem47.pnf. Ребутнулся. При установке на отсутствие файликов не ругнулась, но ошибка в логе установщика все еще присутствует, как следствие, ничего не работает.
ЗЫ Аналогичный глюк появился на другом моем компьютере под win7 sp1, когда я снес winpkfilter и попробовал установить его заново.
Возможно остался ключ в реестре HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesndisrd. Удалите и его тоже. По идее если драйвер деинтсталлирован, удалены кешированные INF и ключи реестра, то следов остаться не должно. После всех удалений желательно перезагрузить систему.
Возможно остался ключ в реестре HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesndisrd. Удалите и его тоже. По идее если драйвер деинтсталлирован, удалены кешированные INF и ключи реестра, то следов остаться не должно. После всех удалений желательно перезагрузить систему.
А ветка HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesndisrd целиком сносится при деинсталляции.
UPD Так, оно заработало. Я не понял, что именно я сделал, постараюсь повторить и систематизировать =)
привет. купил б/у карту R9 290 Asus DC II. До этого в системе стояла Asus GTX 670 DC II. Переустановил Windows (в другую папку). Установил драйвера материнки. Установил последние драйвера Radeon (декабрьские). Обновил DirectX. Диспетчер устройств находит мою видеокарту. GPU-Z тоже определяет видеокарту и все соответсвует. Есть несколько проблем:
система:
MSI ZH77A-G43 (MS-7758)
Intel Core i5-3570, 3600 MHz
2 х 4Gb DDR3
Asus DC II R9 290
HDD: 1Tb
Zalman ZM600-GT 600 Вт
KROOM
ну а если в играх будут какие-то проблемы? или я просто раньше времени развожу панику и нужно установить что-то и попробовать поиграть?
и почему это оно обсчитывает i5-3570?
3д марк 11 физику ситает процом, не зависимо жираф или ати.
Добавлено через 1 минуту 3 секунды:
dzhankoy: Переустановил Windows (в другую папку). Я даже после апгрейда одного вендора произвожу переустановку (откат) системы на чистую Винду, а тут даже смена вендора, так что думаю ответ в этом. Ind146Tolik
подождите, винда была на диске С, я установил новую версию на диск D и запускаю ее. что тут ненормального?
3д марк 11 физику ситает процом, не зависимо жираф или ати. спасибо. это ценная информация, вот только количество fps по какой-то причине стало ниже. хм. может я зацепил процесоор или отсоединился кулер. я тут вспомнил что я когда был в биосе (думал что стоит приоритет в дискретной карте) заметил что температура CPU была 104 С. Это же очень много, да? dzhankoy: Ind1
подождите, винда была на диске С, я установил новую версию на диск D и запускаю ее. что тут ненормального?
sacred
все равно думаю что прична не в этом.
dzhankoy: sacred
все равно думаю что прична не в этом.
у вас были зелёные, драйвера уже в системе есть.
вы установили карту красных, драйвера конфликтуют. Больше наверное не бывает, он попросту должен был отрубится.
Если у вас стоковый кулер на процессоре, проверьте все лапки крепления. 46Tolik: 3д марк 11 физику ситает процом, не зависимо жираф или ати. скорость в физическом тесте зависит почти исключительно от мощности CPU, но разница между результатами видеоплат AMD и NVIDIA всё же есть — первые явно быстрее в тесте программной физики moff
фигня какая то. ничего такого не наблюдалось. блин, может какой-то кабель отошел. была температура нормальная а тут 100+ это вообще бред может датчик не работает.
Добавлено через 14 минут:
т.е. никто не думает что проблема в слабом БП? Zalman ZM600-GT 600 Вт по идее должно хватить на эту систему?
Добавлено через 1 минуту 44 секунды:
dzhankoy
Тут суорей всего процессор уходит в троллинг, если температура его высока. Разберись с охлаждением.
Были установлены дрова 415.13 из app nvidia-drivers попытался обновится до 415.18 - неудачно. Снес всё, удалил, заново добавил репозитори:
Еще раз все сношу что содержит 415 и пробую поставить nvidia-util-415, который тянет в зависимостях только libnvidia-compute-415 - тоже самое. Сношу.
А вот дальше совсем не понятно:
Да как так-то? Откуда берется этот клятый /etc/OpenCL/vendors/nvidia.icd и главное dpkg же откуда-то знает что это libnvidia-compute-415:i386
Удалил к черту этот файл (mv конечно, а не rm) и обновился. Вроде все встало но драйвер ничерта не запускается.
C dpkg -p та же фигня, попробуй apt-cache policy libnvidia-compute-415:i386 .
WitcherGeralt ★★ ( 01.12.18 00:05:19 )Последнее исправление: WitcherGeralt 01.12.18 00:06:13 (всего исправлений: 2)
Да собственно поставил просто удалив тот файл вручную. Теперь вот не пашет :(
Кстати, у тебя nvidia-settings какой версии стоит? у меня 415 тоже не запускается. Работает только 390.77 (но так и раньше было).
дебошлак как обычно
В dmesg ничего интересного не нашел?
Я бы сделал 'apt purge nvidia*', отключил ppa, поставил дровак из десктопных реп и посмотрел встанет ли.
Я бы сделал 'apt purge nvidia*', отключил ppa, поставил дровак из десктопных реп и посмотрел встанет ли.
Встанет. Но работать будет только с ядром 4.15, потому что те что в репах с 4.19 не работают.
В dmesg ничего интересного не нашел?
Короче решилось так - снес 415.18 с purge. Удалил репу, поставил 390, тоже удалил с purge (нашел такой рецепт на буржуйском форуме) вернул на родину репу с дровами и поставил вновь 415.18 - не заработало.
Доустановил nvidia-modprobe - тоже видел такой совет. Нифига.
Установил ядро 4.19.6 и после перезагрузки драйвер включился. Хрен его знает что из этого помогло. А у тебя какое ядро?
nvidia-settings по прежнему использую 390. 415 не пашет :(
Спасибо за помощь.
Suntechnic ★★★★★ ( 01.12.18 20:43:03 )Последнее исправление: Suntechnic 01.12.18 20:43:11 (всего исправлений: 1)
У меня 4.15, и вот именно из-за такого геморроя я никогда не спешу ставить свежак.
У меня проблемы с диском и под подозрением было именно ядро с версий от 4.15 до 4.18
Тут где-то тема была про то, как 4.19 гробит NVMe, так к слову.
WitcherGeralt ★★ ( 01.12.18 21:14:43 )Последнее исправление: WitcherGeralt 01.12.18 21:15:05 (всего исправлений: 1)
Портит ext4. Но я, похоже, попутал и там вообще не в NVMe дело. Не помню откуда я это взял, но в треде в толксах об этом ничего нет.
Читайте также: