Netcfginstanceid не удается найти файл

Обновлено: 02.07.2024

Исполняемый файл не найден

Имя исполняемого файла определяет то, как вызывается средство. Формат описывается в приведенной ниже таблице.

Формат имени исполняемого файла	Формат вызова
dotnet-<toolName>.exe	dotnet <toolName>
<toolName>.exe	<toolName>

Глобальные средства

Глобальные средства можно установить в каталоге по умолчанию или в выбранном вами расположении. Каталоги по умолчанию:

Операционная система	Path
Linux/macOS	$HOME/.dotnet/tools
Windows	%USERPROFILE%\.dotnet\tools

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

Локальные средства

Если вы пытаетесь запустить локальное средство, убедитесь в наличии файла манифеста с именем dotnet-tools.json в текущем каталоге или в любом из его родительских каталогов. Этот файл также может находиться в папке .config где угодно в иерархии папок проекта, а не в корневой папке. Если файл dotnet-tools.json существует, откройте его и проверьте наличие средства, которое вы пытаетесь запустить. Если в файле нет записи для "isRoot": true , также проверьте наличие дополнительных файлов манифестов средств выше в иерархии файлов.

Среда выполнения не найдена

Накат не выполняется по умолчанию в двух распространенных сценариях:

доступны только более ранние версии среды выполнения; при накате выбираются только более поздние версии среды выполнения;
доступны только более поздние основные версии среды выполнения. При накате границы основной версии не пересекаются.

Если приложению не удается найти подходящую среду выполнения, оно не запускается и сообщает об ошибке.

Изменение имен пакетов

Корпорация Майкрософт изменила правила в отношении идентификаторов пакетов для средств, из-за чего некоторые средства теперь невозможно найти по прежним именам. Согласно новым правилам имена средств Майкрософт должны иметь префикс "Microsoft.". Этот префикс зарезервирован и может использоваться только для пакетов, подписанных с помощью авторизованного сертификата Майкрософт.

Во время перехода некоторые средства Майкрософт будут иметь старую форму идентификатора пакета, а другие — новую форму:

По мере обновления идентификаторов пакетов необходимо будет перейти на новый идентификатор, чтобы получить последние обновления. Пакеты с упрощенными именами средств станут нерекомендуемыми.

Предварительные выпуски

Вы пытаетесь установить предварительный выпуск и не использовали параметр --version для указания версии.

NU1212: недопустимое сочетание проекта и пакета для <toolName> . Стиль проекта DotnetToolReference допускает только ссылки типа DotnetTool.

Веб-канал NuGet недоступен

Не удается получить доступ к требуемому веб-каналу NuGet, возможно, из-за проблемы с подключением к Интернету.

Для установки средства требуется доступ к веб-каналу NuGet, содержащему пакет средства. Установка завершается сбоем, если этот веб-канал недоступен. Вы можете изменить веб-каналы с помощью nuget.config , запросить определенный файл nuget.config или указать дополнительные веб-каналы с помощью параметра --add-source . По умолчанию NuGet выдает ошибку для каждого веб-канала, к которому не удается подключиться. Флаг --ignore-failed-sources позволяет пропускать недоступные источники.

Неправильный идентификатор пакета

401 (не санкционировано)

Скорее всего, вы указали альтернативный канал NuGet, и этот канал требует проверки подлинности. Вот несколько разных способов решить проблему:

Добавьте параметр --ignore-failed-sources , чтобы обойти ошибку из закрытого канала и использовать общедоступный канал Майкрософт.

Если вы устанавливаете средство из канала Microsoft NuGet, пользовательский канал возвращает эту ошибку, прежде чем канал Microsoft NuGet вернет результат. Ошибка завершает запрос, отменяя любые другие ожидающие запросы канала, который может быть каналом Microsoft NuGet. Добавление параметра --ignore-failed-sources приводит к тому, что команда обрабатывает эту ошибку как предупреждение и позволяет другим каналам обработать запрос.

Принудительно используйте канал Microsoft NuGet с параметром --add-source .

Возможно, в глобальном или локальном файле конфигурации NuGet отсутствует общедоступный канал Microsoft NuGet. Используйте сочетание параметров --add-source и --ignore-failed-sources , чтобы избежать ошибочного канала и использовать общедоступный веб-канал Майкрософт.

Используйте настраиваемую конфигурацию NuGet, параметр --configfile <FILE> .

Здравствуйте, idiMAN, Вы писали:

MAN>Как выбрать из списка сетевых подключений (адаптеров, интерфейсов), которые присутствуют на локальном компьютере, только те, которые связаны с реальными сетевыми картами. Т.е. нужно исключить, например, адаптеры VMWare и т.п.

Например, можно воспользоваться IP Helper, а именно, функцией GetAdaptersInfo. Там есть пример. Вам нужно обратить внимание на поле Description структуры IP_ADAPTER_INFO. В случае, если в системе присутствуют сетевые адаптеры для VMWare, то поле Description будет содержать "VMware Virtual Ethernet Adapter for. ". Тем самым вы можете их отсекать.
Вот примерчик получения описаний и названий адаптеров в системе (msdn):

Здравствуйте, -prus-, Вы писали:

P>Например, можно воспользоваться IP Helper, а именно, функцией GetAdaptersInfo. Там есть пример. Вам нужно обратить внимание на поле Description структуры IP_ADAPTER_INFO. В случае, если в системе присутствуют сетевые адаптеры для VMWare, то поле Description будет содержать "VMware Virtual Ethernet Adapter for. ". Тем самым вы можете их отсекать.

GetAdaptersInfo не подходит — она возвращает информацию не обо всех адаптерах, например, если состояние адаптера имеет значение "запрещено", то информация о нём не возвращается. И вообще, из данных, возвращаемых GetAdaptersInfo, невозможно определить что данный адаптер соответствует реальной (а не виртуальной) сетевой карте, кроме как по описанию (поле Description). VMware в качестве виртуального сесевого адаптера я указал лишь для примера. В моём случае у меня присутствует одна реальная сетевая карта, которая с помощью драйвера превратилась в две виртуальных, каждая из которых получает пакеты из своего VLAN. Так вот GetAdaptersInfo возвращает только информацию об этих двух виртуальных адаптерах, реальный же адаптер вообще почему-то не фигурирует в выдаваемых данных.

MAN>GetAdaptersInfo не подходит — она возвращает информацию не обо всех адаптерах, например, если состояние адаптера имеет значение "запрещено" то информация о нём не возвращается.

Ну так и на хрена они тебе нужны, если запрещённые?

MAN>И вообще, из данных, возвращаемых GetAdaptersInfo, невозможно определить что данный адаптер соответствует реальной (а не виртуальной) сетевой карте, кроме как по описанию (поле Description). VMware в качестве виртуального сесевого адаптера я указал лишь для примера. В моём случае у меня присутствует одна реальная сетевая карта, которая с помощью драйвера превратилась в две виртуальных, каждая из которых получает пакеты из своего VLAN. Так вот GetAdaptersInfo возвращает только информацию об этих двух виртуальных адаптерах, реальный же адаптер вообще почему-то не фигурирует в выдаваемых данных.

Ну так это как драйвер захочет так и покажет тебе, и на Win32-уровне в общем случае ничего ты не сделаешь.

Здравствуйте, x64, Вы писали:

MAN>>GetAdaptersInfo не подходит — она возвращает информацию не обо всех адаптерах, например, если состояние адаптера имеет значение "запрещено" то информация о нём не возвращается.

x64>Ну так и на хрена они тебе нужны, если запрещённые?

Это я лишь к тому, что данной функцией возвращается не вся информация. Т.е. нет способа получить информацию обо ВСЕХ сетевых адаптерах в системе!

MAN>>И вообще, из данных, возвращаемых GetAdaptersInfo, невозможно определить что данный адаптер соответствует реальной (а не виртуальной) сетевой карте, кроме как по описанию (поле Description). VMware в качестве виртуального сесевого адаптера я указал лишь для примера. В моём случае у меня присутствует одна реальная сетевая карта, которая с помощью драйвера превратилась в две виртуальных, каждая из которых получает пакеты из своего VLAN. Так вот GetAdaptersInfo возвращает только информацию об этих двух виртуальных адаптерах, реальный же адаптер вообще почему-то не фигурирует в выдаваемых данных.

x64>Ну так это как драйвер захочет так и покажет тебе, и на Win32-уровне в общем случае ничего ты не сделаешь.

Может я не правильно объяснил. Попробую по другому. Когда я захожу к себе в "Панель управления" -> "Сетевые подключения", то вижу 3 сетевых подключения
1) Имя — "Подключение по локальной сети", Имя устройства — "Intel(R) 82566DM Gigabit Network Connection"
2) Имя — "CTRL", Имя устройства — "Intel(R) 82566DM Gigabit Network Connection — VLAN : VLAN100"
3) Имя — "LAN", Имя устройства — "Intel(R) 82566DM Gigabit Network Connection — VLAN : VLAN2"
Все три подключения имеют состояние "Подключено".

GetAdaptersInfo возвражает только информацию о подключениях (2) и (3). Не понятно почему нет данных о подключении (1)
GetIfTable Возвращает тоже самое + информацию об интерфейсе "MS TCP Loopback interface"

Нужно получить:
1) информацию обо всех сетевых интерфейсах в системе
2) узнать какие сетевые интерфейсы соответствуют реальной сетевой карте
3) желательно узнать GUID данных интерфейсов

MAN>1) информацию обо всех сетевых интерфейсах в системе

Попробуй GetAdaptersAddresses().

MAN>2) узнать какие сетевые интерфейсы соответствуют реальной сетевой карте

Ты никогда не узнаешь этого в общем случае.

MAN>3) желательно узнать GUID данных интерфейсов

Начиная с Windows Vista можно получить больше информации:

GetAdaptersAddresses()
ConvertInterfaceIndexToLuid()
ConvertInterfaceLuidToGuid()

Здравствуйте, x64, Вы писали:

MAN>>1) информацию обо всех сетевых интерфейсах в системе

x64>Попробуй GetAdaptersAddresses().

MAN>>2) узнать какие сетевые интерфейсы соответствуют реальной сетевой карте

x64>Ты никогда не узнаешь этого в общем случае.

Через WMI я это уже сделал, только мне не нравится — несколько тормознуто.
Также через WMI выдаются все сетевые интерфейсы.

MAN>>3) желательно узнать GUID данных интерфейсов

x64>

x64>Начиная с Windows Vista можно получить больше информации:

x64>GetAdaptersAddresses()
x64>ConvertInterfaceIndexToLuid()
x64>ConvertInterfaceLuidToGuid()

Попробовал GetAdaptersAddresses с флагом Family=AF_UNSPEC, получил всё те же (2), (3) и "MS TCP Loopback interface".
Кстати в IP_ADAPTER_ADDRESSES.AdapterName получаю как раз искомый GUID.

Почему GetAdaptersAddresses не возвращает информацию о сетевом интерфейсе "Подключение по локальной сети" вроде ясно — данный интерфейс не имеет ip адреса (на нём не включен протокол TCP/IP).

MAN>>>2) узнать какие сетевые интерфейсы соответствуют реальной сетевой карте
MAN>Через WMI я это уже сделал, только мне не нравится — несколько тормознуто.

Неужто свойство (bool) Win32_NetworkAdapter.PhysicalAdapter работает? Или что-то другое?

MAN>Кстати в IP_ADAPTER_ADDRESSES.AdapterName получаю как раз искомый GUID.

GUID лучше из WMI получать, там отдельное свойство есть для этого.

MAN>Почему GetAdaptersAddresses не возвращает информацию о сетевом интерфейсе "Подключение по локальной сети" вроде ясно — данный интерфейс не имеет ip адреса (на нём не включен протокол TCP/IP).

Ну ты даёшь, чего ж ты хотел от GetAdaptersInfo(), если в подключении даже IP-протокола нет? :)

Здравствуйте, x64, Вы писали:

MAN>>>>2) узнать какие сетевые интерфейсы соответствуют реальной сетевой карте
MAN>>Через WMI я это уже сделал, только мне не нравится — несколько тормознуто.

x64>Неужто свойство (bool) Win32_NetworkAdapter.PhysicalAdapter работает? Или что-то другое?

Я сижу за Windows Server 2003, а надо, чтоб работало ещё и на XP.
PhysicalAdapter у меня не работает, т.к.

[msdn]PhysicalAdapter
Data type: boolean
Access type: Read-only

Indicates whether the adapter is a physical or a logical adapter. If True, the adapter is physical.

Windows Server 2003, Windows XP, Windows 2000, and Windows NT 4.0: This property is not available. [/msdn]

Я сделал так:
Select * From Win32_NetworkAdapter WHERE PNPDeviceID LIKE "PCI\\VEN_%"

MAN>>Кстати в IP_ADAPTER_ADDRESSES.AdapterName получаю как раз искомый GUID.

x64>GUID лучше из WMI получать, там отдельное свойство есть для этого.

Опять-таки не подходит, т.к.
[msdn]GUID
Data type: string
Access type: Read-only

Globally unique identifier for the connection.

Windows Server 2003, Windows XP, Windows 2000, and Windows NT 4.0: This property is not available.[/msdn]

MAN>>Почему GetAdaptersAddresses не возвращает информацию о сетевом интерфейсе "Подключение по локальной сети" вроде ясно — данный интерфейс не имеет ip адреса (на нём не включен протокол TCP/IP).

x64>Ну ты даёшь, чего ж ты хотел от GetAdaptersInfo(), если в подключении даже IP-протокола нет?
Ну да. А тогда чем?
Как, например, получает список всех сетевых интерфейсов WireShark или TcpDump?

MAN>Я сижу за Windows Server 2003, а надо, чтоб работало ещё и на XP.

Ну тогда да, не подходит, но вообще-то от Windows XP пора уже отходить потихоньку, реально устарело уже, особенно в сравнении с Windows 7.

MAN>Как, например, получает список всех сетевых интерфейсов WireShark или TcpDump?

Wireshark, насколько помню, тупо из реестра берёт список (путь я уже приводил выше).

Здравствуйте, x64, Вы писали:

MAN>>Я сижу за Windows Server 2003, а надо, чтоб работало ещё и на XP.

x64>Ну тогда да, не подходит, но вообще-то от Windows XP пора уже отходить потихоньку, реально устарело уже, особенно в сравнении с Windows 7.

На нашем предприятии с парком компьютеров более 1000 шт. растянется лет на 5 минимум.

MAN>>Как, например, получает список всех сетевых интерфейсов WireShark или TcpDump?

x64>Wireshark, насколько помню, тупо из реестра берёт список (путь я уже приводил выше).

Если у вас "слетела" сеть после лечения.

. Воспользуетесь программой WinsockFix (скачать в зависимости от системы)
Программа делает следующее:
1. Отключает все сетевые адаптеры.
2. Удаляет из реестра ключи Winsock и Winsock2, заменяя нужные параметры исходными значениями согласно "чистой" установке XP, чтобы запустить повторное построение службы Winsock, включая создание таблиц маршрутизации командой Netsh int ip reset resetlog.txt.
3. Разрешает работу сетевых адаптеров.
4. Проверяет файл HOSTS на правильность указателя localhost (обязан ссылаться на адрес 127.0.0.1).

Утилиты для восст./коррекции сетевых настроек

Мы не гарантируем 100% восстановление настроек после применения этих утилит. Желательно перед их применением записать настройки локальной сети для Вашего компьютера.

0. Возможности, заложенные в наших инструментах:
AVZ Файл - Восстановление системы.
Пункт 14. Автоматическое исправление настроек SPl/LSP
Выполняет анализ настроек SPI и в случае обнаружения ошибок производит автоматическое исправление найденных ошибок. Данную микропрограмму можно запускать повторно неограниченное количество раз. После выполнения данной микропрограммы рекомендуется перезагрузить компьютер. Обратите внимание ! Данную микропрограмму нельзя запускать из терминальной сессии
Показания к применению: После удаления вредоносной программы пропал доступ в Интернет.

Показания к применению: После удаления вредоносной программы пропал доступ в Интернет и выполнение микропрограммы "14. Автоматическое исправление настроек SPl/LSP" не дает результата.

Пункт 18.Полное пересоздание настроек SPI
Выполняет резервное копирование настроек SPI/LSP, после чего уничтожает их и создает по эталону, который хранится в базе.
Показания к применению: Тяжелые повреждения настроек SPI, неустранимые скриптами 14 и 15. Применять только в случае необходимости !

1. Стандартное средство от MicroSoft: netsh
Описание взято с сайта производителя

ВВЕДЕНИЕ
Поскольку стек протоколов TCP/IP относится к ключевым компонентам Windows XP, возможность удаления протоколов TCP/IP не предусмотрена. Если при просмотре компонентов сетевого интерфейса выделить элемент "Протокол Интернета (TCP/IP)", кнопка "Удалить" остается недоступной. В некоторых случаях оптимальным решением является переустановка стека IP. С помощью программы NetShell стек протоколов TCP/IP можно вернуть в исходное состояние (состояние сразу после установки операционной системы). Соответствующие сведения представлены в данной статье.

NetShell (netsh) - это интерфейс сценариев командной строки, которая предназначена для настройки и отслеживания доступа к сети в ОС Windows XP. Программа предоставляет пользователю интерактивный интерфейс для взаимодействия с сетевой оболочкой.

В Windows XP в контексте протокола Интернета для программы NetShell предусмотрена команда reset. Выполнение этой команды приводит к перезаписи параметров реестра, которые используются стеком протоколов TCP/IP, что равнозначно его удалению и повторной установке.

Использование команды
netsh int ip reset [имя_файла_журнала] Чтобы выполнить команду вручную, необходимо указать имя файла журнала, в который будут записываться действия, выполняемые командой netsh. Так, запуск одной из команд, которые приведены в разделе "Примеры" этой статьи, приводит к сбросу стека протоколов TCP/IP и записи выполненных действий в файл Resetlog.txt (в первом случае файл журнала создается в текущей папке, а во втором - по указанному в команде адресу). Если журнал с таким именем уже существует, новый журнал будет добавлен в конец файла.

Предупреждение. Выполнение команды netsh winsock reset может отрицательно повлиять на работу программ, осуществляющих доступ в Интернет или отслеживающих данные в Интернете: антивирусных программ, брандмауэров и прокси-клиентов. В случае неправильной работы одной из этих программ после использования рассматриваемого метода переустановите программу, чтобы восстановить ее работоспособность.
Примеры команд:

Имеет возможность создания backup текущих системных установок
Отключает все сетевые адаптеры.
Удаляет из реестра ключи Winsock и Winsock2, заменяя нужные параметры исходными значениями согласно "чистой" установке XP, чтобы запустить повторное построение службы Winsock, включая создание таблиц маршрутизации командой Netsh int ip reset resetlog.txt.
Разрешает работу сетевых адаптеров.
Проверяет файл HOSTS на правильность указателя localhost (обязан ссылаться на адрес 127.0.0.1).

Запустить.
Нажать Reg-Backup для сохранения настроек реестра. (не обязательно)
Нажать Fix
Перезагрузиться.
Восстановить сетевые настройки.

Ссылка на скачивание будет добавлена позже.

Описание на английском взято с сайта разработчика:

LSP-Fix is a free Windows utility to repair a loss of Internet access associated with certain types of software. This type of software, known as a Layered Service Provider or LSP, typically handles low-level Internet-related tasks, and data is passed through a chain of these programs on its way to and from the Internet. However, due to bugs in the LSP software or deletion of the software, this chain can get broken, causing the Internet connection to become inaccessible.

Теперь о нескольких утилитах, применяемых для коорекции MTU. Что это такое и с чем это едят, пригодится ли это Вам в работе смотрите описание ниже.

Основная идея заключается в том, что бы определить, какой максимальный размер tcp-пакета маршрутизатор провайдера может пропустить не фрагментируя его для дальнейшей передачи и установить своё значение MTU меньшим (в идеале равным) значению MTU маршрутизатора. В чем тут фишка. Дело в том, что возможно в силу каких-либо причин на маршрутизаторе установлен размер MTU меньше, чем типичный для ethernet, а у вас используется значение по умолчанию (1492). Если MTU маршрутизатора провайдера к примеру 576 (стандартное для ppp-соединений значение), а у вас 1492, и вы отправляеет в сеть пакет размером 1400 байт (к примеру), то до маршрутизатора он дайдет 1 пакетом, а дальше будет разбит на 3 (1400\576) и отправлен далее по маршруту, а там в свою очередь MTU может быть еще ниже и пакет опять будет разбит. А теперь представьте, что во время передачи между какими-либо маршрутизаторами один из этих фрагментов потерялся (потеря пакета) и соответствеено передача остальных двух смысла уже иметь не будет, вам сообщается, что при передаче произошла ошибка и нужно повторить. Т.е. терятся время и трафик. А если мы сделаем размер уходящего от нас пакета равным минимальному MTU на пути его следования, то и разбивать его маршрутизатору не придется, а значит и шанс на ошибку ниже и времени на достоверную передачу тоже нужно меньше -> мы выигрываем в скорости.

3. Смотрим результат, если видим:
"Требуется фрагментация пакета, но установлен запрещающий флаг"
то уменьшаем размер пакета с 1492 в меньшую сторону до тех пор пока не пойдут привычные ответы. Это и есть подходящее для вас значение MTU. Магическое число 1492 взято не с потолка, это величина получается если из максимального размера фрейма ethernet`a (1500) вычесть 8 байт отводимых под заголовок и получится 1492 байта для полезной нагрузки, а меньше оно может оказаться если по пути следования пакета встречаются не только ethernet каналы, но и каналы использущие другие протоколы канального уровня, где размер фрейма другой (меньше) или фрейм инкапсулируется.

4. Открываем ветку реестра:

Обнаруживаем там много включений вида 0000, 0001, 0002 и так далее. Просматриваем их все, пока не найдем ключ с описанием вашего сетевого адаптера (например у меня "Marvell Yukon 88E8056 PCI-E Gigabit Ethernet Controller") и смотрим значение параметра NetCfgInstanceId

5. Перемещаемся в ветку:

и находим там раздел с именем соответствующим NetCfgInstanceId найденному ранее. Т.е. изменения MTU каснутся только этого сетевого подключения.

6. Если есть параметр MTU, меняем его на полученное вам в результате экспериментов в пункте 3. число (в десятичном виде), если же этого параметра нет - создайте его сами (тип DWORD).

. (Если - создаем, тип DWORD). Его значение определяется исходя из следующих соображений. Величине MTU ставится в соответствие некоторое значение MSS (Maximum Segment Size, максимальный размер сегмента (размер данных, уложенных в MTU)). Величина MSS должна быть меньше MTU на 40 байт заголовка. MSS = MTU - 40. TcpWindowSize рекомендуется ставить мимимум в четыре раза больше величины MSS. TcpWindowSize = MSS * 4. (в моём случае MTU был равен 1464, значит TcpWindowSize должен быть (1462-40)*4 = 5688. Но имейте в виду, что это изменение каснется абсолютно всех подключений (сетевых, dial-up) по умолчанию величина TcpWindowSize 8760 (т.е. расчитан на 6 стандартных фреймов ethernet`а) и уменьшать его следует только в том случае, если канал очень не надежен и значение потерь пакетов до хотя бы до ближайшего маршрутизатора около 16%, что в условиях adsl крайне редко (а вот для dial-up`a очень даже часто). И уменьшенее даст более уверенную передачу. Уменьшать соответственно кратно величине TcpWindowSize. Если канал очень надежный, то казалось бы можно увеличить размер буфера, это можно сделать, но не стоит слишком увлекаться иначе можно только навредить. Величина вплоть до TcpWindowSize * 12 для хорошего канала вполне приемлема.

8. Можно перезагружаться.

ЗЫ Кстатит говоря, пытаться проверять действие этих манипуляций простыми пингами некорректно, так как размер пакета icmp-echo намного меньше MTU. Ощутить разницу можно если до и после изменения MTU замерить скорость скачивания с какого-нибудь ближайшего хоста. Особенно эффект виден на медленных линках (dial-up) но и на adsl тоже вполне ощутим

Эти манипуляции полезны тем, кто сидет на VPN-подключениях, а также для тех, кто имеет провайдера, который прижимает траффик. Если нет желания данные манипуляции проводить руками, то имееются в сети несколько утилит, о которых речь пойдет дальше.

1. SetMTU от Cisco

Как пользоваться видно на скриншоте. Выбираем адаптер и внизу выставляем соотв. значение MTU. После необходимо перезагрузиться.

Почему не обнаруживается файл

Пользователи сходятся во мнении, что данную проблему вызывает работа антивируса. Точнее, сам вирус, следы которого обнаружены, а зараженный им файл удален либо перемещен в карантин. Также ошибка появляется при неправильной установке либо деинсталляции программ. Конечно, всегда можно переустановить Windows, но это крайняя мера, никому ведь не хочется сносить рабочие программы. Поэтому сначала применим менее категоричные меры – рассмотрим различные типы файлов и определим пути исправления ошибки.

Решение проблемы при невозможности открытия exe-файлов

Существует несколько способов решения проблемы открытия exe-файлов. Рассмотрим их по порядку.

Переустановка софта

Если файл удален антивирусной программой, то нет никакой необходимости вытаскивать его из хранилища, не зря же он был туда перемещен. Даже если мы сможем достать его оттуда, он уже поврежден и не сможет функционировать так, как нужно.

В этом случае выход – полная деинсталляция и установка программы, которая не может запуститься. Удалять софт лучше всего не через стандартные средства Windows, а при помощи специального программного обеспечения – Revo Uninstaller либо AIDA64. Они не только деинсталлируют проблемную программу, но и “подчистят” все ненужные остаточные файлы.

Изменение настроек Steam

Кликаем на папке Steam ПКМ и выбираем “Свойства”;
переходим на вкладку “Безопасность”;
в первом окошке “Группы или пользователи” выбираем строку “Пользователи”;
если по какой-либо причине эта строка отсутствует, то чуть ниже нажимаем “Изменить” и в следующем окне “Добавить”;

после успешной проверки имени кликаем на ОК;
убеждаемся, что для выбранного пользователя во всех пунктах “Разрешить” проставлены галочки и кликаем ОК;

дожидаемся окончания ввода всех внесенных изменений и заново запускаем игру.

Редактор реестра и Диспетчер задач в помощь

Можно попробовать и такой способ. Нажимаем ПКМ на Пуск (в Windows 10) и ищем строку “Выполнить”.
Вводим regedit. Открывается Редактор реестра.
Проходим следующий путь – HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run – ищем здесь проблемную строку и удаляем ее.

Решение проблемы с открытием Excel

Ошибка в редакторе локальной групповой политики

В данном случае действуем двумя методами:

ищем другой путь, где нам не понадобятся функции редактора (они помогают легче управлять системными настройками через ввод изменений в реестр);
переустанавливаем ОС до корпоративной, профессиональной и другой версии, имеющей узкую специализацию.

Читайте также: