New
#1
BSOD error 0x0000001a
Im stumped, trying to fix my BSOD error 0x0000001a
I have attached my dump logs from the forum tool.
Attachment 229785
Any help fixing this situation would be much appreciated.
Attachment 229786
Im stumped, trying to fix my BSOD error 0x0000001a
I have attached my dump logs from the forum tool.
Attachment 229785
Any help fixing this situation would be much appreciated.
Attachment 229786
Welcome
Almost all your dumps show memory as the issue with different bug checks
BSOD Analyze
Code:******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 109, {a3a039d8959d0787, b3b7465ee819d74d, fffff80002b18030, 1} *** WARNING: Unable to verify timestamp for win32k.sys *** ERROR: Module load completed but symbols could not be loaded for win32k.sys Probably caused by : memory_corruption Followup: memory_corruption --------- 2: 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: a3a039d8959d0787, Reserved Arg2: b3b7465ee819d74d, Reserved Arg3: fffff80002b18030, 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 Debugging Details: ------------------ BUGCHECK_STR: 0x109 CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: CODE_CORRUPTION PROCESS_NAME: System CURRENT_IRQL: 0 LAST_CONTROL_TRANSFER: from 0000000000000000 to fffff80002a861c0 STACK_TEXT: fffff880`03387598 00000000`00000000 : 00000000`00000109 a3a039d8`959d0787 b3b7465e`e819d74d fffff800`02b18030 : nt!KeBugCheckEx STACK_COMMAND: kb CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt fffff80002b18056 - nt!MiInitializePageAccessLogging+26 [ f8:fa ] 1 error : !nt (fffff80002b18056) MODULE_NAME: memory_corruption IMAGE_NAME: memory_corruption FOLLOWUP_NAME: memory_corruption DEBUG_FLR_IMAGE_TIMESTAMP: 0 MEMORY_CORRUPTOR: ONE_BIT FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT Followup: memory_corruptionHow many memory modules do you have? and is this a new build?Code:******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck A, {fffffa8018b2de00, 2, 1, fffff80002ac0469} *** WARNING: Unable to verify timestamp for win32k.sys *** ERROR: Module load completed but symbols could not be loaded for win32k.sys Probably caused by : memory_corruption ( nt!MiDeletePteRun+6af ) Followup: MachineOwner --------- 2: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* IRQL_NOT_LESS_OR_EQUAL (a) An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses. If a kernel debugger is available get the stack backtrace. Arguments: Arg1: fffffa8018b2de00, memory referenced Arg2: 0000000000000002, IRQL Arg3: 0000000000000001, bitfield : bit 0 : value 0 = read operation, 1 = write operation bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status) Arg4: fffff80002ac0469, address which referenced memory Debugging Details: ------------------ WRITE_ADDRESS: GetPointerFromAddress: unable to read from fffff80002cbd100 fffffa8018b2de00 CURRENT_IRQL: 2 FAULTING_IP: nt!MiDeletePteRun+6af fffff800`02ac0469 f00fba6f1000 lock bts dword ptr [rdi+10h],0 CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT BUGCHECK_STR: 0xA PROCESS_NAME: FlashPlayerPlu TRAP_FRAME: fffff88003d6b3a0 -- (.trap 0xfffff88003d6b3a0) NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=0000058000000000 rbx=0000000000000000 rcx=fffff88003d6b4a0 rdx=000000000001919f rsi=0000000000000000 rdi=0000000000000000 rip=fffff80002ac0469 rsp=fffff88003d6b530 rbp=000000000004d09f r8=0000000000000001 r9=0000000000000000 r10=fffffa80017fdbf8 r11=fffff88003d6b500 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up ei ng nz na po cy nt!MiDeletePteRun+0x6af: fffff800`02ac0469 f00fba6f1000 lock bts dword ptr [rdi+10h],0 ds:00000000`00000010=???????? Resetting default scope LAST_CONTROL_TRANSFER: from fffff80002a8d769 to fffff80002a8e1c0 STACK_TEXT: fffff880`03d6b258 fffff800`02a8d769 : 00000000`0000000a fffffa80`18b2de00 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx fffff880`03d6b260 fffff800`02a8c3e0 : 00000000`00000000 00000000`00000000 00000000`00000000 0001be67`00000080 : nt!KiBugCheckDispatch+0x69 fffff880`03d6b3a0 fffff800`02ac0469 : 0001be67`00000080 fffff680`00065ac0 fffffa80`00e71dd0 00000001`00000001 : nt!KiPageFault+0x260 fffff880`03d6b530 fffff800`02abf4f7 : fffffa80`0413d700 fffff680`00065ff8 fffffa80`0413d7d0 00000000`10030000 : nt!MiDeletePteRun+0x6af fffff880`03d6b6e0 fffff800`02a5f405 : ffffffff`00000000 00000000`0cc2bfff fffffa80`00000000 fffffa80`0394c060 : nt!MiDeleteVirtualAddresses+0x41f fffff880`03d6b8a0 fffff800`02d5f6da : fffff8a0`04cb83d0 fffff880`03d6bbe0 00000000`00000000 fffffa80`0394c060 : nt!MmCleanProcessAddressSpace+0x679 fffff880`03d6b8f0 fffff800`02d42bdd : 00000000`00000000 00000000`00000001 00000000`7ef59000 fffffa80`0251b6c0 : nt!PspExitThread+0x56a fffff880`03d6b9f0 fffff800`02a80cda : 00000000`00000100 fffffa80`0394c120 00000000`00000001 fffff800`02a83ddd : nt!PsExitSpecialApc+0x1d fffff880`03d6ba20 fffff800`02a81020 : 00000000`00000246 fffff880`03d6baa0 fffff800`02d42b50 00000000`00000001 : nt!KiDeliverApc+0x2ca fffff880`03d6baa0 fffff800`02a8d4f7 : fffffa80`0394c060 00000000`0000053c 00000000`00000000 fffffa80`02ddb2a0 : nt!KiInitiateUserApc+0x70 fffff880`03d6bbe0 00000000`741c2e09 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceExit+0x9c 00000000`0975ecf8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x741c2e09 STACK_COMMAND: kb FOLLOWUP_IP: nt!MiDeletePteRun+6af fffff800`02ac0469 f00fba6f1000 lock bts dword ptr [rdi+10h],0 SYMBOL_STACK_INDEX: 3 SYMBOL_NAME: nt!MiDeletePteRun+6af FOLLOWUP_NAME: MachineOwner MODULE_NAME: nt DEBUG_FLR_IMAGE_TIMESTAMP: 4fa390f3 IMAGE_NAME: memory_corruption FAILURE_BUCKET_ID: X64_0xA_nt!MiDeletePteRun+6af BUCKET_ID: X64_0xA_nt!MiDeletePteRun+6af Followup: MachineOwner --------- 2: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* IRQL_NOT_LESS_OR_EQUAL (a) An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses. If a kernel debugger is available get the stack backtrace. Arguments: Arg1: fffffa8018b2de00, memory referenced Arg2: 0000000000000002, IRQL Arg3: 0000000000000001, bitfield : bit 0 : value 0 = read operation, 1 = write operation bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status) Arg4: fffff80002ac0469, address which referenced memory Debugging Details: ------------------ WRITE_ADDRESS: fffffa8018b2de00 CURRENT_IRQL: 2 FAULTING_IP: nt!MiDeletePteRun+6af fffff800`02ac0469 f00fba6f1000 lock bts dword ptr [rdi+10h],0 CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT BUGCHECK_STR: 0xA PROCESS_NAME: FlashPlayerPlu TRAP_FRAME: fffff88003d6b3a0 -- (.trap 0xfffff88003d6b3a0) NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=0000058000000000 rbx=0000000000000000 rcx=fffff88003d6b4a0 rdx=000000000001919f rsi=0000000000000000 rdi=0000000000000000 rip=fffff80002ac0469 rsp=fffff88003d6b530 rbp=000000000004d09f r8=0000000000000001 r9=0000000000000000 r10=fffffa80017fdbf8 r11=fffff88003d6b500 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up ei ng nz na po cy nt!MiDeletePteRun+0x6af: fffff800`02ac0469 f00fba6f1000 lock bts dword ptr [rdi+10h],0 ds:00000000`00000010=???????? Resetting default scope LAST_CONTROL_TRANSFER: from fffff80002a8d769 to fffff80002a8e1c0 STACK_TEXT: fffff880`03d6b258 fffff800`02a8d769 : 00000000`0000000a fffffa80`18b2de00 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx fffff880`03d6b260 fffff800`02a8c3e0 : 00000000`00000000 00000000`00000000 00000000`00000000 0001be67`00000080 : nt!KiBugCheckDispatch+0x69 fffff880`03d6b3a0 fffff800`02ac0469 : 0001be67`00000080 fffff680`00065ac0 fffffa80`00e71dd0 00000001`00000001 : nt!KiPageFault+0x260 fffff880`03d6b530 fffff800`02abf4f7 : fffffa80`0413d700 fffff680`00065ff8 fffffa80`0413d7d0 00000000`10030000 : nt!MiDeletePteRun+0x6af fffff880`03d6b6e0 fffff800`02a5f405 : ffffffff`00000000 00000000`0cc2bfff fffffa80`00000000 fffffa80`0394c060 : nt!MiDeleteVirtualAddresses+0x41f fffff880`03d6b8a0 fffff800`02d5f6da : fffff8a0`04cb83d0 fffff880`03d6bbe0 00000000`00000000 fffffa80`0394c060 : nt!MmCleanProcessAddressSpace+0x679 fffff880`03d6b8f0 fffff800`02d42bdd : 00000000`00000000 00000000`00000001 00000000`7ef59000 fffffa80`0251b6c0 : nt!PspExitThread+0x56a fffff880`03d6b9f0 fffff800`02a80cda : 00000000`00000100 fffffa80`0394c120 00000000`00000001 fffff800`02a83ddd : nt!PsExitSpecialApc+0x1d fffff880`03d6ba20 fffff800`02a81020 : 00000000`00000246 fffff880`03d6baa0 fffff800`02d42b50 00000000`00000001 : nt!KiDeliverApc+0x2ca fffff880`03d6baa0 fffff800`02a8d4f7 : fffffa80`0394c060 00000000`0000053c 00000000`00000000 fffffa80`02ddb2a0 : nt!KiInitiateUserApc+0x70 fffff880`03d6bbe0 00000000`741c2e09 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceExit+0x9c 00000000`0975ecf8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x741c2e09 STACK_COMMAND: kb FOLLOWUP_IP: nt!MiDeletePteRun+6af fffff800`02ac0469 f00fba6f1000 lock bts dword ptr [rdi+10h],0 SYMBOL_STACK_INDEX: 3 SYMBOL_NAME: nt!MiDeletePteRun+6af FOLLOWUP_NAME: MachineOwner MODULE_NAME: nt DEBUG_FLR_IMAGE_TIMESTAMP: 4fa390f3 IMAGE_NAME: memory_corruption FAILURE_BUCKET_ID: X64_0xA_nt!MiDeletePteRun+6af BUCKET_ID: X64_0xA_nt!MiDeletePteRun+6af Followup: MachineOwner ---------
Following the steps mentioned in the tutorial below test each module for at least 8 passes
RAM - Test with Memtest86+
Take all the time needed and post back results
koolkat77,
Thanks for your help.
I have two sticks of RAM, but last week I switched the slots that they were plugged into hoping it would stop the BSOD's. Yesterday when I opened the case I noticed that one RAM module was not flush in the socket. BSOD occured before and after all the RAM movement.
I have ordered two sticks of RAM(combo pack) that was on ASUS suggestion list for my MOBO. Hopefully this will fix my issue. I will use the memtest utility for my current RAM then with my new RAM and post back.
This is a build was from December 2011. I have had BSOD in the past, but the system has just started getting heavy use in the past three months where I was able to see how often the BSOD occurs. The spec for this system is listed under "My System Specs".
Thanks for adding the system specs
Keep us updated of the results and your new ram modules as well