Benutzer mit den meisten Antworten
BUGCHECK 0x109 Arg3: 1a0 Arg4: 7

Frage
-
Dear all,
I've got a new Windows Server 2012 R2 with Hyper-V feature installed, running on Supermicro Hardware.
I get BSODs in the virtual machines after 30minutes up to 14 hours.
I already ran each ram module in single mode, still the same error.
Configured alot of things in the BIOS, also contacted Supermicro, but they couldn't help me.
If I export the virtual machine and run it on older hardware with windows server 2012 r2 + hyper-v the VM runs fine.
I already installed the hypervisor with newest Intel drivers and also just Supermicro recommended drivers.
Haven't got any idea what i should test now.
I would be happy if someone has got additional ideas.
==========================================
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: a3a01f59d89da6de, Reserved
Arg2: b3b72be02b1da54d, 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
8 : Object type
9 : A processor IVT
a : Modification of a system service function
b : A generic session data region
c : Modification of a session function or .pdata
d : Modification of an import table
e : Modification of a session import table
f : Ps Win32 callout modification
10 : Debug switch routine modification
11 : IRP allocator modification
12 : Driver call dispatcher modification
13 : IRP completion dispatcher modification
14 : IRP deallocator modification
15 : A processor control register
16 : Critical floating point control register modification
17 : Local APIC modification
18 : Kernel notification callout modification
19 : Loaded module list modification
1a : Type 3 process list corruption
1b : Type 4 process list corruption
1c : Driver object corruption
1d : Executive callback object modification
1e : Modification of module padding
1f : Modification of a protected process
20 : A generic data region
21 : A page hash mismatch
22 : A session page hash mismatch
23 : Load config directory modification
24 : Inverted function table modification
25 : Session configuration modification
102 : Modification of win32k.sys
Debugging Details:
------------------
DUMP_CLASS: 1
DUMP_QUALIFIER: 400
BUILD_VERSION_STRING: 9600.18146.amd64fre.winblue_ltsb.151121-0600
SYSTEM_MANUFACTURER: Microsoft Corporation
VIRTUAL_MACHINE: HyperV
SYSTEM_PRODUCT_NAME: Virtual Machine
SYSTEM_VERSION: 7.0
BIOS_VENDOR: American Megatrends Inc.
BIOS_VERSION: 090006
BIOS_DATE: 05/23/2012
BASEBOARD_MANUFACTURER: Microsoft Corporation
BASEBOARD_PRODUCT: Virtual Machine
BASEBOARD_VERSION: 7.0
DUMP_TYPE: 2
BUGCHECK_P1: a3a01f59d89da6de
BUGCHECK_P2: b3b72be02b1da54d
BUGCHECK_P3: 1a0
BUGCHECK_P4: 7
PG_MISMATCH: 40000
CPU_COUNT: 2
CPU_MHZ: dac
CPU_VENDOR: GenuineIntel
CPU_FAMILY: 6
CPU_MODEL: 3f
CPU_STEPPING: 2
CPU_MICROCODE: 6,3f,2,0 (F,M,S,R) SIG: FFFFFFFF'00000000 (cache) FFFFFFFF'00000000 (init)
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: BAD_STACK_0x109
BUGCHECK_STR: 0x109
PROCESS_NAME: System
CURRENT_IRQL: 2
ANALYSIS_SESSION_HOST: *deleted*
ANALYSIS_SESSION_TIME: 12-22-2015 22:34:30.0878
ANALYSIS_VERSION: 10.0.10586.567 amd64fre
STACK_TEXT:
ffffd000`f0f591c8 00000000`00000000 : 00000000`00000109 a3a01f59`d89da6de b3b72be0`2b1da54d 00000000`000001a0 : nt!KeBugCheckEx
STACK_COMMAND: kb
THREAD_SHA1_HASH_MOD_FUNC: 81a83ae0317433a47fcc36991983df3b6e638b71
THREAD_SHA1_HASH_MOD_FUNC_OFFSET: 6e16edd8c7dd677734fdbcd2397a2e35e9fae964
THREAD_SHA1_HASH_MOD: 76cd06466d098060a9eb26e5fd2a25cb1f3fe0a3
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_0x109
PRIMARY_PROBLEM_CLASS: BAD_STACK
FAILURE_BUCKET_ID: BAD_STACK_0x109
TARGET_TIME: 2015-12-22T19:52:02.000Z
OSBUILD: 9600
OSSERVICEPACK: 0
SERVICEPACK_NUMBER: 0
OS_REVISION: 0
SUITE_MASK: 305
PRODUCT_TYPE: 2
OSPLATFORM_TYPE: x64
OSNAME: Windows 8.1
OSEDITION: Windows 8.1 LanManNt SmallBusiness TerminalServer SmallBusinessRestricted SingleUserTS
OS_LOCALE:
USER_LCID: 0
OSBUILD_TIMESTAMP: 2015-11-21 17:42:09
BUILDDATESTAMP_STR: 151121-0600
BUILDLAB_STR: winblue_ltsb
BUILDOSVER_STR: 6.3.9600.18146.amd64fre.winblue_ltsb.151121-0600
ANALYSIS_SESSION_ELAPSED_TIME: 35b
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:bad_stack_0x109
FAILURE_ID_HASH: {b4d7023a-05c3-49b2-3ea4-6240fe57d90e}
Followup: MachineOwnerMinidump is uploaded https://onedrive.live.com/redir?resid=A78FFA4458144861!106&authkey=!AE1gDjQU7nzMFok&ithint=file%2cdmp
Antworten
-
Intel's Aggressive Link Power Management war das Problem
Verträgt sich nicht mit VMs, die in nem Storage Spaces liegen und an SATA Ports mit ALPM hängen.
Das ist die Lösung.
Das Problem ist behoben, vielen Dank für eure Vorschläge, das Meiste eurer Ideen habe ich schon umgesetzt gehabt.
Knapp 70 Stunden meiner Arbeit haben gereicht um den Fehler zu finden.
- Als Antwort markiert Teodora MilushevaModerator Montag, 4. Januar 2016 12:03
Alle Antworten
-
Hi,
warum schreibst Du Deinen Post in english?
Welche Applikationen laufen schon in der VM? Gibt es hier einen Virenscanner? Sind die Integrationsdienste aktuell? Wird Dynamic Memory verwendet?
Gruß,
Marcel
http://www.windowspro.de/marcel-kueppers
-
Moin,
hatte den Post aus nem anderen Forum copy-pasted.
1 AD (Essentials)
1 FS (blanke Installation nur Windows Updates)
1 App (mittlerweile Trendmicro WFB)
Virenscanner spielt keine Rolle, der Fehler war vorher schon da.
Integrationsdienste sind aktuell.
Kein dynamic memory.
Der Verdacht liegt momentan auf Aggressive Link Power Management in Verbindung mit Storage Spaces.
Hoffe, dass es das war.
VMs laufen seit 14 Stunden ohne Fehler. Hat aber auch noch nichts zu heißen.....
-
Hallo Benedict,
s. hier
Argument 4: Arg4: 0000000000000007, --> A critical MSR modification
s. hier
Bitte folgende Befehle im WinDBG ausführen:
ln 00000000000001a0
Mal schauen, was raus kommt.
TODOs:
BIOS updaten s. hier
Und folgendes Skript als Admin ausführen und entsprechend die Logs anschauen
-> c:\windows\Logs\cbs.log
-> c:\windows\Logs\sfcdetails.log
DISM /Online /Cleanup-Image /CheckHealth DISM /Online /Cleanup-Image /ScanHealth DISM /Online /Cleanup-Image /RestoreHealth DISM /Online /Cleanup-Image /ScanHealth sfc /scannow findstr /c:"[SR]" %windir%\logs\cbs\cbs.log >c:\windows\logs\cbs\sfcdetails.log pause
Liebe Grüße
Please vote as helpful and mark as answer if a post helped you.
This posting is provided "AS IS" with no warranties, and confers no rights. -
-
Intel's Aggressive Link Power Management war das Problem
Verträgt sich nicht mit VMs, die in nem Storage Spaces liegen und an SATA Ports mit ALPM hängen.
Das ist die Lösung.
Das Problem ist behoben, vielen Dank für eure Vorschläge, das Meiste eurer Ideen habe ich schon umgesetzt gehabt.
Knapp 70 Stunden meiner Arbeit haben gereicht um den Fehler zu finden.
- Als Antwort markiert Teodora MilushevaModerator Montag, 4. Januar 2016 12:03
-
ln 00000000000001a0
Hat im WinDBG nichts gefunden.
Hatte ich schon probiert.
RAM zieht sich die Timings von der Frequenz, da ist Kingston eigentlich sehr zuverlässig.
Probiert wurde auch den RAM auf 1600 MHz statt 2133 laufen zu lassen.BIOS Update wurde auch gemacht, habe mein zweites X10SRL-F auch versucht, da bin ich über ALPM gestolpert.
SFC hat keine Fehler gefunden (auch schon probiert gehabt)
- Bearbeitet Benedict Schultz Donnerstag, 24. Dezember 2015 11:56