Vmci sys vmware ошибка

Обновлено: 04.07.2024

[Виртуальная машина] Решение для VMware с запросом «Невозможно получить версию драйвера VMCI: неверный дескриптор»

1. Появление проблем

Рисунок 1 Окно ошибок

1. Откройте основной интерфейс виртуальной машины, выберите виртуальную машину, которая не была успешно установлена, и найдите путь к файлу конфигурации, показанному в «файле конфигурации» в нижней части интерфейса (рисунок 2)

Рисунок 2 Поиск пути к файлу конфигурации виртуальной машины

2. Найдя файл конфигурации на шаге 1, щелкните правой кнопкой мыши и выберите «Открыть в блокноте» (я использую notepad ++, принцип тот же)

Рисунок 3 Найдите файл конфигурации

3. Найдите код vmci0.present = "TRUE" (как показано на рисунке 4), измените TURE на FALSE и сохраните его.

Рисунок 4 Найдите код vmci0.present = "TRUE"

3. Причина проблемы

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

Интеллектуальная рекомендация

Поверните строку в целые числа

Тема Описание Преобразуйте строку в целое число (реализация функции integer.valueof (строка), но строка не совпадает 0), требуя функции библиотеки, которая нельзя использовать для преобразования целых.

Docker создает репликацию Redis Master-Slave

Centos установить докер быстрый старт докера Создать Dockerfile Поместите файл на сервер Linux, создайте папку / usr / docker / redis и поместите его в этот каталог Выполните следующий код в каталоге .

Установка GateOne на новом CentOS7

Установка GateOne на новом CentOS7 В последнее время исследуются такие инструменты, как WebSSH2, в настоящее время требуется встроить терминал ssh в веб-приложение и найти GateOne. GateOne - это веб-в.

Примечания к исследованию Qt4 (5), QWaitCondition of QThread Learning

Практические занятия: решения проблем системы управления обучением

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

искробезопасная практика (5) обратный индекс

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

Решение центра тяжести неправильного многоугольника

Справочник статей Во-первых, решение центра тяжести неправильных многоугольников 1.1 Метод расчета треугольника центра тяжести 1.2 Метод расчета площади треугольника 1.3 Метод расчета площади полигона.

Файлы SYS, такие как vmci.sys, классифицируются как файлы Win64 EXE (Драйвер). Как файл VMware PCI VMCI Bus Device он был создан для использования в VMware PCI VMCI Bus Device от компании VMware.

Файл vmci.sys изначально был выпущен с VMware Workstation 12.5.5 04/04/2017 для ОС Windows 10. Последним обновлением версии [v9.8.16.0] для VMWare Workstation Player является 15.5.1, выпущенное 09/19/2019. Файл vmci.sys включен в VMWare Workstation Player 15.5.1 и VMware Workstation 12.5.5.

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

Совместимость с Windows 10, 8, 7, Vista, XP и 2000

Средняя оценка пользователей

Сведения о файле
Набор символов:	Unicode
Код языка:	English (U.S.)
Флаги файлов:	(none)
Маска флагов файлов:	0x003f
Точка входа:	0x19000
Размер кода:	74240

✻ Фрагменты данных файлов предоставлены участником Exiftool (Phil Harvey) и распространяются под лицензией Perl Artistic.

Vmci.sys — ошибки «синего экрана» (BSOD)

Существует ряд причин, по которым вы можете столкнуться с проблемами с vmci.sys. Большинство проблем с файлами SYS связаны с ошибками «синего экрана» (BSOD). Эти типы ошибок vmci.sys могут быть вызваны аппаратными проблемами, устаревшей прошивкой, поврежденными драйверами или другими проблемами, связанными с программным обеспечением (например, обновление VMWare Workstation Player). В число этих ошибок входят:

Не удается найти vmci.sys.
Не удалось загрузить vmci.sys.
Файл vmci.sys отсутствует или поврежден.
Windows не удалось запустить — vmci.sys.

Обнаружена проблема, в результате которой ОС Windows завершила работу, чтобы предотвратить повреждение компьютера. По всей видимости, причиной проблемы стал следующий файл: vmci.sys.

:( На вашем ПК возникла проблема, которую не удалось устранить, и его необходимо перезагрузить. Сведения об ошибке можно найти в Интернете: [BSOD] (vmci.sys).

STOP 0x0000007E: SYSTEM THREAD EXCEPTION NOT HANDLED (vmci.sys)
STOP 0x0000003B: SYSTEM SERVICE EXCEPTION (vmci.sys)
STOP 0x00000050: PAGE FAULT IN A NONPAGED AREA (vmci.sys)
STOP 0×0000007A: KERNEL DATA INPAGE (vmci.sys)
STOP 0x0000000A: IRQL NOT LESS EQUAL (vmci.sys)
STOP 0x0000001E: KMODE EXCEPTION NOT HANDLED (vmci.sys)

Крайне важно устранять ошибки «синего экрана»

В большинстве случаев ошибки BSOD vmci.sys возникают после установки нового оборудования, программного обеспечения (VMWare Workstation Player) или выполнения неудачного обновления Windows. В остальных случаях к ошибке «синего экрана» vmci.sys может привести повреждение программного обеспечения, вызванное заражением вредоносным программным обеспечением. Таким образом, крайне важно, чтобы антивирус постоянно поддерживался в актуальном состоянии и регулярно проводил сканирование системы.

СОВЕТ ОТ СПЕЦИАЛИСТА: Как показывает опыт, целесообразно всегда создавать резервную копию системы Windows и (или) точку восстановления системы, прежде чем вносить какие-либо изменения в аппаратное или программное обеспечение на компьютере. Таким образом, в случае неблагоприятного поворота событий и возникновения связанной с файлом vmci.sys ошибки «синего экрана» после недавних изменений можно восстановить систему в предыдущее состояние.

Шаг 1. Восстановите компьютер до последней точки восстановления, «моментального снимка» или образа резервной копии, которые предшествуют появлению ошибки.

Чтобы начать восстановление системы (Windows XP, Vista, 7, 8 и 10):

Если на этапе 1 не удается устранить ошибку vmci.sys, перейдите к шагу 2 ниже.

Шаг 2. Если вы недавно установили приложение VMWare Workstation Player (или схожее программное обеспечение), удалите его, затем попробуйте переустановить VMWare Workstation Player.

Чтобы удалить программное обеспечение VMWare Workstation Player, выполните следующие инструкции (Windows XP, Vista, 7, 8 и 10):

После полного удаления приложения следует перезагрузить ПК и заново установить VMWare Workstation Player.

Если на этапе 2 также не удается устранить ошибку vmci.sys, перейдите к шагу 3 ниже.

VMWare Workstation Player 15.5.1

Шаг 3. Выполните обновление Windows.

Если ни один из предыдущих трех шагов по устранению неполадок не разрешил проблему, можно попробовать более агрессивный подход (примечание: не рекомендуется пользователям ПК начального уровня), загрузив и заменив соответствующую версию файла vmci.sys. Мы храним полную базу данных файлов vmci.sys со 100%-ной гарантией отсутствия вредоносного программного обеспечения для любой применимой версии VMWare Workstation Player . Чтобы загрузить и правильно заменить файл, выполните следующие действия:

Windows 10: C:\Windows\System32\drivers\
Windows 10: C:\Program Files\Common Files\VMware\Drivers\vmci\device\Win8\
Windows 10: C:\Windows\System32\DriverStore\FileRepository\vmci.inf_amd64_5e38a278d114b813\
Windows 10: C:\Windows\System32\drivers\
Windows 10: C:\Program Files\Common Files\VMware\Drivers\vmci\device\Win8\
Показать на 1 каталог больше + Windows 10: C:\Windows\System32\DriverStore\FileRepository\vmci.inf_amd64_64189b30c198ca23\

Если этот последний шаг оказался безрезультативным и ошибка по-прежнему не устранена, единственно возможным вариантом остается выполнение чистой установки Windows 10.

Если вы возитесь с уязвимостями режима ядра в Windows, то рано или поздно приходится иметь дело с такой техникой, как kernel pool spraying (только не называйте ее «распыление ядерной кучи»). Думаю, умение держать под контролем поведение пула памяти ядра будет полезным для разработчика эксплойтов.

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

Обзор структуры пула ядра

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

Существует несколько типов пулов, но все они имеют одинаковое строение (кроме особого пула (special pool), который используется утилитой проверки драйверов (driver verifier)). Каждый пул имеет управляющую структуру, называемую дескриптором пула. Помимо прочего, она хранит списки свободных блоков (chunk) пула, образующих свободное пространство пула. Сам пул состоит из страниц памяти. Они могут быть стандартными 4х-килобайтными или большими 2х-мегабайтными. Количество используемых страниц динамически регулируется.

Previous size (предыдущий размер) — размер предыдущего блока.
Pool index (индекс пула) используется в ситуациях, когда существует несколько пулов одного типа. К примеру, подкачиваемых пулов в системе несколько. Данное поле используется для определения, какому именно пулу принадлежит блок.
Block size (размер блока) — размер текущего блока. Аналогично полю previous size, его размер кодируется как
(размер данных блока + размер заголовка + опциональные 4 байта указателя на процесс, занявший блок) >> 3 (или >> 4 для x64 систем).
Pool type (тип пула) является набором битовых флагов, которые не документированы (!).
- T (Tracked): блок отслеживается утилитой проверки драйверов. Данный флаг используется для отладки.
- S (Session): блок принадлежит подкачиваемому пулу сессии, который используется для выделения памяти для специфичных пользовательской сессии данных.
- Q (Quota): блок состоит на учете системы управления квотами. Этот флаг имеет отношение только к 32-битным системам. Если он выставлен, в конец блока записывается указатель на процесс, владеющий этим блоком.
- U (In use): блок используется в настоящее время. В отличие от состояния «используется», блок может быть свободным, что значит, что из него можно выделять память. Данный флаг находится во втором бите, начиная с Windows Vista, до этого он находился в третьем бите.
- B (Base pool): данное поле определяет, какому базовому пулу принадлежит блок. Есть два базовых пула — подкачиваемый и неподкачиваемый. Неподкачиваемый кодируется нулем, подкачиваемый — единицей. До Windows Vista этот флаг занимал два бита, поскольку кодировался как (тип базового пула + 1), т.е. 0x10 для подкачиваемого пула и 0x1 для неподкачиваемого.
Обзор принципов выделения памяти в пуле

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

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

Когда дело доходит до освобождения блоков, описанный процесс выполняется с точностью до наоборот. Блоки становятся свободными и сливаются в один блок, если являются смежными.

Заметьте, что описанная ситуация является вымышленной и используется только для примера, поскольку на практике пулы заполняются страницами памяти задолго до того момента, когда пул будет готов для использования модулями ядра.

Контролируем выделение памяти из пулов

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

Рано или поздно пулы становятся фрагментированными. Это происходит из-за выделений и освобождений блоков памяти разного размера в различном порядке. Поэтому появляется термин spraying — распыление. При последовательном выделении памяти из пула блоки совершенно не обязаны быть смежными, и, скорее всего, они будут находиться в разных участках памяти. Поэтому когда мы заполняем память подконтрольными (красными) блоками, вероятнее, что мы увидим картинку слева, нежели справа.

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

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

Конечно, размер блока имеет значение. Поэтому необходимо предварительно расcчитать размер окна из освобожденных блоков. Если мы хотим контролируемо выделить блок размером в 0x315 байт при размере объектов для pool spraying в 0x20 байт, необходимо освободить 0x315 / 0x20 = (0x18 + 1) блоков. Думаю, это понятно.
- Если возможность выделения памяти из пулов посредством эксплуатируемого драйвера отсутствует, всегда есть возможность использовать объекты операционной системы в качестве объектов для pool spraying. Поскольку объекты ОС, как ни странно, хранятся в ядре ОС, память для них выделяется из различных пулов.
  - В неподкачиваемом пуле хранятся процессы, потоки, семафоры, мьютексы и т.д.
  - В подкачиваемом пуле хранятся объекты каталогов (directory object), ключи реестра, секции (так называемые сопоставления файлов или file mapping) и т.д.
  - В пуле сессии хранятся объекты подсистем GDI и USER: палитры (palette), контексты устройств (DC), кисти (brush) и т.д.
  VMware CVE 2013-1406
  
  В начале февраля были выпущены интересные рекомендации для обновления продуктов VMware. Судя по ним, в не обновленных компонентах присутствовала уязвимость, приводящая к локальному повышению привилегий как на основной, так и на гостевой ОС. Обходить стороной такие «вкусные» уязвимости нельзя.
  
  Уязвимым компонентом был vmci.sys. VMCI расшифровывается как Virtual Machine Communication Interface. Этот интерфейс используется для взаимодействия между виртуальными машинами и основной ОС. VMCI предоставляет проприетарный тип сокетов, реализованных в виде провайдера Windows Socket Service Provider в библиотеке vsocklib.dll. Драйвер vmci.sys создает виртуальное устройство, реализующее необходимые функциональные возможности. Он всегда запущен на основной ОС. Что касается гостевых систем, для работоспособности VMCI необходимо установить VMware tools.
  
  При написании любого обзора приятно объяснить высокоуровневую логику уязвимости, чтобы обзор превратился в детектив. К сожалению, в данном случае сделать это не удастся, потому что открытой информации о реализации VMCI весьма немного. Однако я думаю, что разработчики эксплойтов не переживают по этому поводу. По крайней мере выгоднее скорее получить рабочий эксплойт, чем потратить кучу времени на разбор того, как работает вся система целиком.
  
  PatchDiff выявил три запатченные функции. Все они относились к обработке одного и того же управляющего кода IOCTL 0x8103208C. Видимо, все конкретно пошло не так с его обработкой…
  
  Третья обновленная функция в конечном итоге вызывалась и из первой, и из второй. Она должна была выделять блок запрошенного размера, умноженного на 0x68, и инициализировать его, заполнив нулями. Этот блок содержит внутреннюю структуру данных для обработки запроса. Проблема была в том, что размер выделяемого блока указывался в режиме пользователя и толком не проверялся, в результате чего внутренняя структура не выделялась, что приводило к некоторым интересным последствиям.
  
  Для управляющего кода 0x8103208C указывались входной и выходной буфер. Чтобы добраться до уязвимого места, необходимо, чтобы его размер был равен 0x624 байта. Чтобы обработать запрос, выделялась внутренняя структура размером в 0x20C байт. Первые ее 4 байта заполнялись значением, указанным по адресу [user_buffer + 0x10]. Именно эти байты использовались в дальнейшем для выделения второй структуры данных, адрес на которую указывался в конце первой. При всем этом, вне зависимости от результата выделения второй структуры вызывалась некая диспетчерская функция.
  
  Данная диспетчерская функция искала указатель для обработки. Обработка включала в себя разыменовывание некоторого объекта и вызова некоторой функции в зависимости от установленных в структуре флагов. Но поскольку при некорректных параметрах выделить структуру для обработки не удавалось, диспетчерская функция просто «проезжала» за границу первого блока. Такая обработка приводила к нарушению доступа и «синему экрану смерти».
  
  Таким образом мы имеем возможность исполнять произвольный код по контролируемому адресу:
  
  Эксплуатация
  
  Поскольку диспетчерская функция выходит за границу блока, она встречается либо с соседним блоком, либо с не спроецированной страницей. Если она выходит в не спроецированную память, случится необрабатываемое исключение, и, следовательно, отобразится «синий экран». Но при попадании на соседний блок, диспетчерская функция интерпретирует его заголовок как указатель на структуру для обработки.
  
  Допустим, имеется x86-система. Четыре байта, которые диспетчерская функция пытается интерпретировать как указатель, на самом деле являются полями Previous Block Size, Pool Index, Current Block Size и флагами Pool Type. Поскольку нам известны размер и индекс пула для обрабатываемого блока, то нам известно значение младшего слова указателя:
  
  0xXXXX0043 – 0x43 является размером блока, который становится полем Previous Size для соседнего. 0 – индекс пула, который гарантированно будет именно нулем, поскольку данные блоки находятся в неподкачиваемом пуле, а он только один в системе. Заметьте, что если соседние блоки разделяют одну и ту же страницу памяти, они принадлежат одному и тому же типу и индексу пула.
  - B = 0: блок из неподкачиваемого пула
  - U = 1: подразумевается, что блок используется
  - Q = 0/1: блок может быть квотированным
  - S = 0: пул не является сессионным
  - T = 0: блок не является отслеживаемым по умолчанию
  - Неиспользуемые биты равны нулю
  - 0x04000000 – 0x06000000 для обычных блоков
  - 0x14000000 – 0x16000000 для квотированных блоков
  1. По адресу [0x43 + 0x38] необходимо поместить DWORD = 0x00000001 для удовлетворения следующего условия:
  2. По адресу [0x43 + 0xAC] необходимо поместить указатель на шелл-код.
  3. По адресу [0x43 + 0x100] нужно поместить указатель на подставной объект, который будет разыменован функцией ObfDereferenceObject(). Учтите, что счетчик ссылок хранится в заголовке с отрицательным смещением по отношению к объекту, поэтому убедитесь в том, что код в функции ObfDereferenceObject() не попадет на неспроецированный регион. Также укажите подходящее значение счетчика ссылок, поскольку, например, при достижении счетчиком ссылок нуля, ObfDereferenceObject() попытается освободить память функциями, совершенно не пригодными для памяти режима пользователя.
  Повышение стабильности эксплойта
  
  Несмотря на то, что мы выработали хорошую стратегию для эксплуатации данной уязвимости, она все еще остается ненадежной. Например, диспетчерская функция может попасть на свободный блок, поля которого предугадать невозможно. Несмотря на то, что заголовок такого блока будет интерпретирован как указатель (потому что он не равен нулю), результатом его обработки будет ошибка «синемий экран». Подобное случится также, когда диспетчерская функция попадет в неспроецированный участок памяти.
  
  В данном случае на помощь приходит техника kernel pool spraying. В качестве объекта pool spraying я выбрал семафоры, поскольку они являются наиболее подходящими по размеру. В результате применения данной техники, стабильность эксплойта повысилась в разы.
  
  Напомню, что в системе Windows 8 появилась поддержка такого механизма защиты, как SMEP, поэтому лень разработчика несколько усложняет разработку эксплойта. Написание базонезависимого кода с обходом SMEP остается упражнением для читателя.
  
  Что касается х64-систем, есть проблема с тем, что размер указателя стал равен 8 байтам. Это значит, что старшее двойное слово (DWORD) указателя будет попадать на поле Pool Tag. А поскольку большинство драйверов и подсистем ядра используют ASCII-символы для таких меток, указатель попадает в пространство неканонических адресов и не может использоваться для эксплуатации. На момент написания статьи я ничего дельного по этому поводу не придумал.
  
  Надеюсь, приведенная информация была полезной. Прошу прощения за то, что не смог уместить все необходимое в пару абзацев. Желаю успехов в исследованиях и эксплуатации во имя всецелого повышения уровня безопасности.
  
  P.S. Напоминаю, что для устранения уязвимости нужно обновить не только основную, но и все гостевые системы!
  P.P.S Если вы ощущаете некоторый дискомфорт от перевода некоторых терминов, будьте готовы мириться с ним в будущем, поскольку данный перевод рекомендован на языковом портале Microsoft.
  
  Ссылки
  [1] Tarjei Mandt. Kernel Pool Exploitation on Windows 7. Black Hat DC, 2011
  [2] Nikita Tarakanov. Kernel Pool Overflow from Windows XP to Windows 8. ZeroNights, 2011
  [3] Kostya Kortchinsky. Real world kernel pool exploitation. SyScan, 2008
  [4] SoBeIt. How to exploit Windows kernel memory pool. X’con, 2005
  
  VMWare
  В данной статье пойдет речь об ошибке This host does not support virtualizing real mode которая вылетает при запуске виртуальной машине на VMware Workstation после которой дальнейшая работа с виртуалкой невозможна. В статья я расскажу почему она происходит и как эту ошибку обойти.
  
  Если в процессе установки на компьютер или сервер программы VMware Workstation вылетела ошибка:
  
  This host does not support virtualizing real mode. The Intel “VMX Unrestricted Guest” feature is necessary to run this virtual machine on an Intel processor.
  Module ‘CPUIDEarly’ power on failed.
  Failed to start the virtual machine.
  
  Этот хост не поддерживает реальный режим виртуализации. Функция Intel «VMX Unrestricted Guest» необходима для запуска этой виртуальной машины на процессоре Intel.
  Сбой при включении модуля CPUIDEarly.
  Не удалось запустить виртуальную машину.
  
  Эта дурацкая ошибка говорит о том, что данное ПО VMware Workstation в моем случаем 15 версия не поддерживает мой процессор Core i7-950
  
  И для решения данной проблемы есть два варианта:
  1. Включение Legacy режима для CPU
  2. Перестановка VMware Workstation на версию ниже допустим 14 версию в которой есть поддержка моего процессора.
  Включение LegacyCPU
  
  Для включение поддержки старых процессоров в VMware Workstation необходимо проделать след шаги:
  
  Несмотря на то, что VMware Workstation является лучшим гипервизором для Windows, в частности, в плане стабильности работы, у него могут возникать определённые сложности. Это может быть, например, ошибка запуска виртуальной машины «Cannot open the configuration file» - ошибка, означающая, что VMware не может открыть файл конфигурации машины, поскольку тот либо повреждён, либо отсутствует. Что делать в такой ситуации? Как восстановить работоспособность виртуальной машины?
  
  Файл конфигурации виртуальной машины
  
  Итак, при запуске машины получаем ошибку открытия файла конфигурации. Следовательно, этот файл повреждён или отсутствует. В некоторых случаях ошибка может быть обусловлена недостаточным наличием прав для открытия файла.
  
  Можно попробовать запустить VMware Workstation с правами администратора, открыть машину, выключить гостевую ОС и попробовать снова запустить машину в программе без прав администратора. Если это не поможет, придётся виртуальную машину пересоздать. Но на базе её существующего виртуального диска.
  
  Файл конфигурации машин VMware – это файл формата «.wmx» , где хранятся параметры эмуляции оборудования и прочие настройки, которые мы указываем при создании машин и потом меняем их. Файл конфигурации хранится в папке виртуальной машины, его путь прямо указан в окошке сведений.
  
  Повреждение или удаление файла конфигурации влечёт за собой невозможность работы виртуальной машины. Однако этот файл никак не влияет на содержимое виртуального диска. В последнем сохранено состояние гостевой ОС, и после пересоздания машины мы продолжим работу с этой гостевой ОС. Разве что будут утеряны какие-то данные последнего сеанса работы гостевой ОС, если у машины было приостановленное, а не выключенное состояние. Ну и также будут удалены снапшоты, если они использовались.
  
  Удаление виртуальной машины
  
  Идём в проводнике по пути хранения данных машины VMware Workstation. Удаляем все её файлы, кроме виртуальных дисков – файлов «.wmdk» (или «.vhd», если используется этот формат) .
  
  В папке машины должны остаться только файлы виртуальных дисков.
  
  Теперь в программе VMware Workstation открываем панель библиотеки и удаляем машину с помощью контекстного меню.
  
  Пересоздание виртуальной машины
  
  Пересоздадим машину. Запускаем создание новой.
  
  Указываем выборочный тип конфигурации.
  
  Жмём «Далее».
  
  Указываем, что мы позже установим гостевую ОС.
  
  Указываем установленную на оставшемся виртуальном диске гостевую ОС, её версию и разрядность.
  
  Указываем тип BIOS , какой был у удалённой машины.
  
  Указываем ядра процессора, выделяемую оперативную память.
  
  Контроллеры и тип диска.
  
  На этапе выбора диска выбираем использование существующего виртуального диска.
  
  Жмём кнопку обзора и указываем путь к оставленному виртуальному диску. Указываем основной файл «.vmdk» (или «.vhd») .
  
  Всё – теперь виртуальная машина с новым файлом конфигурации, и она должна запуститься без проблем.
  
  Читайте также: