Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


bugcheck with MEMORY_CORRUPTION_LARGE

chris_luederschris_lueders Member Posts: 7
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*http://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
---------

Comments

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,821
    [email protected] 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, [email protected]
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Alex_GrigAlex_Grig Member Posts: 3,238
    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).
  • Alex_GrigAlex_Grig Member Posts: 3,238
    When you call NdisFIndicateReceiveNetBufferLists, check if you're on the correct IRQL and if you pass a correct flag reflecting the IRQL.
  • chris_luederschris_lueders Member Posts: 7
    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
  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,400
    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:[email protected]

    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

    -scott
    OSR

  • chris_luederschris_lueders Member Posts: 7
    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!
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE