none
BUGCHECK 0x109 Arg3: 1a0 Arg4: 7 RRS feed

  • 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:     MachineOwner

    Minidump is uploaded https://onedrive.live.com/redir?resid=A78FFA4458144861!106&authkey=!AE1gDjQU7nzMFok&ithint=file%2cdmp

    Dienstag, 22. Dezember 2015 22:06

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.

    Donnerstag, 24. Dezember 2015 11:52

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

    Mittwoch, 23. Dezember 2015 08:11
  • 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.....

    Mittwoch, 23. Dezember 2015 13:16
  • Hatte einen Virenscanner im Verdacht der etwas tief im Kernel wurschtelt.

    http://www.windowspro.de/marcel-kueppers

    Mittwoch, 23. Dezember 2015 14:07
  • Als zweite Möglichkeit hatte ich den RAM im Verdacht. Hast Du mal das Timing angepasst?

    http://www.windowspro.de/marcel-kueppers

    Mittwoch, 23. Dezember 2015 14:12
  • 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



    Best regards,

    David das Neves



    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.

    Mittwoch, 23. Dezember 2015 15:14
  • Am 23.12.2015 schrieb Benedict Schultz:

    hatte den Post aus nem anderen Forum copy-pasted.

    Kannst Du den Link zum anderen Thread/Forum hier bitte posten? Dann
    können hier auch die Leser von den anderen Ideen/Lösungsvorschlägen
    profitieren, Danke.

    Mittwoch, 23. Dezember 2015 16:55
  • 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.

    Donnerstag, 24. Dezember 2015 11:52
  • 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)

    Donnerstag, 24. Dezember 2015 11:55
  • http://answers.microsoft.com/en-us/windows/forum/windows8_1-performance/bugcheck-0x109-arg3-1a0-arg4-7/43a177bb-6571-4c1c-9f77-43931b7be2a9?tm=1450821423071
    Donnerstag, 24. Dezember 2015 11:56
  • Danke für Deine Rückmeldung! Schöne Weihnachten!

    http://www.windowspro.de/marcel-kueppers

    Donnerstag, 24. Dezember 2015 12:36
  • Gerne, wünsche ich auch allen und vielen Dank, dass man sich hier so fleisig gegenseitig hilft.

    Fröhe Weihnachten @all

    Donnerstag, 24. Dezember 2015 12:41