Sfc не является внутренней или внешней командой исполняемой программой или пакетным файлом

Обновлено: 05.07.2024

Поговорим о последствиях действий некоторых вирусов, приводящих, при запуске программ из командной строки, к ошибкам следующего плана:

ping не является внутренней или внешней командой, исполняемой программой или пакетным файлом

На месте ping, в командной строке, с таким же успехом может быть написана любая системная программа (ipconfig, tracert, regedit и т.д.). Честно говоря, о простом решении сразу не подумал и для начала решил накатить обновление SP3 на Windows XP. Результат был нулевым.

В моем случае, PATH содержала совершенно левый зараженный каталог. На чистом Windows XP, переменная PATH имеет следующее значение:

Для внесения изменений необходимо:

Если считаете статью полезной,
не ленитесь ставить лайки и делиться с друзьями.

Комментариев: 2

Все проще. Запустите CMD от имени Администратора

Все проще. Запустите CMD от имени Администратора

При попытке открыть какую-либо команду через окно служебной программы или консоль, вы сталкиваетесь с ошибкой – «Имя файла» не является внутренней или внешней командой, исполняемой программой или пакетным файлом. Система упрямо не открывает файл по каким-то причинам и этот факт очень раздражает. Причиной этого может быть один из нескольких вариантов: неправильно указан путь к файлу и отсутствие компонента в системе вообще, т.е по указанному адресу его не существует.


Ошибка в системной переменной

Основные причины, по которым появляется ошибка «не является внутренней или внешней командой»

Как уже было сказано, одна из причин заключается в неправильном указании пути к открываемому файлу. Обычно путь к файлу прописан в переменной «Path» в системе, должен быть указан строгий путь к директории, в котором размещены нужные файлы. Если имеются какие-то ошибки в настройках при указании пути в переменной, либо при указании имени файла, то система будет выдавать именно такую ошибку – «имя файла» не является внутренней или внешней командой, исполняемой программой.

Первым делом необходимо указать точный путь переменной «Path» операционной системе, чтобы не возникало ошибок при открытии файла. Для этого нужно наверняка знать расположение папки. К примеру, обратимся к программе, которая в дальнейшем будет работать с исполняемым файлом в определенной папке.

Переменная «Path» — это переменная операционной системы, которая служит для того, чтобы найти указанные исполняемые объекты через командную строку или терминал. Найти ее можно в панели управления Windows. В новых версиях Виндовс и других ОС указание вручную обычно не требуется.


Системная переменная Path

Указываем правильный путь в переменной path на ОС Windows 7

Чтобы правильно указать путь необходимо знать точное расположение файла. Если файл программы, который нужно открыть лежит на диске в С:Program FilesJavajdk 1.8.0.45in, тогда этот путь нужно скопировать и указать в системной переменной для последующего открытия.

  1. Далее нам понадобиться рабочий стол, наводим мышь на «Мой компьютер» и в контекстном меню выбираем «Свойства».
  2. Нажимаем «Дополнительные параметры» слева и выбираем пункт «Переменные среды».
  3. В открывшемся окне ищем строку «Path» нажимаем на нее и вставляем скопированные путь сюда.
  4. Действие нужно подтвердить кнопкой «Ок». Компьютер желательно перезагрузить, чтобы настройки точно вступили в силу. Откройте консоль и вбейте нужную команду. Ошибки быть не должно.


В том случае, если ошибка будет появляться снова, попробуйте перенести программу в рабочие директории диска с установленной операционной системой, например /System32. С этой директорией Виндовс работает чаще.

Также ошибки возникают из-за отсутствия компонентов программы. Устранить их можно дополнив нужными. Для примера возьмем компонент «Telnet». Чтобы его включить, перейдите:

  • На «Панель управления».
  • Дальше выберите «Включение и выключение компонентов».
  • Из списка выбираем «Клиент Telnet», напротив ставим галочку и нажимаем «Ок».
  • Компонент должен работать и ошибок возникать больше не должно.

Признаюсь, с этой статьёй немного запоздал (лет эдак на дцать, не менее), однако часто в других статьях я отсылаю читателей в никуда или в “общеподготовительные” мануалы по работе с этой полезной системной утилитой. Между тем она является одним из главных и первоначальнейших инструментов не только диагностики состояния системы, но и исправления ошибок в Windows. С появлением Windows 10/8 настольной версии этот инструмент дополнился ещё одним (причём предварительным: если у вас, к примеру, Window 10 – начните именно со средства проверки DISM ) вариантом сравнения имеющихся системных файлов с шаблонными, но, так как обладатели Windows 7 этого инструмента лишены… Знакомьтесь, кто ещё не в курсе: утилита sfc /scannow она же SFC.exe.

Что такое sfc /scannow?

Практически – это программа, которая, как и многие из других системных располагается в папке

C:WindowsSystem32

и является неотъемлемой частью механизма защиты ресурсов Windows, который охраняет реестровые ключи и отдельные параметры от поражения (равно как и критически важные системные файлы). Если только после запуска утилиты та обнаружит изменения в этих файлах или параметрах, она – утилита – приступит (по команде пользователю) к исправлению ситуации. Для этого сама Windows всегда держит кэшированную копию файлов в системной папке с одноимённым названием. Есть желание – взгляните:

System File Checker = Sfc.exe = sfc /scannow

Для запуска проверки системных файлов откройте cmd от имени админа:


В окне консоли пишем знакомую команду:


Утилита проверит нужное, в случае обнаружения несоответствия будет проведена подмена после перезагрузки.

Что sfc /scannow умеет?

Справка по утилите русифицирована, так что вам стоит лишь набрать:


Результаты проверки sfc /scannow

  • Для завершения восстановления системы требуется перезагрузка. Перезапустите систему Windows и выполнитеsfcещё раз:


Проблема, которую вы пытаетесь разрешить, лежит, по-видимому, в иной плоскости.

  • Защита ресурсов Windows обнаружила поврежденные файлы и успешно их восстановила.


Наиболее частое повреждение файлов – либо неправильная работа (а чаще удаление) сторонних программ в/из Windows, а также сбои в работе жёсткого диска (см. “Плохие секторы жёсткого диска“). И утилита частично эти проблема разрешила, подменив на исходные. Настоятельно рекомендую взглянуть на лог утилиты по адресу в консоли – там могут быть интересные детали для разрешения вероятных в последующем ошибок:

C:WindowsLogsCBS CBS.log

    Защита ресурсов Windows обнаружила поврежденные файлы, но не может восстановить некоторые из них. При этом система отправляет вас в лог программы за подробностями. Реже, но также встречается ещё более категорическое


Большинство пользователей подобное “заявление” ставит в тупик. Я могу предложить вам несколько вариантов действий:

  • Иногда камнем преткновения является аудиослужба Windows, причём в Windows 10 это сплошь и рядом. Откройте консоль cmd от имени администратора и введите две последовательные команды:
  • Сразу проверяем готовность соответствующей службы. Набираем (в строке Найти/Выполнить) команду на открытие консоли

Ищем в списке служб Установщик модулей Windows. Тип запуска: Вручную.

  • Проверьте, на месте ли папки (и не пусты ли они) PendingDeletes и PendingRenames в директории

C:WindowsWinSxSTemp



  • Повторите операцию по запуску sfc /scannow, но уже в Безопасном режиме. Запуск Windows в щадящем режиме можно запланировать прямо сейчас из другой системной утилитыmsconfig:

Если результат окажется тем же , возможно попробовать сдвинуть запуск утилиты восстановления ещё ближе к запуску Windows: на этот раз sfc /scannow может проверить файлы ещё до загрузки системы. Однако для этого вам потребуется загрузочный носитель с той копией Windows, которая у вас установлена:


вставьте загрузочный диск/флешку


удостоверьтесь, что система на жёстком диске видна с флешки/дисковода

Обратите внимание на букву Локального диска (D) в столбце Папка: запомните её!


ищем консоль в параметрах восстановления

и вводим команду на офлайн проверку вашей Windows:

sfc /scannow /offbootdir=d: /offwindir=d:windows

где d – имя локального диска на компьютере/ноутбуке. Обратите внимание: эта команда позволит вам проверять внешние носители с установленной Windows.

Читаем логи и проверяем подробности работы sfc

Путь расположения лог-файла sfc.exe вы уже знаете. Чтобы его не искать в терниях системы, по аналогии с официальной справкой по sfc.exe я предлагаю вам набрать такую команду в консоли от имени админа:

На Рабочем столе появится текстовый файл, в котором вы найдёте подробности того, с чем команда sfc /scannow столкнулась:


Большинство записей (а в “холостом” режиме работы утилиты) в логах должны выглядеть так:


Sfc.exe традиционного проверяет файлы поблочно по 100 штук. Этих самых файлов немало, и потому строк в логах также много. Информация выводится по типу:

Дата Время Тип Режим доступа Подробности

А вот и проблема “…но не может восстановить некоторые из них“:


для увеличение изображения откройте его в новой вкладке

где самые частые содержания в строках такие:

  • beginning verifiyng … – проверка файлов в текущем блоке начата
  • cannot repaire member file… – не могу починить файл имя.расширение
  • file is missing – файл отсутствует

hash mismatch – хэш-код файла не соответствует системному (“родному”)

this component was referenced by… – компонент изначально относился к… (на него ссылался…)

verifying 100 components – проверка 100 составляющих блока завершена успешно

repairing corrupted file – ремонт повреждённого файла

repair complete – ремонт закончен

Пробуем восстановить файл вручную.

Восстановление файлов из списка логов sfc вручную .

В Windows 7 придётся попотеть. Сначала получите к нему доступ и права на работу с файлом:

takeown /f полный-путь-к-файлу/папке

icacls полный-путь-к-файлу/папке /GRANT ADMINISTRATORS:F

Например, система обнаружила повреждение файла System.Management.Automation.dll и не смогла его починить.


откройте в новой вкладке

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


Консоль, скорее всего, выдаст несколько вариантов (заметьте, что нередко в Windows папка таковой не является – это может быть всего лишь системный узел или вид “с нескольких ракурсов”). Так что, опираясь на логи, откиньте ненужные результаты. Если всё ещё не удаётся его вычленить, используйте повторную проверку каждого из “подозреваемых” с помощью той же sfc.exe в формате (смотрите справку):

sfc /verifyfile=полный-путь-к-файлу

Остаётся обнаружить и заполучить искомый файл. Для того есть несколько способов:

  • взять у друга с такой же Windows (попросить на добропорядочном форуме)
  • скачать аккуратно из сети, не нарвавшись на бяку
  • забрать с установочного диска/флешки/образа (тогда проще уж просто запустить sfc.exe с загрузочного диска)

После того, как вы утвердились в выборе, замените повреждённый файл на обновлённый командой в cmd в формате:

copy полный-путь-к-хорошему-файлу полный-путь-к-плохому-файлу

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

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