Hyper v ошибка 18590

Are you stuck with hyper v error 18590? We can help you fix it.

This error occurs due to an interrupted power supply.

At Bobcares, we often get requests from our customers regarding Hyper-V errors as a part of our Server Management Services.

Today, let’s see how our Support Engineers help our customers resolve this error.

Why does Hyper V error 18590 occur?

A shutdown is triggered in the system without notifying the service in the server. During a clean shutdown, it works as by sending a signal to the service to turn off then Shutdown the machine.

If this process does not happen, the event is logged with the Event ID 18590.

One of the major reasons is because of the interrupted power supply. This can also occur due to hardware issues or due to server crash.

The logs in the Event viewer looks as:

Let’s discuss how our Support Engineers help our customers resolve it.

How we fix Hyper V error 18590

Recently one of our customers contacted us with this error. Now let’s discuss how our Support Engineers help our customers resolve it.

Power issue

One of the common reasons for the event ID in the log is because of the issue with the power supply.

When the power supply is down thus making the Virtual Machine Shutdown unexpectedly.

If the issue with the UPS attached to the Hyper-V servers, then we suggest our customers contact the UPS Manufacture. Also, we suggest them to make sure to use the UPS manufacture software correctly to handle the battery threshold level.

Firmware update for Hyper V error

Recently one of our customers contacted us saying that the server unexpectedly keeps shutting down and no power interruption is happening.

On further analyzing the issue, we found that Hyper-V servers are facing issues with a CPU microcode update. Thus to resolve the error we update the firmware to the latest one. Let’s discuss how our Support Engineers update the firmware for our customers.

1. Initially, we log in to the management interface. Then we go to Maintenance and select Firmware update.

2. Now we enable update mode by clicking the Enter Update Mode.

3. Then we upload the ZIP file. Now the screen will show the current and the newly added firmware. We confirm the version and click on Start Upgrade.

4. Once the update is complete the management interface will reboot. It will return back to the login screen.

After the firmware update, we monitored the servers. The Virtual Machine was stable after the update.

If the issue still persists we need to upgrade the Intel processors on the Hyper-V host server to resolve it.

Power control

Another solution to the error is to make changes to the power management settings in BIOS.

To make the changes in the settings we enter the BIOS. Then we select Power Management in BIOS.

We change all the systems from Active Power Controller to Maximum Performance.

Thus the CPU ready times drop to a normal level. This way we resolve the error.

[Need assistance to fix Hyper v errors – We can help you fix it]

Conclusion

In short, we have discussed the causes of the hyper v error 18590. Also, we have discussed how our Support Engineers help our customers fix it.

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

.

Исключения в антивирусе

Если на сервере Hyper-V установлено антивирусное программное обеспечение и файлы виртуальной машины Hyper-V не добавлены в список исключений компонента сканирования в реальном времени, то вы можете столкнуться со множеством трудностей. Наиболее распространенная проблема — администратор открывает консоль управления Hyper-V и обнаруживает, что виртуальные машины исчезли. Другие симптомы:

• проблемы с производительностью виртуальных машин;
• создание или запуск виртуальной машины заканчивается неудачей, при этом появляется одно из следующих сообщений:

1. The requested operation cannot be performed on a file with a user-mapped section open. (0x800704C8);
2. VMName’ Microsoft Synthetic Ethernet Port (Instance ID{7E0DA81A-A7B4-4DFD-869F-37002C36D816}): Failed to Power On with Error ‘The specified network resource or device is no longer available.’ (0x80070037);
3. The I/O operation has been aborted because of either a thread exit or an application request. (0x800703E3).

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

• Папка, в которой по умолчанию хранятся настройки виртуальных машин (C:ProgramDataMicrosoftWindowsHyper-V).
• Другие папки конфигураций виртуальных машин.
• Папка, в которой по умолчанию хранятся VHD-файлы (C:UsersPublicDocumentsHyper-VVirtual Hard Disks).
• Другие папки, в которых хранятся VHD-файлы.
• Папки, в которых хранятся снимки.
• Vmms.exe (возможно, придется настроить как процесс-исключение в антивирусной программе).
• Vmwp.exe (возможно, придется настроить как процесс-исключение в антивирусной программе).

Рекомендуемые исключения, необходимые для работы Hyper-V, а также известные проблемы, связанные с антивирусным программным обеспечением, описаны в статье Microsoft «Virtual machines are missing in the Hyper-V Manager Console or when you create or start a virtual machine, you receive one of the following error codes: ‘0x800704C8’, ‘0x80070037’ or ‘0x800703E3’» (support.microsoft.com/kb/961804).

Снимки и нехватка места на диске

Если снимки не могут быть объединены из-за нехватки места на диске (то есть error0x80070070), не удаляйте файлы с расширением. avhd (файлы снимков). В результате удаления файлов. avhd произойдет потеря данных, которая приведет к тому, что виртуальная машина перестанет запускаться. Если у вас нет возможности освободить необходимое дисковое пространство на томе, где хранятся файлы. avhd, требуется сделать следующее:

1. Экспортировать виртуальную машину на том, где достаточно свободного места на диске.
2. После завершения экспорта откройте консоль управления Hyper-V и удалите виртуальную машину, которую экспортировали.
3. Импортируйте виртуальную машину из нового места хранения. Если версия Hyper-V ниже Windows Server 2008 R2, включите виртуальную машину, а затем выключите ее, чтобы запустить процесс объединения в новом месте хранения.

Полный список наработанных методов использования снимков можно найти в статье TechNet «Hyper-V Virtual Machine Snapshots: FAQ» по ссылке technet.microsoft.com/en-us/library/dd560637(WS.10).aspx.

Компоненты интеграции не обновлены

После того как исправление или обновление для Hyper-V установлено на сервер (Windows 2008 R2, Server 2008 или Microsoft Hyper-V Server), просмотрите документацию, связанную с исправлением, чтобы узнать, требует ли это исправление обновления компонентов интеграции виртуальной машины. Вы также можете просмотреть список обновлений Hyper-V на сайте TechNet, чтобы выяснить, включает ли обновление усовершенствованные компоненты интеграции.

• Список обновлений Hyper-V для Windows Server 2008: technet.microsoft.com/en-us/library/dd430893(WS.10).aspx?lc=1033.
• Список обновлений Hyper-V для Windows Server 2008 R2: technet.microsoft.com/en-us/library/ff394763(WS.10).aspx.

Пример проблемы, которая может возникнуть из-за устаревших компонентов интеграции, можно найти в статье Microsoft «The network connection is lost on a Hyper-V virtual machine» (support.microsoft.com/kb/2223005), где говорится об исправлении для Hyper-V, которое решает проблему сетевого подключения к виртуальной машине. Для этого исправления требуется обновить компоненты интеграции виртуальных машин с системами Windows XP и Windows Server 2003. Если исправление установить на сервер Hyper-V, но не обновить компоненты интеграции виртуальной машины, то, вероятно, сетевая проблема, которую должно было устранить исправление, останется.

Чтобы определить, какие виртуальные машины имеют устаревшие компоненты интеграции, можно просмотреть журнал событий Microsoft-Windows-Hyper-V-Integration/Admin. Если виртуальная машина использует устаревшие компоненты интеграции, то при ее запуске в журнал будет записано следующее событие:

Log Name: Microsoft-Windows-Hyper-VIntegration-Admin

Source: Microsoft-Windows-Hyper-V-Integration

Event ID: 4010

Level: Warning

Description: Hyper-V Heartbeat connected to virtual machine ‘vmname’, but the version does not match the version expected by Hyper-V (Virtual machine ID A5C22E8D-5F58-4186-832F-E7C2AE0B4804). This is an unsupported configuration. This means that technical support will not be provided until this problem is resolved. To fix this problem, upgrade the integration services. To upgrade, connect to the virtual machine and select Insert Integration Services Setup Disk from the Action menu.

Событие с идентификатором 4010 будет записано для каждой устаревшей службы интеграционного компонента виртуальной машины (экран 1).

Экран 1. Событие 4010 в журнале

Вы также можете задействовать инструмент Hyper-V Best Practices Analyzer (BPA) или сценарии PowerShell, чтобы определить, какие виртуальные машины имеют устаревшие компоненты интеграции. Узнать, как получить инструмент Hyper-V BPA, можно из статьи Microsoft «Hyper-V BPA for Windows Server 2008 R2 is now available» (support.microsoft.com/kb/977238). Команда разработчиков Hyper-V разместила сценарий PowerShell в хранилище сценариев TechNet по ссылке gallery.technet.microsoft.com/scriptcenter/251337c5-ab97-40b3-a888-80b68102d1d5.

Функция Refresh virtual machine configuration и кластер

Консоль управления Hyper-V не поддерживает кластеры, и это означает, что изменения настроек виртуальных сетей или виртуальных машин в данной консоли должны быть продублированы на другие узлы кластеров с помощью функции Refresh virtual machine configuration в консоли диспетчера отказоустойчивых кластеров.

Если не воспользоваться этой функцией, то виртуальная машина либо вообще не сможет перемещаться между узлами кластера, либо ее параметры (например, VLAN ID), которые были изменены, будут потеряны при перемещении виртуальной машины на другой узел кластера Hyper-V. Чтобы обновить настройки виртуальной машины, выполните следующие шаги.

1. В консоли диспетчера отказоустойчивых кластеров откройте раздел Services and Applications, а затем щелкните по виртуальной машине, для которой хотите обновить настройки.
2. В окне Actions прокрутите список вниз, щелкните мышью на кнопке More Actions, затем выберите функцию Refresh virtual machine configuration, как показано на экране 2.

Экран 2. Функция Refresh virtual machine configuration

В системе Server 2008 R2 функцией Refresh virtual machine configuration можно не пользоваться, если вы меняете параметры виртуальной машины с помощью консоли диспетчера отказоустойчивых кластеров. Для изменения параметров виртуальной машины в этой консоли сделайте следующее:

• в консоли диспетчера отказоустойчивых кластеров откройте раздел Services and Applications, затем щелкните по виртуальной машине, для которой хотите изменить параметры;
• в окне Actions щелкните мышью на кнопке Settings, чтобы изменить параметры виртуальной машины.

Сбои в работе Hyper-V

Чтобы посмотреть полный список распространенных проблем в настройке Hyper-V, обратитесь к статье TechNet «Hyper-V: Gotchas» по ссылке social.technet.microsoft.com/wiki/contents/articles/hyper-v-gotchas.aspx. Этот список обновляется раз в квартал при выявлении новых проблем.

Джефф Паттерсон (jeffpatt@microsoft.com) — старший менеджер в команде Product Quality and Online в Microsoft

I have a problem. My VMs (Hyper-V) — Windows Server 2012 R2 restart themselves quite often (BSOD: CRITICAL_STRUCTURE_CORRUPTION (109)). Last time it was 11x over weekend. I have new HW, 2x Supermicro server. I installed Windows Server 2012 R2 and Hyper‑V role on both servers (+ drivers from Supermicro website are installed). As a guest systems (VMs) I have 2x Windows Server 2012 and 1x Windows Server 2012 R2 on each Hyper-V host. Like I wrote, problem is, that W2012R2 VMs randomly restart themselves. But only W2012R2 VMs. VMs with W2012 are OK. All systems are clean, no applications are installed and there is no workload.

After reboot, there are these events logged on VMs:

Kernel-Power 41

EventData:
BugcheckCode 265 
BugcheckParameter1 0xa3a01f59e148b50a 
BugcheckParameter2 0xb3b72be033c8b301 
BugcheckParameter3 0x1a0 
BugcheckParameter4 0x7 
SleepInProgress 0 
PowerButtonTimestamp 0 
BootAppStatus 0 

BugCheck 1001

EventData 
param1 0x00000109 (0xa3a01f59e148b50a, 0xb3b72be033c8b301, 0x00000000000001a0, 0x0000000000000007) 
param2 C:WindowsMEMORY.DMP 
param3 021516-3093-01

WinDbg output:

CRITICAL_STRUCTURE_CORRUPTION (109)
This bugcheck is generated when the kernel detects that critical kernel code or
data have been corrupted. There are generally three causes for a corruption:
1) A driver has inadvertently or deliberately modified critical kernel code
 or data. See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
2) A developer attempted to set a normal kernel breakpoint using a kernel
 debugger that was not attached when the system was booted. Normal breakpoints,
 "bp", can only be set if the debugger is attached at boot time. Hardware
 breakpoints, "ba", can be set at any time.
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arguments:
Arg1: a3a01f5a69a8b6bb, Reserved
Arg2: b3b72be0bc28b4a2, Reserved
Arg3: 00000000000001a0, Failure type dependent information
Arg4: 0000000000000007, Type of corrupted region, can be
0 : A generic data region
1 : Modification of a function or .pdata
2 : A processor IDT
3 : A processor GDT
4 : Type 1 process list corruption
5 : Type 2 process list corruption
6 : Debug routine modification
7 : Critical MSR modification  

Debugging Details:

PG_MISMATCH:  40000
CUSTOMER_CRASH_COUNT:  1
DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT_SERVER
BUGCHECK_STR:  0x109
PROCESS_NAME:  System
CURRENT_IRQL:  2
ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre
STACK_TEXT:  
ffffd001`1bb7e088 00000000`00000000 : 00000000`00000109 a3a01f5a`69a8b6bb b3b72be0`bc28b4a2 00000000`000001a0 : nt!KeBugCheckEx
STACK_COMMAND:  kb
SYMBOL_NAME:  ANALYSIS_INCONCLUSIVE
FOLLOWUP_NAME:  MachineOwner
MODULE_NAME: Unknown_Module
IMAGE_NAME:  Unknown_Image
DEBUG_FLR_IMAGE_TIMESTAMP:  0
IMAGE_VERSION:  
BUCKET_ID:  BAD_STACK
FAILURE_BUCKET_ID:  BAD_STACK
ANALYSIS_SOURCE:  KM
FAILURE_ID_HASH_STRING:  km:bad_stack
FAILURE_ID_HASH:  {75814664-faf6-4b70-bbc7-dc592132ecdd}
Followup: MachineOwner

Sometimes, there is this event logged on the host server. But not every time when VM fails:

Hyper-V-Worker 18590

VmErrorCode0 0x109
VmErrorCode1 0xbb8d251d
VmErrorCode2 0xe0d2304
VmErrorCode3 0x1a0
VmErrorCode4 0x7

Could you help me solve this problem please?