Jump to content

childoftheko4n

Member
  • Posts

    1
  • Joined

  • Last visited

Everything posted by childoftheko4n

  1. Hey All, New build and discovering some kernel panics. My event log shows its happened almost twice a day since building it last week , but i never noticed it (so it must have happened while asleep?). I did notice when waking it from sleep a couple times over the week ti appeared to have restarted, so that makes sense. Today it happened while i was on it. Below is the log, and my build: Build https://pcpartpicker.com/user/childoftheko4n/saved/#view=QcWF8d Log: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Microsoft-Windows-Kernel-Power" Guid="{331c3b3a-2005-44c2-ac5e-77220c37d6b4}" /> <EventID>41</EventID> <Version>8</Version> <Level>1</Level> <Task>63</Task> <Opcode>0</Opcode> <Keywords>0x8000400000000002</Keywords> <TimeCreated SystemTime="2020-06-25T20:16:54.3670873Z" /> <EventRecordID>799</EventRecordID> <Correlation /> <Execution ProcessID="4" ThreadID="8" /> <Channel>System</Channel> <Computer>DESKTOP-GGJFJMF</Computer> <Security UserID="S-1-5-18" /> </System> <EventData> <Data Name="BugcheckCode">0</Data> <Data Name="BugcheckParameter1">0x0</Data> <Data Name="BugcheckParameter2">0x0</Data> <Data Name="BugcheckParameter3">0x0</Data> <Data Name="BugcheckParameter4">0x0</Data> <Data Name="SleepInProgress">6</Data> <Data Name="PowerButtonTimestamp">0</Data> <Data Name="BootAppStatus">3221225684</Data> <Data Name="Checkpoint">16</Data> <Data Name="ConnectedStandbyInProgress">false</Data> <Data Name="SystemSleepTransitionsToOn">2</Data> <Data Name="CsEntryScenarioInstanceId">0</Data> <Data Name="BugcheckInfoFromEFI">false</Data> <Data Name="CheckpointStatus">0</Data> <Data Name="CsEntryScenarioInstanceIdV2">0</Data> <Data Name="LongPowerButtonPressDetected">false</Data> </EventData> </Event> pulled the dmp file: Microsoft (R) Windows Debugger Version 10.0.19528.1000 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:\Users\Scott\OneDrive\Desktop\MEMORY.DMP] Kernel Bitmap Dump File: Kernel address space is available, User address space may not be available. Symbol search path is: srv* Executable search path is: Windows 10 Kernel Version 19041 MP (16 procs) Free x64 Product: WinNt, suite: TerminalServer SingleUserTS Personal 19041.1.amd64fre.vb_release.191206-1406 Machine Name: Kernel base = 0xfffff8037a600000 PsLoadedModuleList = 0xfffff8037b22a2b0 Debug session time: Tue Jun 30 07:30:04.503 2020 (UTC - 4:00) System Uptime: 0 days 15:50:27.124 Loading Kernel Symbols ............................................................... ..Page 140fc6 not present in the dump file. Type ".hh dbgerr004" for details .......Page 1404a3 not present in the dump file. Type ".hh dbgerr004" for details ....................................................... .........................Page daddd not present in the dump file. Type ".hh dbgerr004" for details ..Page 2176 not present in the dump file. Type ".hh dbgerr004" for details .Page 14fc52 not present in the dump file. Type ".hh dbgerr004" for details .................................... .............. Loading User Symbols PEB is paged out (Peb.Ldr = 000000352b922018). Type ".hh dbgerr001" for details Loading unloaded module list ..................... For analysis of this file, run !analyze -v nt!KeBugCheckEx: fffff8037a9dda20 48894c2408 mov qword ptr [rsp+8],rcx ss:0018:ffffa28c`054e5e00=0000000000000109 7: kd> !analyze -v * Bugcheck Analysis * * ******************************************************************************* 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: a3a00e5d6858d6c4, Reserved Arg2: b3b71ae3bada4b74, Reserved Arg3: fffff8037fb0fd58, Failure type dependent information Arg4: 0000000000000001, 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 26 : An extended processor control register 27 : Type 1 pool corruption 28 : Type 2 pool corruption 29 : Type 3 pool corruption 2a : Type 4 pool corruption 2b : Modification of a function or .pdata 2c : Image integrity corruption 2d : Processor misconfiguration 2e : Type 5 process list corruption 2f : Process shadow corruption 30 : Retpoline code page corruption 101 : General pool corruption 102 : Modification of win32k.sys Debugging Details: KEY_VALUES_STRING: 1 Key : Analysis.CPU.Sec Value: 2 Key : Analysis.DebugAnalysisProvider.CPP Value: Create: 8007007e on SCOTTPC Key : Analysis.DebugData Value: CreateObject Key : Analysis.DebugModel Value: CreateObject Key : Analysis.Elapsed.Sec Value: 8 Key : Analysis.Memory.CommitPeak.Mb Value: 69 Key : Analysis.System Value: CreateObject ADDITIONAL_XML: 1 BUGCHECK_CODE: 109 BUGCHECK_P1: a3a00e5d6858d6c4 BUGCHECK_P2: b3b71ae3bada4b74 BUGCHECK_P3: fffff8037fb0fd58 BUGCHECK_P4: 1 PROCESS_NAME: csrss.exe STACK_TEXT: ffffa28c054e5df8 0000000000000000 : 0000000000000109 a3a00e5d6858d6c4 b3b71ae3bada4b74 fffff8037fb0fd58 : nt!KeBugCheckEx SYMBOL_NAME: Ntfs!NtfsBreakBatchOplock+ac298 MODULE_NAME: Ntfs IMAGE_NAME: Ntfs.sys IMAGE_VERSION: 10.0.19041.1 STACK_COMMAND: .thread ; .cxr ; kb BUCKET_ID_FUNC_OFFSET: ac298 FAILURE_BUCKET_ID: 0x109_1_Ntfs!NtfsBreakBatchOplock OS_VERSION: 10.0.19041.1 BUILDLAB_STR: vb_release OSPLATFORM_TYPE: x64 OSNAME: Windows 10 FAILURE_ID_HASH: {3940434c-474b-7456-62bd-12e6a4ef565e} Followup: MachineOwner steps taken since last issue: -Updated BIOS (new build. BIOS from 12/2019, 3 updates since. including Improve memory compatibility. Though my build has detected my RAM since day 1) -Updated chipset AMD driver -Checked for other driver updates (only found 1, was a relatively small one, i forget which device. wasnt anything major though)
×