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.
PREVENT YOUR SERVER FROM CRASHING!
Never again lose customers to poor server speed! Let us help you.
Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.
GET STARTED
var google_conversion_label = «owonCMyG5nEQ0aD71QM»;
- Remove From My Forums
-
Question
-
Would like to know the cause and how to solve this issue. Vm rebooted unexpectably and this system should have high availability due to redundant hosts supporting microsoft failover cluster, no cluster events found only Hyper-V-Worker event id
18590 the minute the system rebooted.Have found no information relevant about this event and have not found either info on this particular vm error codes combination, our virtual machine is rebooting unexpectably with error 41
«The system has rebooted without cleanly shutting down first. This error could be caused if the system stopped responding, crashed, or lost power unexpectedly.»
nothing more.
The host only reports the hyper v worker with following info:
[
Name]Microsoft-Windows-Hyper-V-Worker [
Guid]{51DDFA29-D5C8-4803-BE4B-2ECB715570FE} Keywords 0x8000000000000000 [
SystemTime]2018-05-15T20:08:35.506202300Z [
ProcessID]5424 [
ThreadID]5692 Channel Microsoft-Windows-Hyper-V-Worker-Admin Computer CHU-MTF-MD-TMS2.AUTOTMS.NET [
UserID]S-1-5-83-1-2261632595-1252162391-1381914804-3329928821 VmId 86CDC653-7B57-4AA2-B458-5E5275AE7AC6
- Remove From My Forums
-
Question
-
Would like to know the cause and how to solve this issue. Vm rebooted unexpectably and this system should have high availability due to redundant hosts supporting microsoft failover cluster, no cluster events found only Hyper-V-Worker event id
18590 the minute the system rebooted.Have found no information relevant about this event and have not found either info on this particular vm error codes combination, our virtual machine is rebooting unexpectably with error 41
«The system has rebooted without cleanly shutting down first. This error could be caused if the system stopped responding, crashed, or lost power unexpectedly.»
nothing more.
The host only reports the hyper v worker with following info:
[
Name]Microsoft-Windows-Hyper-V-Worker [
Guid]{51DDFA29-D5C8-4803-BE4B-2ECB715570FE} Keywords 0x8000000000000000 [
SystemTime]2018-05-15T20:08:35.506202300Z [
ProcessID]5424 [
ThreadID]5692 Channel Microsoft-Windows-Hyper-V-Worker-Admin Computer CHU-MTF-MD-TMS2.AUTOTMS.NET [
UserID]S-1-5-83-1-2261632595-1252162391-1381914804-3329928821 VmId 86CDC653-7B57-4AA2-B458-5E5275AE7AC6
Hi Spiceheads,
I’m hoping some of you might kindly help me figure out why this Domain Controller is randomly rebooting.
First I’ll give you an overview of the Server and network.
1 Physical Server running Hyper-V — Windows Server 2012 Standard
1 DC — Windows Server 2012
1 Exchange Server 2010 — Windows Server 2008 r2
1 App server with free SQL and basic file sharing — Windows Server 2012
Host Hardware Specification:
Make/Model: HP ProLiant ML 350 G6
CPU’s: 2x Intel Xeon CPU E5606 2.13GHz
RAM: 76Gb
RAID Configuration
P410
1 Logical Drive (for the host OS) 2x 3TB SATA RAID 1
P410i Embedded
1 Logical Drive (for Hyper-V) 6x 3TB SATA RAID 1+0
The problem we have is that the DC randomly reboots. I’m looking at the errors that happen around the time of each crash which are as follows:
This error is logged within the host:
Event ID: 18590
Log: Hyper-V-Worker
‘VM-DC’ has encountered a fatal error. The guest operating system reported that it failed with the following error codes: ErrorCode0: 0xD1, ErrorCode1: 0x6, ErrorCode2: 0x2, ErrorCode3: 0x0, ErrorCode4: 0x56F74E7. If the problem persists, contact Product Support for the guest operating system. (Virtual machine ID 8D08BE34-DE81-445A-808A-252F19E8F402)
These errors are logged around the time of the crash within the VM:
Event ID: 8193
Log: Application
Volume Shadow Copy Service error: Unexpected error calling routine RegOpenKeyExW(-2147483646,SYSTEMCurrentControlSetServicesVSSDiag,…). hr = 0x80070005, Access is denied.
Operation:
Initializing Writer
Context:
Writer Class Id: {e8132975-6f93-4464-a53e-1050253ae220}
Writer Name: System Writer
Writer Instance ID: {4bf88c49-c6a6-4a2a-89af-287ccb8d52c0}
Event ID: 7001
Log: System
The Remote Access Management service service depends on the Windows Internal Database service which failed to start because of the following error:
The service did not start due to a logon failure.
Event ID: 7000
Log: System
The Windows Internal Database service failed to start due to the following error:
The service did not start due to a logon failure.
Event ID: 7041
Log: system
The MSSQL$MICROSOFT##WID service was unable to log on as NT SERVICEMSSQL$MICROSOFT##WID with the currently configured password due to the following error:
Logon failure: the user has not been granted the requested logon type at this computer.
Service: MSSQL$MICROSOFT##WID
Domain and account: NT SERVICEMSSQL$MICROSOFT##WID
This service account does not have the required user right «Log on as a service.»
User Action
Assign «Log on as a service» to the service account on this computer. You can use Local Security Settings (Secpol.msc) to do this. If this computer is a node in a cluster, check that this user right is assigned to the Cluster service account on all nodes in the cluster.
If you have already assigned this user right to the service account, and the user right appears to be removed, check with your domain administrator to find out if a Group Policy object associated with this node might be removing the right.
These errors are on the run up to the system crash
Event ID: 5774
Log: System
The dynamic registration of the DNS record ‘_ldap._tcp.Default-First-Site-Name._sites.Domain.local. 600 IN SRV 0 100 389 VM-DC.Domain.local.’ failed on the following DNS server:
DNS server IP address: ::
Returned Response Code (RCODE): 0
Returned Status Code: 0
For computers and users to locate this domain controller, this record must be registered in DNS.
USER ACTION
Determine what might have caused this failure, resolve the problem, and initiate registration of the DNS records by the domain controller. To determine what might have caused this failure, run DCDiag.exe. To learn more about DCDiag.exe, see Help and Support Center. To initiate registration of the DNS records by this domain controller, run ‘nltest.exe /dsregdns’ from the command prompt on the domain controller or restart Net Logon service.
Or, you can manually add this record to DNS, but it is not recommended.
ADDITIONAL DATA
Error Value: Bad DNS packet.
Critical Error ID: 41
Log: System
The system has rebooted without cleanly shutting down first. This error could be caused if the system stopped responding, crashed, or lost power unexpectedly.
Error ID: 1001
Log: System
The computer has rebooted from a bugcheck. The bugcheck was: 0x000000d1 (0x0000000000000006, 0x0000000000000002, 0x0000000000000000, 0xfffff880059b34e7). A dump was saved in: C:WindowsMEMORY.DMP. Report Id: 030713-18671-01.
The dump file information:
Crash time: 07/03/2013 11:13:58
Bug Check String: DRIVER_IRQL_NOT_LESS_EQUAL
Bug Check Code: 0x000000d1
Caused by Driver: winnat.sys
Caused by Address: winnat.sys+d4e7
Crash Address: ntoskrnl.exe+7a040
The majority of the Crashes had the same information apart from 1 which has the following:
Crash time: 04/03/2013 13:52:45
Bug Check String: APC_INDEX_MISMATCH
Bug Check Code: 0x00000001
Caused by Driver: vhdmp.sys
Caused by Address: vhdmp.sys+519a0
Crash Address: ntoskrnl.exe+7a040
Any ideas anyone? Need more information?
Many thanks,
Simon
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?