Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

Monthly Seminars at OSR Headquarters

East Coast USA
Windows Internals and SW Drivers, Dulles (Sterling) VA, 13 November 2017

Kernel Debugging & Crash Analysis for Windows, Nashua (Amherst) NH, 4 December 2017

Writing WDF Drivers I: Core Concepts, Nashua (Amherst) NH, 8 January 2018

WDF Drivers II: Advanced Implementation Techniques, Nashua (Amherst) NH, 15 January 2018


Go Back   OSR Online Lists > ntdev
Welcome, Guest
You must login to post to this list
  Message 1 of 7  
25 Jan 17 12:28
chris lueders
xxxxxx@cxxl.de
Join Date: 12 Sep 2007
Posts To This List: 5
bugcheck with MEMORY_CORRUPTION_LARGE

I got a kernel memory dump from one of our customers. It shows loads (3022!) memory corruptions. But they are very orderly, so I'm sure it's not just random corruption. I checked some code addresses and it looked like this: first in the chkimg list: fffff801a4a01595 - nt!MiDuplicateCloneLeaf+39 [ fa:8b ] kd> u 0xfffff801a4a01580 nt!MiDuplicateCloneLeaf+0x24: fffff801`a4a01580 194889 sbb dword ptr [rax-77h],ecx fffff801`a4a01583 58 pop rax fffff801`a4a01584 c041ba01 rol byte ptr [rcx-46h],1 fffff801`a4a01588 0000 add byte ptr [rax],al fffff801`a4a0158a 004c8bf3 add byte ptr [rbx+rcx*4-0Dh],cl fffff801`a4a0158e 48b900000000808bffff mov rcx,0FFFF8B8000000000h <<< fffff801`a4a01598 49c1ee0c shr r14,0Ch second in the list: fffff801a4a08bdb - nt!MiCloneReserveVadCommit+63 (+0x7646) [ f6:f1 ] kd> u 0xfffff801a4a08bc0 nt!MiCloneReserveVadCommit+0x48: fffff801`a4a08bc0 0bc0 or eax,eax fffff801`a4a08bc2 4889542438 mov qword ptr [rsp+38h],rdx fffff801`a4a08bc7 48baffffffff0f000000 mov rdx,0FFFFFFFFFh fffff801`a4a08bd1 4c23c2 and r8,rdx fffff801`a4a08bd4 49b90000000080f1ffff mov r9,0FFFFF18000000000h <<< fffff801`a4a08bde 498db42400050000 lea rsi,[r12+500h] and so on... it seems that a lot of pointers were patched. that leaves two conclusions for me: it's bad or good :) bad: virus/rootkit/whatever patched the system. good: windows does it itself to accommodate for something (didn't NT4 patch itself according to the CPU type??), or some benign software did it (firewall, etc). can anybody advise me further? what is this? cheers, chris PS: here is the windbg output: Microsoft (R) Windows Debugger Version 10.0.10586.567 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:\Users\chris\Downloads\x\MEMORY.DMP] Kernel Bitmap Dump File: Kernel address space is available, User address space may not be available. ************* Symbol Path validation summary ************** Response Time (ms) Location Deferred srv* ************* Symbol Path validation summary ************** Response Time (ms) Location Deferred srv* Deferred SRV*i:\mysymbols Deferred SRV*k:\mysymbols_old Deferred SRV*j:\addsymbols Deferred SRV*j:\websymbols*http://msdl.microsoft.com/download/symbols Symbol search path is: srv*;SRV*i:\mysymbols;SRV*k:\mysymbols_old;SRV*j:\addsymbols;SRV*j:\websymbols*ht tp://msdl.microsoft.com/download/symbols Executable search path is: srv* Windows 10 Kernel Version 14393 MP (4 procs) Free x64 Product: WinNt, suite: TerminalServer SingleUserTS Personal Built by: 14393.321.amd64fre.rs1_release_inmarket.161004-2338 Machine Name: Kernel base = 0xfffff801`a4a00000 PsLoadedModuleList = 0xfffff801`a4d04080 Debug session time: Tue Dec 13 15:45:36.772 2016 (UTC + 1:00) System Uptime: 0 days 0:06:17.536 Loading Kernel Symbols ............................................................... ................................................................ ............................................................. Loading User Symbols Loading unloaded module list ........ ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck C8, {0, 2, 0, 0} Probably caused by : memory_corruption Followup: memory_corruption --------- Processing initial command '!analyze -v' 2: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* IRQL_UNEXPECTED_VALUE (c8) The processor's IRQL is not what it should be at this time. This is usually caused by a lower level routine changing IRQL for some period and not restoring IRQL at the end of that period (eg acquires spinlock but doesn't release it). if UniqueValue is 0 or 1 2 = APC->KernelRoutine 3 = APC 4 = APC->NormalRoutine Arguments: Arg1: 0000000000000000, (Current IRQL << 16) | (Expected IRQL << 8) | UniqueValue Arg2: 0000000000000002 Arg3: 0000000000000000 Arg4: 0000000000000000 Debugging Details: ------------------ DUMP_CLASS: 1 DUMP_QUALIFIER: 401 BUILD_VERSION_STRING: 14393.321.amd64fre.rs1_release_inmarket.161004-2338 SYSTEM_MANUFACTURER: Dell Inc. SYSTEM_PRODUCT_NAME: XPS 13 9360 SYSTEM_SKU: 075B BIOS_VENDOR: Dell Inc. BIOS_VERSION: 1.0.7 BIOS_DATE: 09/13/2016 BASEBOARD_MANUFACTURER: Dell Inc. BASEBOARD_PRODUCT: 0T3FTF BASEBOARD_VERSION: A00 DUMP_TYPE: 1 BUGCHECK_P1: 0 BUGCHECK_P2: 2 BUGCHECK_P3: 0 BUGCHECK_P4: 0 CPU_COUNT: 4 CPU_MHZ: b58 CPU_VENDOR: GenuineIntel CPU_FAMILY: 6 CPU_MODEL: 8e CPU_STEPPING: 9 CPU_MICROCODE: 6,8e,9,0 (F,M,S,R) SIG: 30'00000000 (cache) 30'00000000 (init) DEFAULT_BUCKET_ID: CODE_CORRUPTION BUGCHECK_STR: 0xC8 PROCESS_NAME: System CURRENT_IRQL: 2 ANALYSIS_SESSION_HOST: ZIR ANALYSIS_SESSION_TIME: 01-25-2017 17:51:35.0433 ANALYSIS_VERSION: 10.0.10586.567 amd64fre LAST_CONTROL_TRANSFER: from fffff801a4b721a4 to fffff801a4b4a2c0 STACK_TEXT: ffffcb80`235a1378 fffff801`a4b721a4 : 00000000`000000c8 00000000`00000000 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx ffffcb80`235a1380 fffff80a`31212a75 : ffff920b`8016adc0 00000000`00000000 ffff920b`7f113ae0 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x18d14 ffffcb80`235a13d0 fffff80a`31210624 : 00000000`00000200 ffffcb80`00000000 fffff80a`34afa870 ffff920b`82f71030 : ndis!ndisExpandStack+0x19 ffffcb80`235a1410 fffff80a`312302b2 : 00000000`00000000 ffff920b`7c652010 ffff920b`8016adc0 ffff920b`7c652010 : ndis!ndisInvokeNextReceiveHandler+0xd0 ffffcb80`235a14e0 fffff80a`3120e674 : ffff920b`7c652010 ffff920b`83d30b10 ffff920b`00000000 00000000`00000001 : ndis!ndisFilterIndicateReceiveNetBufferLists+0x21c12 ffffcb80`235a1580 fffff80a`334821ed : ffff920b`84179030 ffffcb80`235a17e9 ffff920b`7c544cf0 ffff920b`8016adc0 : ndis!NdisFIndicateReceiveNetBufferLists+0x54 ffffcb80`235a15c0 fffff80a`33438870 : ffff920b`84179030 ffff920b`841796f0 ffff920b`84179030 ffff920b`83d80030 : cfosspeed6!xxx ffffcb80`235a1600 fffff80a`334c2cbe : ffffcb80`235a1900 ffff920b`841796f0 00000000`00000000 00000000`00000000 : cfosspeed6!xxx ffffcb80`235a1730 fffff80a`334e14fd : ffffcb80`235a1900 00000000`3fd942bb ffffcb80`235a18a0 ffff920b`7e2e1bc0 : cfosspeed6!xxx ffffcb80`235a1850 fffff80a`334e1816 : ffffcb80`235a1900 00000000`002b45dd ffffcb80`235a1930 00000000`00000000 : cfosspeed6!xxx ffffcb80`235a1880 fffff80a`334e19e1 : 00000000`00000080 fffff80a`33506810 ffff920b`7e2e1bc0 fffff80a`334d0673 : cfosspeed6!xxx ffffcb80`235a18e0 fffff80a`334d036e : ffffcb80`235a1aa0 fffff80a`334b8105 fffff80a`3354edb8 ffff920b`7e2cdd10 : cfosspeed6!xxx ffffcb80`235a1940 fffff80a`334d31a3 : ffffcb80`235a1aa0 ffff920b`7e2cdd10 fffff80a`33506810 00000000`00000001 : cfosspeed6!xxx ffffcb80`235a1980 fffff80a`334d2b99 : fffff80a`3354ec60 ffffcb80`235a1b38 fffff80a`33506810 00000000`00000080 : cfosspeed6!xxx ffffcb80`235a1af0 fffff80a`33506847 : fffff80a`3354edb8 fffff80a`3354edb8 00000000`00000001 ffffcb80`22106b40 : cfosspeed6!xxx ffffcb80`235a1b60 fffff801`a4ad2405 : ffffcb80`22100180 fffff801`a4b4f6af 00000000`00956386 ffff920b`727fe040 : cfosspeed6!xxx ffffcb80`235a1b90 fffff801`a4b4f786 : ffffcb80`22100180 ffff920b`727fe040 fffff801`a4ad23c4 ffffe081`bd474b40 : nt!PspSystemThreadStartup+0x41 ffffcb80`235a1be0 00000000`00000000 : ffffcb80`235a2000 ffffcb80`2359b000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16 STACK_COMMAND: kb CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt fffff801a4a01595 - nt!MiDuplicateCloneLeaf+39 [ fa:8b ] fffff801a4a08bdb - nt!MiCloneReserveVadCommit+63 (+0x7646) [ f6:f1 ] fffff801a4a08c64 - nt!MiCloneReserveVadCommit+ec (+0x89) [ f6:f1 ] fffff801a4a0e540 - nt!MiFlushDirtyBitsToPfn+74 (+0x58dc) [ f6:f1 ] fffff801a4a0e599 - nt!MiFlushDirtyBitsToPfn+cd (+0x59) [ f6:f1 ] fffff801a4a0e67f - nt!MiFlushDirtyBitsToPfn+1b3 (+0xe6) [ fa:8b ] fffff801a4a13f3d - nt!MiExchangeWsle+55 (+0x58be) [ f6:f1 ] fffff801a4a13f83 - nt!MiExchangeWsle+9b (+0x46) [ fa:8b ] fffff801a4a14277 - nt!MiAllocateContiguousMemory+227 (+0x2f4) [ fa:8b ] fffff801a4a142ac - nt!MiAllocateContiguousMemory+25c (+0x35) [ f6:f1 ] fffff801a4a14632 - nt!MmUnmapIoSpace+72 (+0x386) [ f6:f1 ] fffff801a4a14705 - nt!MiZeroAndFlushPtes+41 (+0xd3) [ f6:f1 ] fffff801a4a14817 - nt!MiZeroAndFlushPtes+153 (+0x112) [ f6:f1 ] fffff801a4a14a15 - nt!MiMapContiguousMemory+115 (+0x1fe) [ fa:8b ] fffff801a4a14a5b - nt!MiMapContiguousMemory+15b (+0x46) [ f6:f1 ] fffff801a4a14aa9 - nt!MiMapContiguousMemory+1a9 (+0x4e) [ fa:8b ] fffff801a4a156ae - nt!MiMappingHasIoReferences+e (+0xc05) [ f6:f1 ] fffff801a4a159bf - nt!MiDrainZeroLookasides+af (+0x311) [ fa:8b ] fffff801a4a15ac4 - nt!MiSetImageProtection+18 (+0x105) [ f6:f1 ] fffff801a4a15b33 - nt!MiRemoveImagePageFromSystemWorkingSet+47 (+0x6f) [ f6:f1 ] fffff801a4a15c63 - nt!MiSetSystemCodeProtection+53 (+0x130) [ f6:f1 ] fffff801a4a15d64-fffff801a4a15d66 3 bytes - nt!MiSetSystemCodeProtection+154 (+0x101) [ 40 fb f6:c0 f8 f1 ] fffff801a4a15d7a - nt!MiSetSystemCodeProtection+16a (+0x16) [ fa:8b ] fffff801a4a15fc9-fffff801a4a15fcb 3 bytes - nt!MiSetSystemCodeProtection+3b9 (+0x24f) [ 40 fb f6:c0 f8 f1 ] fffff801a4a15ffc - nt!MiSetSystemCodeProtection+3ec (+0x33) [ fa:8b ] fffff801a4a1604f - nt!MiSetSystemCodeProtection+43f (+0x53) [ f6:f1 ] fffff801a4a1607b-fffff801a4a1607e 4 bytes - nt!MiSetSystemCodeProtection+46b (+0x2c) [ a0 7d fb f6:60 fc f8 f1 ] fffff801a4a1608d-fffff801a4a16091 5 bytes - nt!MiSetSystemCodeProtection+47d (+0x12) [ d0 be 7d fb f6:30 7e fc f8 f1 ] fffff801a4a1619a - nt!MiMoveValidWsle+8e (+0x10d) [ f6:f1 ] fffff801a4a161c3 - nt!MiMoveValidWsle+b7 (+0x29) [ fa:8b ] fffff801a4a16457 - nt!MiMakeDriverPagesPrivate+53 (+0x294) [ f6:f1 ] fffff801a4a16554 - nt!MiMakeDriverPagesPrivate+150 (+0xfd) [ fa:8b ] fffff801a4a165c3 - nt!MiMakeDriverPagesPrivate+1bf (+0x6f) [ fa:8b ] fffff801a4a165e6 - nt!MiMakeDriverPagesPrivate+1e2 (+0x23) [ fa:8b ] fffff801a4a16687 - nt!MiMakeDriverPagesPrivate+283 (+0xa1) [ fa:8b ] fffff801a4a167b3 - nt!MiMakeDriverPagesPrivate+3af (+0x12c) [ fa:8b ] fffff801a4a167fd - nt!MiMakeDriverPagesPrivate+3f9 (+0x4a) [ fa:8b ] fffff801a4a168d0 - nt!MiTradeActivePage+5c (+0xd3) [ fa:8b ] fffff801a4a1694a - nt!MiTradeActivePage+d6 (+0x7a) [ f6:f1 ] fffff801a4a16c0c - nt!MiGetTopLevelPfn+5c (+0x2c2) [ fa:8b ] fffff801a4a17614 - nt!MiFindContiguousPages+214 (+0xa08) [ fa:8b ] fffff801a4a17903 - nt!MiPfnsWorthTrying+73 (+0x2ef) [ fa:8b ] fffff801a4a17a8c - nt!MiPfnsWorthTrying+1fc (+0x189) [ fa:8b ] fffff801a4a17ed5 - nt!MiAllocateMostlyContiguous+245 (+0x449) [ fa:8b ] fffff801a4a17fea - nt!MiAllocateMostlyContiguous+35a (+0x115) [ fa:8b ] fffff801a4a185d4 - nt!MiActivePageClaimCandidate+34 (+0x5ea) [ fa:8b ] fffff801a4a18709-fffff801a4a1870b 3 bytes - nt!MiActivePageClaimCandidate+169 (+0x135) [ 40 fb f6:c0 f8 f1 ] fffff801a4a1875d - nt!MiActivePageClaimCandidate+1bd (+0x54) [ f6:f1 ] fffff801a4a18773 - nt!MiActivePageClaimCandidate+1d3 (+0x16) [ f6:f1 ] fffff801a4a188de-fffff801a4a188e2 5 bytes - nt!MiActivePageClaimCandidate+33e (+0x16b) [ d0 be 7d fb f6:30 7e fc f8 f1 ] WARNING: !chkimg output was truncated to 50 lines. Invoke !chkimg without '-lo [num_lines]' to view entire output. fffff801a4c4b387-fffff801a4c4b389 3 bytes - nt!ExFreePoolWithTag+387 [ 40 fb f6:c0 f8 f1 ] fffff801a4c4b83e - nt!ExFreePoolWithTag+83e (+0x4b7) [ f6:f1 ] fffff801a4c4cc85-fffff801a4c4cc87 3 bytes - nt!ExDeferredFreePool+4e5 (+0x1447) [ 40 fb f6:c0 f8 f1 ] fffff801a4c4ccba - nt!ExDeferredFreePool+51a (+0x35) [ fa:8b ] fffff801a4c54f30-fffff801a4c54f31 2 bytes - nt!_guard_dispatch_icall_fptr [ 70 67:b0 fa ] fffff801a4dcc491 - nt!MmDuplicateMemory+231 [ fa:8b ] fffff801a4dcc4e9 - nt!MmDuplicateMemory+289 (+0x58) [ fa:8b ] fffff801a4dcc56e - nt!MmDuplicateMemory+30e (+0x85) [ fa:8b ] fffff801a4dcc799 - nt!MmDuplicateMemory+539 (+0x22b) [ fa:8b ] fffff801a4dcce21 - nt!MiMarkKernelPageTablePages+d (+0x688) [ f6:f1 ] fffff801a4dcce72 - nt!MiMarkKernelPageTablePages+5e (+0x51) [ f7:f2 ] fffff801a4dcd371 - nt!MmMarkHiberPhase+71 (+0x4ff) [ fa:8b ] fffff801a4dcd388 - nt!MmMarkHiberPhase+88 (+0x17) [ fa:8b ] fffff801a4dcd97b - nt!MiMarkHiberNotCachedPages+2b (+0x5f3) [ fa:8b ] fffff801a4dcda93 - nt!MiMarkNonPagedHiberPhasePages+67 (+0x118) [ fa:8b ] fffff801a4dcdb5e - nt!MiMarkKernelPageTablesHelper+3e (+0xcb) [ f6:f1 ] fffff801a4dcde0d - nt!MiEnumerateKernelLeafPtes+11 (+0x2af) [ f6:f1 ] fffff801a4dcde17 - nt!MiEnumerateKernelLeafPtes+1b (+0x0a) [ f7:f2 ] fffff801a4dd064b - nt!MmInitializeProcessor+3b (+0x2834) [ f6:f1 ] fffff801a4dd4d1c - nt! ?? ::OKHAJAOM::`string'+28ac (+0x46d1) [ fa:8b ] fffff801a4dd4da4 - nt! ?? ::OKHAJAOM::`string'+2934 (+0x88) [ fa:8b ] fffff801a4dd4e4c - nt! ?? ::OKHAJAOM::`string'+29dc (+0xa8) [ fa:8b ] fffff801a4dd4f56 - nt! ?? ::OKHAJAOM::`string'+2ae6 (+0x10a) [ fa:8b ] fffff801a4ddd55f - nt!MmFreeIndependentPages+53 [ fa:8b ] fffff801a4e35d5d - nt!MmChangeImageProtection+159 (+0x587fe) [ fa:8b ] fffff801a4e35f64 - nt!MiAllocateDriverPage+9c (+0x207) [ fa:8b ] fffff801a4e35fcf - nt!MiValidateImagePfn+3b (+0x6b) [ fa:8b ] fffff801a4e36019 - nt!MiValidateImagePfn+85 (+0x4a) [ f6:f1 ] fffff801a4e37476-fffff801a4e3747a 5 bytes - nt!MiInitializeWorkingSetList+f2 (+0x145d) [ d0 be 7d fb f6:30 7e fc f8 f1 ] fffff801a4e374ba - nt!MiInitializeWorkingSetList+136 (+0x44) [ fa:8b ] fffff801a4e3750d - nt!MiInitializeWorkingSetList+189 (+0x53) [ fa:8b ] fffff801a4e5dfd9 - nt!PfpPfnPrioRequest+99 (+0x26acc) [ fa:8b ] fffff801a4e5e018 - nt!PfpPfnPrioRequest+d8 (+0x3f) [ fa:8b ] fffff801a4e754be - nt!MiReleaseProcessReferenceToSessionDataPage+a2 (+0x174a6) [ fa:8b ] fffff801a4e848a4-fffff801a4e848a6 3 bytes - nt!MiMapViewOfDataSection+c44 (+0xf3e6) [ 40 fb f6:c0 f8 f1 ] fffff801a4e848e9-fffff801a4e848ed 5 bytes - nt!MiMapViewOfDataSection+c89 (+0x45) [ d7 be 7d fb f6:37 7e fc f8 f1 ] fffff801a4e85e9e - nt!MiReturnPageTablePageCommitment+16e (+0x15b5) [ f6:f1 ] fffff801a4e87c73 - nt!MiPfPrepareSequentialReadList+2e3 (+0x1dd5) [ fa:8b ] fffff801a4e8aa73 - nt!MiRelocateImagePfn+73 (+0x2e00) [ fa:8b ] fffff801a4e8aa80 - nt!MiRelocateImagePfn+80 (+0x0d) [ f6:f1 ] fffff801a4e8aa9b - nt!MiRelocateImagePfn+9b (+0x1b) [ f6:f1 ] fffff801a4e9624f - nt!MiPfPrepareReadList+4cf (+0xb7b4) [ fa:8b ] fffff801a4eb63a7 - nt!MiCreateImageFileMap+ff (+0x20158) [ fa:8b ] fffff801a4eba05c - nt!MiPrefetchDriverPages+24 (+0x3cb5) [ f6:f1 ] fffff801a4eba8d2 - nt!MmCreateProcessAddressSpace+1de (+0x876) [ fa:8b ] fffff801a4eba965 - nt!MmCreateProcessAddressSpace+271 (+0x93) [ f6:f1 ] fffff801a4ebaa88 - nt!MmCreateProcessAddressSpace+394 (+0x123) [ fa:8b ] fffff801a4ee448b - nt!MiFreeDriverInitialization+5f (+0x29a03) [ f6:f1 ] fffff801a4ee465c - nt!MiFreeInitializationCode+150 (+0x1d1) [ fa:8b ] fffff801a4eef2ee - nt!MiSelectSystemImageAddress+26 (+0xac92) [ f6:f1 ] fffff801a4ef700f - nt!MmAllocateIndependentPages+6f (+0x7d21) [ f6:f1 ] fffff801a4ef70b5 - nt!MmAllocateIndependentPages+115 (+0xa6) [ fa:8b ] fffff801a4f11a7d - nt!MmAllocateMappingAddress+95 (+0x1a9c8) [ f6:f1 ] fffff801a4f170f9-fffff801a4f170fd 5 bytes - nt!MiDereferenceSessionFinal+1a9 (+0x567c) [ d0 be 7d fb f6:30 7e fc f8 f1 ] fffff801a4f1ffea-fffff801a4f1ffec 3 bytes - nt!MiInitializeDynamicBitmap+fe (+0x8ef1) [ 40 fb f6:c0 f8 f1 ] fffff801a4f2002e-fffff801a4f20031 4 bytes - nt!MiInitializeDynamicBitmap+142 (+0x44) [ a0 7d fb f6:60 fc f8 f1 ] fffff801a4f20040-fffff801a4f20044 5 bytes - nt!MiInitializeDynamicBitmap+154 (+0x12) [ d0 be 7d fb f6:30 7e fc f8 f1 ] fffff801a4f2012d - nt!MiInitializeDynamicBitmap+241 (+0xed) [ f6:f1 ] fffff801a4f2016f - nt!MiInitializeDynamicBitmap+283 (+0x42) [ fa:8b ] fffff801a4f205dd - nt!MiSessionCreateInternal+12d (+0x46e) [ f6:f1 ] fffff801a4f2083b - nt!MiMapNewSession+c3 (+0x25e) [ fa:8b ] fffff801a4f2084d-fffff801a4f2084f 3 bytes - nt!MiMapNewSession+d5 (+0x12) [ 40 fb f6:c0 f8 f1 ] fffff801a4f20856-fffff801a4f20859 4 bytes - nt!MiMapNewSession+de (+0x09) [ a0 7d fb f6:60 fc f8 f1 ] fffff801a4f208ec-fffff801a4f208f0 5 bytes - nt!MiMapNewSession+174 (+0x96) [ d0 be 7d fb f6:30 7e fc f8 f1 ] fffff801a4f20951-fffff801a4f20954 4 bytes - nt!MiMapNewSession+1d9 (+0x65) [ a0 7d fb f6:60 fc f8 f1 ] fffff801a4f20968 - nt!MiMapNewSession+1f0 (+0x17) [ fa:8b ] fffff801a4f2097a-fffff801a4f2097c 3 bytes - nt!MiMapNewSession+202 (+0x12) [ 40 fb f6:c0 f8 f1 ] fffff801a4f209ca - nt!MiMapNewSession+252 (+0x50) [ fa:8b ] fffff801a4f20a30-fffff801a4f20a32 3 bytes - nt!MiMapNewSession+2b8 (+0x66) [ 40 fb f6:c0 f8 f1 ] fffff801a4f20a69-fffff801a4f20a6c 4 bytes - nt!MiMapNewSession+2f1 (+0x39) [ a0 7d fb f6:60 fc f8 f1 ] fffff801a4f20a7e-fffff801a4f20a82 5 bytes - nt!MiMapNewSession+306 (+0x15) [ d0 be 7d fb f6:30 7e fc f8 f1 ] fffff801a4f2a136 - nt!MiReleaseDriverPtes+42 (+0x96b8) [ f6:f1 ] fffff801a4f2a22a - nt!MiReleaseDriverPtes+136 (+0xf4) [ f6:f1 ] WARNING: !chkimg output was truncated to 50 lines. Invoke !chkimg without '-lo [num_lines]' to view entire output. 3022 errors : !nt (fffff801a4a01595-fffff801a50662d2) MODULE_NAME: memory_corruption IMAGE_NAME: memory_corruption FOLLOWUP_NAME: memory_corruption DEBUG_FLR_IMAGE_TIMESTAMP: 0 MEMORY_CORRUPTOR: LARGE FAILURE_BUCKET_ID: MEMORY_CORRUPTION_LARGE BUCKET_ID: MEMORY_CORRUPTION_LARGE PRIMARY_PROBLEM_CLASS: MEMORY_CORRUPTION_LARGE TARGET_TIME: 2016-12-13T14:45:36.000Z OSBUILD: 14393 OSSERVICEPACK: 0 SERVICEPACK_NUMBER: 0 OS_REVISION: 0 SUITE_MASK: 784 PRODUCT_TYPE: 1 OSPLATFORM_TYPE: x64 OSNAME: Windows 10 OSEDITION: Windows 10 WinNt TerminalServer SingleUserTS Personal OS_LOCALE: USER_LCID: 0 OSBUILD_TIMESTAMP: 2016-10-05 10:17:53 BUILDDATESTAMP_STR: 161004-2338 BUILDLAB_STR: rs1_release_inmarket BUILDOSVER_STR: 10.0.14393.321.amd64fre.rs1_release_inmarket.161004-2338 ANALYSIS_SESSION_ELAPSED_TIME: 1638 ANALYSIS_SOURCE: KM FAILURE_ID_HASH_STRING: km:memory_corruption_large FAILURE_ID_HASH: {e29154ac-69a4-0eb8-172a-a860f73c0a3c} Followup: memory_corruption ---------
  Message 2 of 7  
25 Jan 17 12:58
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11673
bugcheck with MEMORY_CORRUPTION_LARGE

xxxxx@cxxl.de wrote: > I got a kernel memory dump from one of our customers. It shows loads (3022!) memory corruptions. But they are very orderly, so I'm sure it's not just random corruption. I checked some code addresses and it looked like this: This is just way too suspicious. It really looks like someone did a search-and-replace for certain patterns. I presume cfosspeed6 is your NDIS filter driver. What is it doing, in general terms? Is it possible you're looking for patterns? Could your pattern search have gone awry? -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 3 of 7  
25 Jan 17 13:57
Alex Grig
xxxxxx@broadcom.com
Join Date: 14 Apr 2008
Posts To This List: 3219
bugcheck with MEMORY_CORRUPTION_LARGE

Those "corruptions" are just a bunch of red herring. These are just normal relocations. Check the relocation table and see. The debugger is way too happy to spew this BS when it had access to the binaries (through the symbol server).
  Message 4 of 7  
25 Jan 17 13:59
Alex Grig
xxxxxx@broadcom.com
Join Date: 14 Apr 2008
Posts To This List: 3219
bugcheck with MEMORY_CORRUPTION_LARGE

When you call NdisFIndicateReceiveNetBufferLists, check if you're on the correct IRQL and if you pass a correct flag reflecting the IRQL.
  Message 5 of 7  
17 Feb 17 03:48
chris lueders
xxxxxx@cxxl.de
Join Date: 12 Sep 2007
Posts To This List: 5
bugcheck with MEMORY_CORRUPTION_LARGE

Thanks for your replies. I've checked IRQL and the NdisFIndicateReceiveNetBufferLists function doc and my use of the function, but cannot find any fault. Furthermore, windbg mentions this in his "!analyze -v" output: Arg1: 0000000000000000, (Current IRQL << 16) | (Expected IRQL << 8) | UniqueValue So, it's supposed to be 0 and it is 0. Did I miss something? Does any of you have a lead for me? Thanks, Chris
  Message 6 of 7  
17 Feb 17 09:04
Scott Noone
xxxxxx@osr.com
Join Date:
Posts To This List: 1341
List Moderator
bugcheck with MEMORY_CORRUPTION_LARGE

The bugcheck description clearly doesn’t match the usage of the code in this function. I'd actually classify this as an OS bug, but at a minimum it's a documentation issue. Here’s the relevant assembly from Win10 RS1 (much trimmed for brevity): mov rsi, cr8 ; Get the current IRQL ... call qword ptr [rsp+60h] ; Call the stack expand callback ... mov rax, cr8 ; Get the current IRQL cmp al, sil ; Are they the same? jz short loc_14007040C ; If yes just return, otherwise crash with C8 movzx r8d, al ; BugcheckArg1 = Current IRQL movzx edx, sil ; BugcheckArg2 = Previous IRQL ... mov ecx, 0C8h ; IRQL_UNEXPECTED_VALUE call KeBugCheckEx ; Grand closing... So, the bugcheck would actually indicate that someone was called at DISPATCH_LEVEL but they lowered the IRQL to PASSIVE_LEVEL. Have you tried running Driver Verifier yet? I'd enable it on all the network drivers present (including NDIS) and see what you get. -scott OSR @OSRDrivers wrote in message news:222371@ntdev... Thanks for your replies. I've checked IRQL and the NdisFIndicateReceiveNetBufferLists function doc and my use of the function, but cannot find any fault. Furthermore, windbg mentions this in his "!analyze -v" output: Arg1: 0000000000000000, (Current IRQL << 16) | (Expected IRQL << 8) | UniqueValue So, it's supposed to be 0 and it is 0. Did I miss something? Does any of you have a lead for me? Thanks, Chris
  Message 7 of 7  
23 Feb 17 05:20
chris lueders
xxxxxx@cxxl.de
Join Date: 12 Sep 2007
Posts To This List: 5
bugcheck with MEMORY_CORRUPTION_LARGE

Scott, thanks for your help. I tried Verifier on Win8 and Win10RS1, but could not reproduce the crash. I've asked the customer to use Verifier. Maybe I can get a new dump and learn more from that. Thanks again!
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 10:17.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license