Как заменить файл в папке windows winsxs

Для восстановления работоспособности Windows существует масса способов – точки отката, бэкап, бэкап и откат её реестра, восстановление целостности её файлов, переустановка Microsoft Visual C++ и прочих системных компонентов. Но только предварительно сделанный бэкап системы можно считать панацеей, универсальным «лекарством» от всех возможных проблем. Как быть, если нужно восстановить системные файлы, а у нас ни бэкапа нет, ни инструмент восстановления системных файлов не работает?

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

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

это значит, что повреждён или удалён файл diskmgmt.msc – файл запуска непосредственно утилиты управления дисками. В этом случае мы можем попытаться решить проблему путём восстановления целостности системных файлов, т.е. запустить в командной строке известную команду sfc/scannow. Но этот механизм системы не всегда даёт положительные результаты и часто завершается уведомлением о невозможности восстановления.

В таком случае далее нужно предпринимать действия по восстановлению хранилища системных ресурсов и потом снова запускать sfc/scannow. Ручная замена проблемных системных файлов – более топорная операция, плюс к этому, требующая, как упоминалось, чёткого понимания, какие именно файлы по какому пути нужно заменять. Но если эти файлы и пути известны, то это более быстрое и надёжное решение проблемы.

Что для этого необходимо? Нам понадобится установочный ISO нужной версии Windows. Открываем его архиватором 7-Zip.

Открываем папку «sources», далее – «install».

Внутри файла «install» выбираем папку с тем или иным порядковым номером. Порядковые номера – это индексы редакций Windows. Если, например, в нашем случае нужно восстановить файл diskmgmt.msc, нам без разницы редакция, эта системная утилита есть в любой редакции Windows. Поэтому мы просто выберем редакцию Pro, она идёт под номером 4.

Но если файл нужного системного компонента есть только в определённой редакции, например, только в Pro, то необходимо указывать индекс конкретно этой редакции. А узнать индексы редакций в составе дистрибутива можно с помощью командной строки. Нужно подключить установочный ISO для отображения в системе и прописать в команде Dism путь к файлу install на борту этого ISO, вот так:

Dism /Get-WimInfo /WimFile:J:sourcesinstall.wim

Здесь вместо буквы J каждый должен подставить свою букву диска подключённого ISO. И если файл install имеет формат не «.wim», а «.esd», то, соответственно, в конце команды необходимо указать этот формат. В ответ на эту команду получим справку о соответствии индексам редакций Windows.

Определившись с редакцией, распаковываем нужный системный каталог. В нашем случае необходимо заменить файл утилиты diskmgmt.msc, следовательно, мы распаковываем каталог «Windows». Кликаем его и жмём «Extract».

Указываем путь распаковки.

И после распаковки ищем файл утилиты diskmgmt.msc.

При поиске обнаружилось несколько дубликатов diskmgmt.msc – в оригинальном месте хранения файла, в хранилище системных ресурсов (т.е. в папке WinSxS), в других системных подкаталогах. Мы берём файл, находящийся по исходному его пути хранения, в папке «System32». Копируем его.

И помещаем этот файл в папку «System32» внутри каталога «Windows» на диске С текущей системы.

Подтверждаем вставку или замену файла.

Вот и всё.

***

Мы рассмотрели простейший пример замены системных файлов вручную, чтобы осветить сугубо механизм этой процедуры. Необходимо понимать, что не со всеми системными файлами процесс замены произойдёт так вот просто, могут возникнуть трудности. Некоторые файлы Windows в активном состоянии не захочет заменять, и потребуется либо получение прав TrustInstaller, либо работа с LiveDisk. Также нужно учитывать, что после замены некоторых файлов, например, файлов активных системных процессов, прежде лицезрения результата проделанной работы, необходимо перезагрузить Windows.

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

В данной статье описан метод ручного восстановления хранилища компонентов Windows. Подобные описанному в данном посте методу восстановления работоспособности компонентной модели рождаются вовсе не от хорошей жизни, появляются они под воздействием многочисленных проблем с компонентной моделью операционной системы. Во многих случаях официальные подходы к восстановлению хранилища компонентов не помогают, помимо этого отсутствует какая бы то ни было внятная официальная документация, из чего складывается недопонимание структуры и принципов работы компонентной модели. При подобном отношении со стороны разработчиков абсолютно любые средства вернуть компонентную модель в работоспособное состояние приемлемы!! Как показывает практика, при всех стараниях разработчиков из Microsoft предоставить возможность конечному пользователю системы устранять возникающие проблемы в автоматическом режиме (при помощи специальных утилит), никогда полностью не будут исключены ситуации, в которых эти самые автоматизированные средства будут давать сбои. Причина тут кроется в симбиозе старых механизмов операционной системы и необходимостью постоянного внедрения новых (не оттестированных) технологий, должным образом не заботясь о приведении в надлежащее состояние всех связанных (участвующих) компонентов, что, в свою очередь, порождает огромное количество проблем.
В данной публикации речь пойдет о восстановлении компонента прямой заменой файлов. Фактически методом предусматривается прямая ручная замена поврежденных [кривых, неправильно функционирующих] файлов, являющихся причиной возникновения ошибок, а так же частей реестра. По этой методике, исправные файлы и соответствующие ключи реестра копируются с работоспособной станции-донора. Слабое место метода в том, что для реализации требуется наличие находящейся на том же уровне обновлений нормально функционирующей операционной системы той же версии/ревизии.
В процессе повествования постараемся описать общую методику, тем не менее, в статье будут присутствовать частные случаи из практики.

Определение виновника проблемы

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

Ошибки в лог-файлах

Основной и пожалуй самый информативный источник о проблемах, связанных с компонентной моделью Windows — лог-файлы системных утилит обслуживания. Чаще всего ошибки выявляются при выполнении обновления системы, то есть установки обновлений/исправлений. Проявляются они в виде разнообразных ошибочных статусов в интерфейсе Центра обновления и окон обновлений. Тем не менее, сам по себе статус не малоинформативен, а вот более детальная информация попадает в специализированные файлы журналов. В данном разделе мы опишем методики поиска источников проблем в лог-файлах результатов работы системных утилит SURT/DISM/SFC/SFCFix, которые работают с хранилищем компонентов и системными каталогами а предмет восстановления целостности компонентной модели системы.

CheckSUR.log / DISM.log

Правила поиска ошибок в файлах %Windir%LogsCBSCheckSUR.log или %Windir%LogsDISMDISM.log:

Статусы (первый символ):

• (f) — фатальная ошибка;
• (w) — предупреждение;
• (fix) — указывает на ошибку, которая была исправлена; выводятся в виде отдельной строки сразу за строкой со статусом (f);

Оставшаяся часть строки содержит имя поврежденного файла и код ошибки.
В конце файла можно видеть секцию Unavailable repair files:, которая группирует все файлы, которые нужно будет заменять.

CBS.log

Несколько вариантов поиска ошибок в лог-файле %WinDir%LogsCBSCBS.log:

• Производим поиск строк, содержащих ключевое слово Error (с пробелом ДО или ПОСЛЕ). В их окружении можно найти указание на конкретные ошибки;
• Выполняем команду

  findstr /c:»[SR]» %windir%logscbscbs.log > c:sfcdetails.txt

  в результате чего в корне диска C: будет создан файл sfcdetails.txt, включающий лишь строки исходного файла, содержащие префикс [SR] (содержащие информацию об ошибках).

1: отсутствующие компоненты

В обрамлении видно строки, содержащие ключевые слова Cannot repair member file.. указывающие на то, что:

• содержимое файла не соответствует содержимому хранилища для файла и WRP пытается его восстановить, тем не менее..
• ..WRP не может восстановить файл описанного в строке компонента, потому что записи в реестре о нем присутствуют, а вот сам файл отсутствует в хранилище, о чем недвусмысленно намекает фрагмент строки ..file is missing.

Ниже по тексту можно найти статус STATUS_OBJECT_NAME_NOT_FOUND, указывающий на отсутствие подкаталога. В нашем случае, как видно из отчета, повреждению подверглась целая иерархия компонента, состоящая из подкаталогов и файлов, размещавшаяся в каталоге C:WindowsWinSxSamd64_prnbr002.inf_31bf3856ad364e35_6.1.7600.16385_none_49c93aa2c4304e9e. Заглянув в целевой каталог, я убедился, что он действительно пуст, а вот что за событие/действие удалило его содержимое, остается только гадать, хотя подобные инциденты в Windows-системах сплошь и рядом.
2: отсутствие манифеста

Ключевые слова, на которые в данном случае стоит обращать внимание:

• Manifest hash for component .. does not match expected value.
• Unable to load manifest for component ..

Из чего следует, что в данном случае возникла проблема с файлом wow64_microsoft-windows-directshow-core_31bf3856ad364e35_6.1.7601.24382_none_0f268a5b523efde9.manifest, который является манифестом и располагается в поддиректории %SystemRoot%WinSxSManifests. При более близком изучении было выяснено, что указанный файл почему-то нулевой.
3: попытка удаления отсутствующего компонента
При попытках установки обновления безопасности мы можем столкнуться со следующей проблемой:

Судя по всему установщик ругается на попытку удаления отсутствующего компонента amd64_microsoft-windows-w..lient-aux.resources_31bf3856ad364e35_7.6.7601.23775_ru-ru_306f57c17eac5f89 из пакета Package_846_for_KB4019265~31bf3856ad364e35~amd64~~6.1.1.3.4019265-2966_neutral_LDR. Сам компонент оказался на месте вместе со собственным манифестом, поэтому не понятно что же не нравится стеку обслуживания. Тем не менее что-то с этим пакетом явно не так.

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

Часто ошибки наблюдаются пользователем визуально, в виде статусов ошибок в окне Центра обновления Windows, но иногда их можно увидеть в автономных информационных окнах. Например, отказ запуска множества исполняемых системных образов может выражаться в постоянно всплывающих окнах, в заголовке которых можно видеть «<имя_образа> (в контексте которого произошел сбой) — ошибочный образ», а в информационной части текст ошибки: X:XXXXXXxxxxxxxx.dll либо не предназначен для выполнения под управлением Windows или содержит ошибку. Попробуйте переустановить программу с помощью исходного установочного носителя или обратитесь к системному администратору или поставщику программного обеспечения за поддержкой:

В английских версиях в заголовке можно увидеть «<filename> — bad image», а описание звучит как: «<filename> is either not designed to run on Windows or it contains an error. Try installing the program again using the original installation media or contact your system administrator or the software vendor for support.» Часто сообщение в окне дополняется специфической деталью сбоя, например кодом ошибки: «Error status 0xc000012f».

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

В данном случае, как вы можете видеть на снимке экрана выше, у нас повреждена библиотека с именем ncrypt.dll, относительно неё мы и поведем дальнейшее повествование.

Тем не менее, в ваших случаях для выявления виновника сбоя потребуется исследовать лог-файл %WinDir%LogsCBSCBS.log и составить список проблемных файлов. И при не столь очевидных намеках на источник проблемы всегда начинайте исследование сбоя с анализа данного лог-файла.

Восстановление файлов

На предыдущем шаге мы определились в виновником ошибки, то есть определили имена поврежденных/удаленных файлов:

• Если мы наблюдаем ошибку в виде информационного окна в графическом интерфейсе, то виновником обычно является модуль, имя которого фигурирует в тексте (в примере выше: ncrypt.dll). В этом случае мы будем менять все без исключения ревизии проблемного файла;
• Если мы производим разбор лог-файлов отчетов сервисных утилит (CBS/DISM/CheckSur/SFCFix), то виновник(и) проблемы обычно предстают перед нами в виде списка конкретных файлов компонентов или обновлений;

Давайте в этом разделе опишем метод восстановления компонента прямой заменой файлов подробнее, разбив весь процесс на подразделы, подробно описывающие шаги.

Поиск рабочих экземпляров файлов

На этом этапе нам необходимо найти рабочие копии поврежденных или отсутствующих файлов. Существует несколько основных подходов по нахождению рабочих копий:

1. Скопировать файлы с аналогичной, полностью работоспособной системы той же версии/редакции:
• при помощи поиска (в проводнике, или любым специализированным средством типа Far/Total Commander) по системному разделу (обычно C:) находим все каталоги, содержащие в своем названии искомую маску/имя (для случая выше: *ncrypt*). Сокращенный вывод:

  . . . C:Windowswinsxsx86_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.24417_none_6072150268f96612 C:Windowswinsxsamd64_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.18741_none_bbe0d7630856b4a1 C:Windowswinsxsx86_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.24408_none_607de53868f06378 C:Windowswinsxsamd64_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.18812_none_bc024957083d774c C:Windowswinsxsx86_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.24387_none_602663a869322c82 C:Windowswinsxsamd64_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.18869_none_bbd33bc1085fb462 C:Windowswinsxsx86_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.24384_none_602362ca6934e07d C:Windowswinsxsamd64_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.18923_none_bbf87b9b0844a9bb C:Windowswinsxsx86_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.24357_none_6046d36c6919d8af C:Windowswinsxsamd64_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.18933_none_bbedabaf084cc5ac C:Windowswinsxsx86_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.24335_none_605a72b0690b6e1f C:Windowswinsxsamd64_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.18939_none_bbf3ad6b08475db6 . . .

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

  Можно произвести замену файлов и в системных каталогах, таких как C:Windowssystem32. Хотя делать это не обязательно, поскольку файлы там представляет собой жесткие ссылки на оригиналы в хранилище WinSxS, а они восстанавливаются автоматически при проверке через sfc).

• в ходе того же самого поиска, кроме директорий, выявляются и файлы, которые располагаются по следующим путям (вывод сокращен):

  . . . C:WindowswinsxsManifestsamd64_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.24408_none_bc9c80bc214dd4ae.manifest C:WindowswinsxsManifestsx86_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.18741_none_5fc23bdf4ff9436b.manifest C:WindowswinsxsManifestsamd64_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.24387_none_bc44ff2c218f9db8.manifest C:WindowswinsxsManifestsx86_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.18812_none_5fe3add34fe00616.manifest C:WindowswinsxsManifestsamd64_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.24384_none_bc41fe4e219251b3.manifest C:WindowswinsxsManifestsx86_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.18869_none_5fb4a03d5002432c.manifest C:WindowswinsxsManifestsamd64_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.24357_none_bc656ef0217749e5.manifest C:WindowswinsxsManifestsx86_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.18923_none_5fd9e0174fe73885.manifest C:WindowswinsxsManifestsamd64_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.24335_none_bc790e342168df55.manifest C:WindowswinsxsManifestsx86_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.18933_none_5fcf102b4fef5476.manifest C:WindowswinsxsManifestsamd64_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.24308_none_bc9c7ed6214dd787.manifest C:WindowswinsxsManifestsx86_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.18939_none_5fd511e74fe9ec80.manifest . . .

2. Разархивировать требуемые файлы из пакета обновления.
   • Для этого определяем имя обновления KBXXXXXXXX, в состав которого входят обнаруженные на предыдущем шаге файлы, из Центра загрузок Майкрософт или Центра обновления Майкрософт или попросту используя поиск.
   • Распаковываем содержимое выкачанного только что пакета обновления (.msu) в произвольную (временную) директорию:

     expand -F:* windows6.1-kb4019265-x64_c21fb9314da54cf6bd7972581da3159535f55aec.msu c:temp4019265

   • после чего в целевой директории мы увидим следующее содержимое:
     • .xml-файл — метаданные-описатели пакета обновления (.msu). Утилиты установки используют .xml-файл при выполнении установки в автоматическом режиме;
     • .cab-файл — архив с данными (полезная нагрузка) обновления;
     • *-pkgProperties.txt — файл с описанием свойств пакета (дата релиза, архитектура, тип, ссылка на KB и прочее);
     • WSUSSCAN.cab — файл оффлайн-сценария проверки;
   • затем выполняем еще одну команду, теперь уже над только что распакованным .cab-файлом:

     expand -F:* windows6.1-kb4019265-x64.cab c:temp4019265extracted

   • после этого необходимые нам для замены файлы будут располагаться в директории c:temp4019265extracted

Установка безопасности для каталогов/файлов

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

Выполнять приведенные здесь действия следует из-под учетной записи с правами локального Администратора (с эскалацией привилегий).

Сделать это можно двумя способами:

1. Через проводник. Нажимаем правую клавишу мыши на директории WinSxS — пункт Свойства — вкладка Безопасность — кнопка Дополнительно — вкладка Владелец — кнопка Изменить — ставим курсор на нужного нам пользователя, активируем чекбокс Заменить владельца подконтейнеров и объектов — жмем кнопку Применить. После окончания процесс закрываем все открытые окна через кнопку OK, повторно жмем правую клавишу мыши на директории WinSxS — вкладка Безопасность — во фрейме Группы и пользователи кнопка Изменить — выделяем курсором группу Администраторы — ставим разрешения Изменение и Запись;
2. Через командную строку. Из командной строки (cmd) выполняем следующие команды:

   takeown /f c:windowswinsxs*

   

   даем группе Администраторы (в которую, я надеюсь, включена ваша учетная запись) полный доступ к целевому файлу, для этого выполняем следующую команду:

   icacls c:windowswinsxs* /GRANT АДМИНИСТРАТОРЫ:F

   

Копирование каталогов/файлов

И последним шагом выполняется непосредственно копирование (с заменой) с донорской (исправной) системы на целевую (проблемную) содержимого всех обнаруженных на предыдущих шагах каталогов и файлов, не забывайте так же и .manifest-файлы.
Что именно мы копируем:

1. Если присутствуют пара .cat или .mum файлов компонента, то скопировать их в каталог %WinDir%servicingPackages (с донора на цель). Копировать именно всю пару, даже если поврежден всего-лишь один из них (и один из них отображается в лог-файле);
2. Если к паре .cat/.mum файлов присутствует еще и .ses-файл, то копируем и его;
3. Если присутствуют одноименные манифесты (.manifest-файл(ы)) компонента, то скопировать их в каталог %WinDir%WinSxSManifests (с донора на цель);
4. Если присутствуют остальные подкаталоги/файлы компонента, то скопировать их в каталог компонента %WinDir%WinSxSимя_компонента (c донора на цель);
5. Если присутствуют файлы в директории C:WindowsSystem32, то можно скопировать и их (с донора на цель). Хотя делать это и не обязательно, поскольку жесткие ссылки восстанавливаются при проверках через sfc;

Производить операции копирования файлов (во избежание блокировок на работающей системе) можно при помощи любого загрузочного LiveCD, предварительно скопировав все переносимые файлы на флешку (или любой иной носитель). Выполнять же само копирование можно как при помощи командной строки, так и выполнить перемещение с помощью проводника Windows.

Восстановление реестра

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

• Запустить командную строку (cmd);
• Подключить динамический куст реестра HKLMCOMPONENTS командой:

  reg load HKLMCOMPONENTS C:WINDOWSSYSTEM32CONFIGCOMPONENTS

  если выскакивает ошибка:

  процесс не может получить доступ к файлу, так как этот файл занят другим процессом.

  то куст уже подключен.

• Запустить редактор реестра regedit;
• В открывшемся окне нажать Ctrl+F и ввести имя компонента, который вы восстанавливали на предыдущем шаге;
• В случае отсутствия каких либо записей реестра, выполнить импортирование соответствующих записей реестра о компоненте с рабочей машины;
• Выполнить команду:

  reg unload HKLMCOMPONENTS

• выполнить перезагрузку операционной системы;

Nonsense! I move the winsxs folder on any install I’m fortunate enough to have another disk to send it to.

Now, the method of moving it is probably different than what you are thinking.

1) Close any running applications (This is important).

2) Copy your winsxs folder to another location (preferably off of your SSD

3) Now comes the magic: You are going to create a junction point to literally trick Windows into thinking the winsxs folder is in the same place.

3a) Start > Run > Type «mklink /J «c:Windowswinsxs» «d:winsxs»

The mklink command functions as such: mklink LINK TARGET, so in the above example the c:Windowswinsxs acts as the LINK location where you want to trick Windows into thinking it still exists and the TARGET location is of course the d:winsxs on another drive.

The only real drawback of this is if you manage to boot your computer without the other location and then you try to launch an application. However, if you are running an internal drive configuration then I guess I wouldn’t worry about it.

I use this method ALL THE TIME for moving certain games in and out of the Steam folder on my gaming computers at home and even successfully moved the Adobe Creative Suite’s MASSIVE install to one single location on another drive off of my wife’s SSD.

********Note********

I would NEVER do this in an Enterprise environment but at home it’s just golden.

Nonsense! I move the winsxs folder on any install I’m fortunate enough to have another disk to send it to.

Now, the method of moving it is probably different than what you are thinking.

1) Close any running applications (This is important).

2) Copy your winsxs folder to another location (preferably off of your SSD

3) Now comes the magic: You are going to create a junction point to literally trick Windows into thinking the winsxs folder is in the same place.

3a) Start > Run > Type «mklink /J «c:Windowswinsxs» «d:winsxs»

The mklink command functions as such: mklink LINK TARGET, so in the above example the c:Windowswinsxs acts as the LINK location where you want to trick Windows into thinking it still exists and the TARGET location is of course the d:winsxs on another drive.

The only real drawback of this is if you manage to boot your computer without the other location and then you try to launch an application. However, if you are running an internal drive configuration then I guess I wouldn’t worry about it.

I use this method ALL THE TIME for moving certain games in and out of the Steam folder on my gaming computers at home and even successfully moved the Adobe Creative Suite’s MASSIVE install to one single location on another drive off of my wife’s SSD.

********Note********

I would NEVER do this in an Enterprise environment but at home it’s just golden.

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

Теперь метод его перемещения, вероятно, отличается от того, что вы думаете.

1) Закройте все запущенные приложения (это важно).

2) Скопируйте папку winsxs в другое место (желательно с вашего SSD

3) Теперь приходит волшебство: вы собираетесь создать точку соединения, которая буквально обманывает Windows, заставляя думать, что папка winsxs находится там же.

3a) Пуск> Выполнить> Введите «mklink /J» c:Windowswinsxs »« d:winsxs »

Команда mklink работает следующим образом: mklink LINK TARGET, поэтому в приведенном выше примере c:Windowswinsxs действует как местоположение LINK, где вы хотите обмануть Windows, думая, что она все еще существует, и расположение TARGET, конечно же, d:winsxs на другом диске.

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

Я использую этот метод ВСЕ ВРЕМЯ для перемещения определенных игр в папку Steam на своих игровых компьютерах дома и даже успешно перенес установку MASSIVE из Adobe Creative Suite в одно место на другом диске SSD моей жены.

********Заметка********

Я бы НИКОГДА не делал это в корпоративной среде, но дома это просто золотой.