Analyze BSOD WHEA_UNCORRECTABLE_ERROR WIN8 Driver - windows

I have a new Computer for 3 Weeks now and i get a lot of WHEA_UNCORRECTABLE_ERROR BSODs.
I get These Bluescreens random every 30 - 50 minutes.
Here is the dump from WinDbg:
Microsoft (R) Windows Debugger Version 6.2.9200.20512 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Windows\Minidump\050913-7984-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: SRV*c:\Symbole*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 8 Kernel Version 9200 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 9200.16551.amd64fre.win8_gdr.130306-1502
Machine Name:
Kernel base = 0xfffff80104018000 PsLoadedModuleList = 0xfffff801042e4b00
Debug session time: Thu May 9 17:12:45.597 2013 (UTC + 2:00)
System Uptime: 0 days 0:00:25.246
Loading Kernel Symbols
...............................................................
................................................................
..................
Loading User Symbols
Loading unloaded module list
.......
*
Bugcheck Analysis *
*
Use !analyze -v to get detailed debugging information.
BugCheck 124, {0, fffffa8008c87028, be200000, 2110a}
Probably caused by : GenuineIntel
Followup: MachineOwner
1: kd> !analyze -v
*
Bugcheck Analysis *
*
WHEA_UNCORRECTABLE_ERROR (124)
A fatal hardware error has occurred. Parameter 1 identifies the type of error
source that reported the error. Parameter 2 holds the address of the
WHEA_ERROR_RECORD structure that describes the error conditon.
Arguments:
Arg1: 0000000000000000, Machine Check Exception
Arg2: fffffa8008c87028, Address of the WHEA_ERROR_RECORD structure.
Arg3: 00000000be200000, High order 32-bits of the MCi_STATUS value.
Arg4: 000000000002110a, Low order 32-bits of the MCi_STATUS value.
Debugging Details:
BUGCHECK_STR: 0x124_GenuineIntel
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
PROCESS_NAME: System
CURRENT_IRQL: f
STACK_TEXT:
fffff880009f9868 fffff8010479193d : 0000000000000124 0000000000000000 fffffa8008c87028 00000000be200000 : nt!KeBugCheckEx
fffff880009f9870 fffff80104178969 : 0000000000000001 fffffa80066d7320 0000000000000000 fffffa8008c87028 : hal!HalBugCheckSystem+0xf9
fffff880009f98b0 fffff801047916e3 : 0000000000000728 0000000000000001 fffff880009f9a10 fffffa80066d7320 : nt!WheaReportHwError+0x249
fffff880009f9910 fffff8010479100c : 0000000000000010 fffffa80066d7320 fffff880009f9ac8 fffffa80066d7320 : hal!HalpMcaReportError+0x53
fffff880009f9a70 fffff80104790f07 : fffffa800678b760 0000000000000001 0000000000000001 0000000000000000 : hal!HalpMceHandlerCore+0xd4
fffff880009f9ac0 fffff80104790d64 : 0000000000000004 0000000000000001 0000000000000000 0000000000000000 : hal!HalpMceHandler+0xe3
fffff880009f9b00 fffff80104791edb : fffffa800678b760 fffff880009f9d30 0000000000000000 0000000000000000 : hal!HalpMceHandlerWithRendezvous+0xd4
fffff880009f9b30 fffff8010407057b : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : hal!HalHandleMcheck+0x40
fffff880009f9b60 fffff8010407032e : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KxMcheckAbort+0x7b
fffff880009f9ca0 fffff8800158e984 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiMcheckAbort+0x16e
fffff88002e1b888 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : intelppm!MWaitIdle+0x18
STACK_COMMAND: kb
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: GenuineIntel
IMAGE_NAME: GenuineIntel
DEBUG_FLR_IMAGE_TIMESTAMP: 0
FAILURE_BUCKET_ID: 0x124_GenuineIntel_PROCESSOR_CACHE
BUCKET_ID: 0x124_GenuineIntel_PROCESSOR_CACHE
Followup: MachineOwner
I have also reinstalled Windows 3 times now but every time i get These Errors.
Can anyone tell me whats the Problem is?
Greets


This might cause by INTEL CPU driver, for energy management or etc. try not to install intel cpu driver(might delivered with motherboard).

Related

The KMDF driver crashes with no useful information from !analyze -v

I am trying to debug Hello World KMDF driver from MSDN in Virtual Box. Symbols loads and everything looks fine. But when I am trying to debug the code the following happens:
-----------------------------------------------------------------------
-----------------------------------------------------------------------
Starting New Debugger Session
-----------------------------------------------------------------------
-----------------------------------------------------------------------
[debug session data]
Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPointWithStatus:
fffff807`0d262390 cc int 3
I don't know what that breakpoint is. Moreover it remains when I am debugging another example driver.
The following message the only message I recieve when I run the driver and hit Break All button regardless of another breakpoints setted or not.
kd> g
Break instruction exception - code 80000003 (first chance)
*******************************************************************************
* *
* You are seeing this message because you pressed either *
* CTRL+C (if you run console kernel debugger) or, *
* CTRL+BREAK (if you run GUI kernel debugger), *
* on your debugger machine's keyboard. *
* *
* THIS IS NOT A BUG OR A SYSTEM CRASH *
* *
* If you did not intend to break into the debugger, press the "g" key, then *
* press the "Enter" key now. This message might immediately reappear. If it *
* does, press "g" and "Enter" again. *
* *
*******************************************************************************
nt!DbgBreakPointWithStatus:
fffff807`0d262390 cc int 3
And adress of the breakpont is always the same. Also the debugger does not pick up the source code and local variables.
The !analyze -v response is hard to interpret because it almost has no specific information:
kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Unknown bugcheck code (0)
Unknown bugcheck description
Arguments:
Arg1: 0000000000000000
Arg2: 0000000000000000
Arg3: 0000000000000000
Arg4: 0000000000000000
Debugging Details:
------------------
KEY_VALUES_STRING: 1
STACKHASH_ANALYSIS: 1
TIMELINE_ANALYSIS: 1
DUMP_CLASS: 1
DUMP_QUALIFIER: 0
BUILD_VERSION_STRING: 17763.1.amd64fre.rs5_release.180914-1434
DUMP_TYPE: 0
BUGCHECK_P1: 0
BUGCHECK_P2: 0
BUGCHECK_P3: 0
BUGCHECK_P4: 0
PROCESS_NAME: svchost.exe
FAULTING_IP:
nt!DbgBreakPointWithStatus+0
fffff807`0d262390 cc int 3
ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint has been reached.
EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid
EXCEPTION_CODE_STR: 80000003
EXCEPTION_PARAMETER1: 0000000000000000
CPU_COUNT: 1
CPU_MHZ: e10
CPU_VENDOR: GenuineIntel
CPU_FAMILY: 6
CPU_MODEL: 9e
CPU_STEPPING: 9
CPU_MICROCODE: 6,9e,9,0 (F,M,S,R) SIG: 0'00000000 (cache) 0'00000000 (init)
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
BUGCHECK_STR: 0x0
CURRENT_IRQL: d
ANALYSIS_SESSION_HOST: DESKTOP-7FEEGEP
ANALYSIS_SESSION_TIME: 05-17-2019 13:39:22.0086
ANALYSIS_VERSION: 10.0.17763.132 amd64fre
STACK_TEXT:
fffff807`0f46db78 fffff807`0d27721e : fffff807`0ce14180 00000000`00000001 ffffd087`89a36080 00000000`0000806c : nt!DbgBreakPointWithStatus
fffff807`0f46db80 fffff807`0d2d3c04 : ffffd087`84602020 00000000`00000000 00000000`0000806b fffff807`0d01446f : nt!KdCheckForDebugBreak+0x90e66
fffff807`0f46dbb0 fffff807`0d18bdf4 : 00000000`00000000 00000000`00000000 00000000`0000806c fffff807`0ce14180 : nt!KeAccumulateTicks+0x144cd4
fffff807`0f46dc10 fffff807`0d011332 : 00000000`00000000 fffff807`0d074be8 fffff903`28437b80 00000000`00000000 : nt!KeClockInterruptNotify+0x604
fffff807`0f46df30 fffff807`0d1da195 : 000000b9`9e48c277 fffff807`0d077850 fffff807`0d077900 fffff903`28437b80 : hal!HalpTimerClockInterrupt+0xf2
fffff807`0f46df60 fffff807`0d25c12a : fffff903`28437b80 fffff807`0d077850 00000000`000000bc fffff807`0d077850 : nt!KiCallInterruptServiceRoutine+0xa5
fffff807`0f46dfb0 fffff807`0d25c677 : 00000127`1c58e310 fffff903`28437b80 ffffba01`a64f3c80 ffffd087`00001680 : nt!KiInterruptSubDispatchNoLockNoEtw+0xfa
fffff903`28437b00 00007ffe`6d921d90 : 00007ffe`63c76dc9 00000000`00000030 00000127`1c58e310 00000127`1cf29fc6 : nt!KiInterruptDispatchNoLockNoEtw+0x37
0000001b`4ddfda48 00007ffe`63c76dc9 : 00000000`00000030 00000127`1c58e310 00000127`1cf29fc6 00000000`00000086 : ntdll!RtlLeaveCriticalSection
0000001b`4ddfda50 00007ffe`63c75c4a : 00000127`1c58e310 00000000`00000000 00000127`1cf29fc6 00000000`00000001 : StateRepository_Core!dbMallocRawFinish+0xf9
0000001b`4ddfda80 00007ffe`63c74318 : 0000001b`4ddfdc90 00000127`218eaab5 0000001b`4ddfdad0 0000001b`4ddfe500 : StateRepository_Core!sqlite3ExprListAppend+0x10a
0000001b`4ddfdab0 00007ffe`63c73f4f : 00000127`218eaab5 00000000`0000003b 0000001b`4ddfe600 00000127`218eaab5 : StateRepository_Core!yy_reduce+0x138
0000001b`4ddfdb60 00007ffe`63c714d0 : 00000000`0000000b 00000127`1d48d4c0 00000127`17a60000 00000127`1c58e310 : StateRepository_Core!sqlite3RunParser+0x18f
0000001b`4ddfe5a0 00007ffe`63c7fad6 : 00000127`0000000b 00000127`210c9e50 00000127`1d48d4c0 00000127`1c58e310 : StateRepository_Core!sqlite3Prepare+0x140
0000001b`4ddfe8a0 00007ffe`63c77470 : 00000000`00000000 00000000`00000001 00000127`227c5620 00000127`1c58e310 : StateRepository_Core!sqlite3Reprepare+0xa6
0000001b`4ddfe910 00007ffe`5baa75ed : 0000001b`4ddfea40 00000000`00000000 0000001b`4ddfeb30 00000000`00000001 : StateRepository_Core!sqlite3_step+0x1e0
0000001b`4ddfe940 0000001b`4ddfea40 : 00000000`00000000 0000001b`4ddfeb30 00000000`00000001 00000127`227c5620 : appxdeploymentserver+0x1975ed
0000001b`4ddfe948 00000000`00000000 : 0000001b`4ddfeb30 00000000`00000001 00000127`227c5620 00000000`00000000 : 0x0000001b`4ddfea40
THREAD_SHA1_HASH_MOD_FUNC: 7624d44a362bc09f63010be40dd2f10b30164688
THREAD_SHA1_HASH_MOD_FUNC_OFFSET: 116dd5b296cb899eb0af37455673964c028141de
THREAD_SHA1_HASH_MOD: eeaa9c3cd71569b57a2e0c61a2a59028a432624c
FOLLOWUP_IP:
nt!DbgBreakPointWithStatus+0
fffff807`0d262390 cc int 3
FAULT_INSTR_CODE: ccccc3cc
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: nt!DbgBreakPointWithStatus+0
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 438ffec3
STACK_COMMAND: .thread ; .cxr ; kb
BUCKET_ID: MANUAL_BREAKIN
PRIMARY_PROBLEM_CLASS: MANUAL_BREAKIN
FAILURE_BUCKET_ID: MANUAL_BREAKIN
TARGET_TIME: 2019-05-17T10:34:32.000Z
OSBUILD: 17763
OSSERVICEPACK: 0
SERVICEPACK_NUMBER: 0
OS_REVISION: 0
SUITE_MASK: 272
PRODUCT_TYPE: 1
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
OSEDITION: Windows 10 WinNt TerminalServer SingleUserTS
OS_LOCALE:
USER_LCID: 0
OSBUILD_TIMESTAMP: 2005-12-02 00:58:59
BUILDDATESTAMP_STR: 180914-1434
BUILDLAB_STR: rs5_release
BUILDOSVER_STR: 10.0.17763.1.amd64fre.rs5_release.180914-1434
ANALYSIS_SESSION_ELAPSED_TIME: 69b
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:manual_breakin
FAILURE_ID_HASH: {30cbeaaa-35e3-de0f-a585-406cd241c851}
Followup: MachineOwner
---------
I confused a little by DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT line because I build the driver for Windows 10. And also by IMAGE_NAME: ntkrnlmp.exe. Looks like something happens in nt module. Googling gave no results.
Same things happens with another driver samples I tried to debug.
How can I handle this problem or at least to get more information about it?
Host: Windows 10 x64 build 17134.765, VS Community 2017 build 15.9.11, WDK 10.0.17740.1000
Target: Virtual Box build 6.0.4r128413, Windows 10 x64 build 17763.437

Winsock Kernel's "WskSendTo" function causes "DRIVER_IRQL_NOT_LESS_OR_EQUAL" BSOD on Win7 SP1

I'm developing a Windows packet capture software called Npcap. And it needs to send loopback raw IP sockets based on Windows Kernel. But the WskSocket->Dispatch->WskSendTo always causes DRIVER_IRQL_NOT_LESS_OR_EQUAL BSOD on Win7 SP1. The strange thing is that my code doesn't trigger this BSoD on other systems like Win8, Win10. It only happens on Win7. So I even doubt that is this a bug of Windows itself or only my bug? Thanks!
The reproduce steps are:
Install Npcap 0.07 r17 with default options
Install Nmap 7.20 Beta 5 (don't install the shipped Npcap)
In CMD, run nmap -v -O -6 localhost to perform a localhost scan (this functionality is provided by Npcap), you will encounter the BSoD in a couple of seconds.
If you want the faulty driver's debug symbols, it can be downloaded here. Refer to \npcap-DebugSymbols\win7\x64\npcap.pdb for x64 system and \npcap-DebugSymbols\win7\x86\npcap.pdb for x86 system.
The BSOD analysis from WinDbg (I have the full dump, tell me if needed):
************* Symbol Path validation summary **************
Response Time (ms) Location
OK J:\npcap\packetWin7\npf\x64\Win7 Release(WinPcap Mode)
Deferred SRV*J:\Symbols*http://msdl.microsoft.com/download/symbols
Microsoft (R) Windows Debugger Version 10.0.10586.567 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Users\Administrator\Desktop\New folder (2)\MEMORY.DMP]
Kernel Complete Dump File: Full address space is available
************* Symbol Path validation summary **************
Response Time (ms) Location
OK J:\npcap\packetWin7\npf\x64\Win7 Release(WinPcap Mode)
Deferred SRV*J:\Symbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: J:\npcap\packetWin7\npf\x64\Win7 Release(WinPcap Mode);SRV*J:\Symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.18798.amd64fre.win7sp1_gdr.150316-1654
Machine Name:
Kernel base = 0xfffff800`02a0a000 PsLoadedModuleList = 0xfffff800`02c4f890
Debug session time: Thu Jun 23 13:50:07.660 2016 (UTC + 8:00)
System Uptime: 0 days 0:31:55.712
Loading Kernel Symbols
...............................................................
................................................................
..............................
Loading User Symbols
.....
Loading unloaded module list
..................Unable to enumerate user-mode unloaded modules, NTSTATUS 0xC0000147
Loading Wow64 Symbols
............................................
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck D1, {0, 2, 8, 0}
"kernel32.dll" was not found in the image list.
Debugger will attempt to load "kernel32.dll" at given base 00000000`00000000.
Please provide the full image name, including the extension (i.e. kernel32.dll)
for more reliable results.Base address and size overrides can be given as
.reload <image.ext>=<base>,<size>.
Unable to add module at 00000000`00000000
Probably caused by : npcap.sys ( npcap!WSKSendTo_NBL+d4 )
Followup: MachineOwner
---------
************* Symbol Path validation summary **************
Response Time (ms) Location
OK J:\npcap\packetWin7\npf\x64\Win7 Release
Deferred SRV*J:\Symbols*http://msdl.microsoft.com/download/symbols
0: kd> .reload
Loading Kernel Symbols
...............................................................
................................................................
..............................
Loading User Symbols
.....
Loading unloaded module list
..................Unable to enumerate user-mode unloaded modules, NTSTATUS 0xC0000147
Loading Wow64 Symbols
............................................
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: 0000000000000000, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000008, value 0 = read operation, 1 = write operation
Arg4: 0000000000000000, address which referenced memory
Debugging Details:
------------------
"kernel32.dll" was not found in the image list.
Debugger will attempt to load "kernel32.dll" at given base 00000000`00000000.
Please provide the full image name, including the extension (i.e. kernel32.dll)
for more reliable results.Base address and size overrides can be given as
.reload <image.ext>=<base>,<size>.
Unable to add module at 00000000`00000000
DUMP_CLASS: 1
DUMP_QUALIFIER: 402
BUILD_VERSION_STRING: 7601.18798.amd64fre.win7sp1_gdr.150316-1654
SYSTEM_MANUFACTURER: VMware, Inc.
VIRTUAL_MACHINE: VMware
SYSTEM_PRODUCT_NAME: VMware Virtual Platform
SYSTEM_VERSION: None
BIOS_VENDOR: Phoenix Technologies LTD
BIOS_VERSION: 6.00
BIOS_DATE: 07/02/2015
BASEBOARD_MANUFACTURER: Intel Corporation
BASEBOARD_PRODUCT: 440BX Desktop Reference Platform
BASEBOARD_VERSION: None
DUMP_TYPE: 0
BUGCHECK_P1: 0
BUGCHECK_P2: 2
BUGCHECK_P3: 8
BUGCHECK_P4: 0
READ_ADDRESS: 0000000000000000
CURRENT_IRQL: 2
FAULTING_IP:
+0
00000000`00000000 ?? ???
PROCESS_NAME: nmap.exe
CPU_COUNT: 2
CPU_MHZ: a29
CPU_VENDOR: GenuineIntel
CPU_FAMILY: 6
CPU_MODEL: 5e
CPU_STEPPING: 3
CPU_MICROCODE: 6,5e,3,0 (F,M,S,R) SIG: 23'00000000 (cache) 23'00000000 (init)
DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
BUGCHECK_STR: 0xD1
ANALYSIS_SESSION_HOST: DESKTOP-AKQG651
ANALYSIS_SESSION_TIME: 06-23-2016 13:56:03.0297
ANALYSIS_VERSION: 10.0.10586.567 amd64fre
TRAP_FRAME: fffff88006aa5680 -- (.trap 0xfffff88006aa5680)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffffa80018ede30 rbx=0000000000000000 rcx=fffffa8001a13390
rdx=fffffa800108de20 rsi=0000000000000000 rdi=0000000000000000
rip=0000000000000000 rsp=fffff88006aa5818 rbp=fffff88008565d06
r8=fffff880017684e8 r9=fffff8800164f030 r10=0000000000000000
r11=fffff88006aa5480 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
00000000`00000000 ?? ???
Resetting default scope
IP_IN_FREE_BLOCK: 0
LAST_CONTROL_TRANSFER: from fffff80002a7bfe9 to fffff80002a7ca40
FAILED_INSTRUCTION_ADDRESS:
+0
00000000`00000000 ?? ???
STACK_TEXT:
fffff880`06aa5818 fffff880`0173d917 : fffffa80`0108df50 fffffa80`0108df50 00000000`00000018 00000000`00000018 : 0x0
fffff880`06aa5820 fffff880`0173fe02 : fffffa80`026cc080 fffffa80`01d89080 00000000`00000087 00000000`00000000 : tcpip!Ipv6pHandleNeighborSolicitation+0x257
fffff880`06aa58e0 fffff880`0165bf9e : 00000000`00000000 00000000`00000000 fffff880`01769800 fffffa80`026cc1c0 : tcpip!Icmpv6ReceiveDatagrams+0x342
fffff880`06aa5980 fffff880`0165baaa : 00000000`00000000 fffff880`01769800 fffff880`06aa5b30 00000000`00000001 : tcpip!IppDeliverListToProtocol+0xfe
fffff880`06aa5a40 fffff880`0165b0a9 : 00000000`00000003 fffffa80`026cc100 fffff880`06aa5a03 fffff880`06aa5b30 : tcpip!IppProcessDeliverList+0x5a
fffff880`06aa5ae0 fffff880`0163e28f : fffff880`01769800 00000000`00000000 00000000`00000000 fffff880`06aa5c78 : tcpip!IppReceiveHeaderBatch+0x23a
fffff880`06aa5bc0 fffff800`02a893d8 : fffff880`01769800 00000000`00000000 00000000`00000000 00000000`00000000 : tcpip!IppLoopbackTransmit+0x38f
fffff880`06aa5c70 fffff880`0163e92f : fffff880`016916fc fffffa80`01a0f490 fffff880`06aa5e02 00000000`00000000 : nt!KeExpandKernelStackAndCalloutEx+0xd8
fffff880`06aa5d50 fffff880`0165d4ca : fffffa80`026cc1c0 00000000`00000000 fffffa80`01a0f400 fffffa80`0195e820 : tcpip!IppLoopbackEnqueue+0x22f
fffff880`06aa5e00 fffff880`0165ebf5 : 00000000`00000000 fffffa80`036f4900 fffffa80`019ae400 00000000`000000fa : tcpip!IppDispatchSendPacketHelper+0x38a
fffff880`06aa5ec0 fffff880`0165de7e : fffffa80`019ae4fa fffff880`06aa6200 00000000`00000028 fffffa80`00000000 : tcpip!IppPacketizeDatagrams+0x2d5
fffff880`06aa5fe0 fffff880`0166079e : 00000000`00000000 fffffa80`019b4204 fffff880`01623790 fffffa80`0195e820 : tcpip!IppSendDatagramsCommon+0x87e
fffff880`06aa6180 fffff880`01624248 : fffffa80`019b42f0 fffff880`06aa6700 00000000`00000000 00000000`000007ff : tcpip!IpNlpSendDatagrams+0x3e
fffff880`06aa61c0 fffff880`0162462d : 00000000`00000103 fffff880`01730470 fffffa80`0279c0e0 fffff880`00000001 : tcpip!RawSendMessagesOnPathCreation+0x238
fffff880`06aa63f0 fffff880`03afe69e : fffffa80`00ebc8a0 00000000`00000001 fffffa80`031ea580 fffff880`05a0a7e8 : tcpip!RawSendMessages+0x2bd
fffff880`06aa66e0 fffff880`05a01fb0 : fffffa80`02c77d48 00000025`02a80f78 fffff880`05a0a7e8 00000000`00000000 : afd!WskProIRPSendTo+0x11e
fffff880`06aa6790 fffff880`05a01bdb : 00000000`c0000001 fffffa80`033d8350 fffffa80`03cede20 fffffa80`03cede20 : npcap!WSKSendTo_NBL+0xd4 [j:\npcap\packetwin7\npf\npf\lo_send.c # 858]
fffff880`06aa6820 fffff880`05a06a0c : fffffa80`03cede20 fffffa80`033d8420 00000000`00000001 fffffa80`03e49318 : npcap!NPF_WSKSendPacket_NBL+0x93 [j:\npcap\packetwin7\npf\npf\lo_send.c # 366]
fffff880`06aa6860 fffff880`05a06e4b : 00000000`00000000 fffffa80`033d8350 fffffa80`03e40000 00000000`00000000 : npcap!NPF_LoopbackSendNetBufferLists+0x18 [j:\npcap\packetwin7\npf\npf\write.c # 1019]
fffff880`06aa6890 fffff800`02d8530b : 00000000`00000001 fffffa80`00000000 fffffa80`033d8420 fffffa80`033d8350 : npcap!NPF_Write+0x243 [j:\npcap\packetwin7\npf\npf\write.c # 328]
fffff880`06aa6900 fffff800`02d90b13 : fffffa80`033d8468 00000000`00000000 fffffa80`0269c9b0 fffffa80`033d8468 : nt!IopSynchronousServiceTail+0xfb
fffff880`06aa6970 fffff800`02a7bcd3 : 00000000`75192401 00000000`00000000 00000000`00000000 00000000`00000000 : nt!NtWriteFile+0x7e2
fffff880`06aa6a70 00000000`75192e09 : 00000000`751929f5 00000000`778201b4 00000000`74ea0023 00000000`00000246 : nt!KiSystemServiceCopyEnd+0x13
00000000`0010e4f8 00000000`751929f5 : 00000000`778201b4 00000000`74ea0023 00000000`00000246 00000000`0030f8fc : wow64cpu!CpupSyscallStub+0x9
00000000`0010e500 00000000`74ead286 : 00000000`00000000 00000000`75191920 ffffffff`fc630000 00000000`7765e021 : wow64cpu!ReadWriteFileFault+0x31
00000000`0010e5c0 00000000`74eac69e : 00000000`00000000 00000000`00000000 00000000`74ea4b10 00000000`7ffe0030 : wow64!RunCpuSimulation+0xa
00000000`0010e610 00000000`77671736 : 00000000`00472e50 00000000`00000000 00000000`7775d670 00000000`77730920 : wow64!Wow64LdrpInitialize+0x42a
00000000`0010eb60 00000000`776cca90 : 00000000`00000000 00000000`77670e41 00000000`0010f110 00000000`00000000 : ntdll!LdrpInitializeProcess+0x17e3
00000000`0010f050 00000000`7765b69e : 00000000`0010f110 00000000`00000000 00000000`7efdf000 00000000`00000000 : ntdll! ?? ::FNODOBFM::`string'+0x25cf0
00000000`0010f0c0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!LdrInitializeThunk+0xe
STACK_COMMAND: .trap 0xfffff88006aa5680 ; kb
THREAD_SHA1_HASH_MOD_FUNC: dbfd1c8718001d6bf1bf4c8614036f99d76c5b23
THREAD_SHA1_HASH_MOD_FUNC_OFFSET: bb2b8033b6c74e4069a0f00b4027a4e6f51f03e3
THREAD_SHA1_HASH_MOD: b7fd3d0a19cb3a2bbc48aa7b577ad71c3bba8ecf
FOLLOWUP_IP:
npcap!WSKSendTo_NBL+d4 [j:\npcap\packetwin7\npf\npf\lo_send.c # 858]
fffff880`05a01fb0 3d03010000 cmp eax,103h
FAULT_INSTR_CODE: 1033d
FAULTING_SOURCE_LINE: j:\npcap\packetwin7\npf\npf\lo_send.c
FAULTING_SOURCE_FILE: j:\npcap\packetwin7\npf\npf\lo_send.c
FAULTING_SOURCE_LINE_NUMBER: 858
FAULTING_SOURCE_CODE:
854: RemoteAddress,
855: 0,
856: NULL,
857: Irp);
> 858: if (Status == STATUS_PENDING)
859: {
860: KeWaitForSingleObject(&CompletionEvent, Executive, KernelMode, FALSE, NULL);
861: Status = Irp->IoStatus.Status;
862: }
863:
SYMBOL_STACK_INDEX: 10
SYMBOL_NAME: npcap!WSKSendTo_NBL+d4
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: npcap
IMAGE_NAME: npcap.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 5767b816
FAILURE_BUCKET_ID: X64_0xD1_CODE_AV_NULL_IP_npcap!WSKSendTo_NBL+d4
BUCKET_ID: X64_0xD1_CODE_AV_NULL_IP_npcap!WSKSendTo_NBL+d4
PRIMARY_PROBLEM_CLASS: X64_0xD1_CODE_AV_NULL_IP_npcap!WSKSendTo_NBL+d4
TARGET_TIME: 2016-06-23T05:50:07.000Z
OSBUILD: 7601
OSSERVICEPACK: 1000
SERVICEPACK_NUMBER: 0
OS_REVISION: 0
SUITE_MASK: 272
PRODUCT_TYPE: 1
OSPLATFORM_TYPE: x64
OSNAME: Windows 7
OSEDITION: Windows 7 WinNt (Service Pack 1) TerminalServer SingleUserTS
OS_LOCALE:
USER_LCID: 0
OSBUILD_TIMESTAMP: 2015-03-17 12:02:04
BUILDDATESTAMP_STR: 150316-1654
BUILDLAB_STR: win7sp1_gdr
BUILDOSVER_STR: 6.1.7601.18798.amd64fre.win7sp1_gdr.150316-1654
ANALYSIS_SESSION_ELAPSED_TIME: 124e
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:x64_0xd1_code_av_null_ip_npcap!wsksendto_nbl+d4
FAILURE_ID_HASH: {4a65a334-abd9-00b8-4b67-6fff67ae90f0}
Followup: MachineOwner
---------
The faulty code line is here:
https://github.com/nmap/npcap/blob/4325bdac9e8434186dca295f3b2ae893047b818f/packetWin7/npf/npf/Lo_send.c#L850-L857
The raw socket is created in the NPF_WSKInitSockets function.

from stack view - you send Icmpv6 datagram to in6LoopbackAddr - and all here correct, no mistakes. because it to in6LoopbackAddr tcpip.sys just Icmpv6ReceiveDatagrams called. in function Icmpv6ReceiveDatagrams exist switch, how packet process, based on 1 byte from packet:
switch (cl)
{
case 0x80: Icmpv6pHandleEchoRequest();break;
case 0x81: Icmpv6pHandleEchoReplyAndError();break;
case 0x82: Ipv6pHandleMldQuery();break;
case 0x83: Ipv6pHandleMldReport();break;
case 0x85: Ipv6pHandleRouterSolication();break;
case 0x86: Ipv6pHandleRouterAdvertisement();break;
case 0x87: Ipv6pHandleNeighborSolicitation();break;
case 0x89: Ipv6pHandleRedirect();break;
}
our case is (87) - Ipv6pHandleNeighborSolicitation(x,y) . and in Ipv6pHandleNeighborSolicitation crash at next line -
call qword ptr [r8+50h] // 0 at r8+50h
so tcpip try call some callback, but it is zero. i look, what at memory to which r8 point, here some callbacks table. all functions from tcpip.sys (so this not your WSK callbacks):
08 FllQueryInterface
10 WfpInbuiltCalloutNotifyNull
18 FlQuerySubInterface
20 WfpInbuiltCalloutNotifyNull
28 IppCleanupNlp
30 FllMapAddress
38 FllSendPackets
40 FllFastSendPackets
48 FllCancelSendPackets
50 0 - and this 0 and called !
this is on win7. but if look on win8.1 and win10 in same place - already no any callback called - this code is removed. so i guess this is faster win7 bug than your - no memory corruption, wrong calls, not init structs.. but same zero callback, and think not you must init it. and no this callbacks on later windows versions. from another side - i dont sure, are Ipv6pHandleNeighborSolicitation() - function,that you want to be called on packet. may be wrong icmp packet format ?
of course this not full response, but something
some place on win8.1
and on win10

How to read a Windows 10 BSOD mini dump analysis

I'm hoping someone here can help.
I have a new Windows 10 machine (all parts by EVGA).
I get random BSOD, so I've grabbed a mini dump, installed the SDK and looked into it. I just don't understand what it is reporting.
Can someone point me in the direction of a guide, or decode this mini dump.
Note : Each dump looks very similar. e.g. almost the same report from 'irp'
Here is the dump....
Microsoft (R) Windows Debugger Version 10.0.10586.567 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Windows\Minidump\033016-4718-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: srv*
Executable search path is:
Windows 10 Kernel Version 10586 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 10586.162.amd64fre.th2_release_sec.160223-1728
Machine Name:
Kernel base = 0xfffff8018d674000 PsLoadedModuleList = 0xfffff8018d952cd0
Debug session time: Wed Mar 30 18:15:33.639 2016 (UTC + 1:00)
System Uptime: 0 days 2:47:26.264
Loading Kernel Symbols
.
Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.
..............................................................
................................................................
................................
Loading User Symbols
Loading unloaded module list
.............
*
Bugcheck Analysis *
*
Use !analyze -v to get detailed debugging information.
BugCheck 9F, {3, ffffe000935ea880, fffff8018f25a890, ffffe00092718bd0}
Probably caused by : ACPI.sys
Followup: MachineOwner
0: kd> !analyze -v
*
Bugcheck Analysis *
*
DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time.
Arguments:
Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
Arg2: ffffe000935ea880, Physical Device Object of the stack
Arg3: fffff8018f25a890, nt!TRIAGE_9F_POWER on Win7 and higher, otherwise the Functional Device Object of the stack
Arg4: ffffe00092718bd0, The blocked IRP
Debugging Details:
DUMP_CLASS: 1
DUMP_QUALIFIER: 400
BUILD_VERSION_STRING: 10586.162.amd64fre.th2_release_sec.160223-1728
SYSTEM_MANUFACTURER: EVGA INTERNATIONAL CO.,LTD
SYSTEM_PRODUCT_NAME: Default string
SYSTEM_SKU: Default string
SYSTEM_VERSION: Default string
BIOS_VENDOR: American Megatrends Inc.
BIOS_VERSION: 1.07
BIOS_DATE: 01/04/2016
BASEBOARD_MANUFACTURER: EVGA INTERNATIONAL CO.,LTD
BASEBOARD_PRODUCT: 111-SS-E172
BASEBOARD_VERSION: 1.0
DUMP_TYPE: 2
DUMP_FILE_ATTRIBUTES: 0x8
Kernel Generated Triage Dump
BUGCHECK_P1: 3
BUGCHECK_P2: ffffe000935ea880
BUGCHECK_P3: fffff8018f25a890
BUGCHECK_P4: ffffe00092718bd0
DRVPOWERSTATE_SUBCODE: 3
IMAGE_NAME: ACPI.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 56cbf9c9
MODULE_NAME: ACPI
FAULTING_MODULE: fffff800d5de0000 ACPI
CPU_COUNT: 8
CPU_MHZ: d50
CPU_VENDOR: GenuineIntel
CPU_FAMILY: 6
CPU_MODEL: 5e
CPU_STEPPING: 3
CPU_MICROCODE: 6,5e,3,0 (F,M,S,R) SIG: 33'00000000 (cache) 33'00000000 (init)
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
BUGCHECK_STR: 0x9F
PROCESS_NAME: System
CURRENT_IRQL: 2
ANALYSIS_SESSION_HOST: Q-PC
ANALYSIS_SESSION_TIME: 03-30-2016 20:04:47.0460
ANALYSIS_VERSION: 10.0.10586.567 x86fre
STACK_TEXT:
fffff8018f25a858 fffff8018d854e42 : 000000000000009f 0000000000000003 ffffe000935ea880 fffff8018f25a890 : nt!KeBugCheckEx
fffff8018f25a860 fffff8018d854d62 : ffffe00096133010 fffff8018f252070 0000000000000000 fffff8018d73e0a6 : nt!PopIrpWatchdogBugcheck+0xde
fffff8018f25a8c0 fffff8018d6e22c6 : ffffe00096133048 fffff8018f25aa10 0000000000000001 0000000000000002 : nt!PopIrpWatchdog+0x32
fffff8018f25a910 fffff8018d7b951a : 0000000000000000 fffff8018d991180 fffff8018da07740 ffffe00096723800 : nt!KiRetireDpcList+0x5f6
fffff8018f25ab60 0000000000000000 : fffff8018f25b000 fffff8018f254000 0000000000000000 0000000000000000 : nt!KiIdleLoop+0x5a
STACK_COMMAND: kb
THREAD_SHA1_HASH_MOD_FUNC: 81a7ba75a791115b4f55c8910c64a260d525502e
THREAD_SHA1_HASH_MOD_FUNC_OFFSET: 936d5c51c0ad2157bf4c85af575dd55cea2c0947
THREAD_SHA1_HASH_MOD: f08ac56120cad14894587db086f77ce277bfae84
FOLLOWUP_NAME: MachineOwner
IMAGE_VERSION: 10.0.10586.122
FAILURE_BUCKET_ID: 0x9F_3_POWER_DOWN_i8042prt_IMAGE_ACPI.sys
BUCKET_ID: 0x9F_3_POWER_DOWN_i8042prt_IMAGE_ACPI.sys
PRIMARY_PROBLEM_CLASS: 0x9F_3_POWER_DOWN_i8042prt_IMAGE_ACPI.sys
TARGET_TIME: 2016-03-30T17:15:33.000Z
OSBUILD: 10586
OSSERVICEPACK: 0
SERVICEPACK_NUMBER: 0
OS_REVISION: 0
SUITE_MASK: 272
PRODUCT_TYPE: 1
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
OSEDITION: Windows 10 WinNt TerminalServer SingleUserTS
OS_LOCALE:
USER_LCID: 0
OSBUILD_TIMESTAMP: 2016-02-24 05:48:00
BUILDDATESTAMP_STR: 160223-1728
BUILDLAB_STR: th2_release_sec
BUILDOSVER_STR: 10.0.10586.162.amd64fre.th2_release_sec.160223-1728
ANALYSIS_SESSION_ELAPSED_TIME: 3d7
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:0x9f_3_power_down_i8042prt_image_acpi.sys
FAILURE_ID_HASH: {22a3ff34-49ca-8d37-715b-ae023b6cc9fb}
Followup: MachineOwner
0: kd> !irp ffffe00092718bd0
Irp is active with 8 stacks 6 is current (= 0xffffe00092718e08)
No Mdl: No System Buffer: Thread 00000000: Irp stack trace. Pending has been returned
cmd flg cl Device File Completion-Context
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[IRP_MJ_POWER(16), IRP_MN_WAIT_WAKE(0)]
0 0 ffffe000935ea880 00000000 fffff800d6a81ec0-00000000
\Driver\ACPI i8042prt!I8xPowerUpToD0Complete
Args: 00000000 00000000 00000000 00000002
[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
0 e1 ffffe00093f936f0 00000000 fffff800d6ab1060-00000000 Success Error Cancel pending
\Driver\i8042prt kbdclass!KeyboardClassPowerComplete
Args: 00051100 00000001 00000001 00000002
[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
0 e1 ffffe00093dc95f0 00000000 fffff8018d7840b8-ffffe00096133010 Success Error Cancel pending
\Driver\kbdclass nt!PopRequestCompletion
Args: 00051100 00000001 00000001 00000002
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-ffffe00096133010
Args: 00000000 00000000 00000000 00000000
I'm also adding a BlueScreen screen shot, incase that helps.
Now adding output from some extra commands after Martins comments...
0: kd> !devstack ffffe000935ea880
!DevObj !DrvObj !DevExt ObjectName
ffffe00093dc95f0 \Driver\kbdclass ffffe00093dc9740 InfoMask field not found for _OBJECT_HEADER at ffffe00093dc95c0
ffffe00093f936f0 \Driver\i8042prt ffffe00093f93840 InfoMask field not found for _OBJECT_HEADER at ffffe00093f936c0
> ffffe000935ea880 \Driver\ACPI ffffe000923fa8d0 Cannot read info offset from nt!ObpInfoMaskToOffset
!DevNode ffffe000935d6af0 :
DeviceInst is "ACPI\PNP0303\0"
ServiceName is "i8042prt"
!process 0 7
**** NT ACTIVE PROCESS DUMP ****
GetPointerFromAddress: unable to read from fffff8018d9f3200
Error in reading nt!_EPROCESS at 0000000000000000
0: kd> !poaction
PopAction: fffff8018d94efe0
State..........: 0 - Idle
Updates........: 0
Action.........: None
Lightest State.: Unspecified
Flags..........: 10000003 QueryApps|UIAllowed
Irp minor......: ??
System State...: Unspecified
Hiber Context..: 0000000000000000
Allocated power irps (PopIrpList - fffff8018d94f4f0)
IRP: ffffe00092718bd0 (set/D0,), PDO: ffffe000935ea880, CURRENT: ffffe00093f936f0
IRP: ffffe000971aa990
Irp worker threads (PopIrpThreadList - fffff8018d94e100)
THREAD: ffffe00091515040 (static)
THREAD: ffffe00091501800 (static)
Error resolving nt!_POP_CURRENT_BROADCAST...
Summary: Error was caused by my 10 year old Razor mouse with Windows 10.
The driver when entering power save state was freaking out and causing the blue screen.
I purchased a new mouse, removed the driver & 2 months in no more BSOD.

I usually use BlueScreenView by Nirsoft. It will get you a list of last BSOD and will show a nice view of the components. "Normally" the first mentioned component could be the reason.
Not sure, if you are looking for a solution on a specific problem or the minidump usage in general.
Some driver got problems with power state change. Make sure, you have the current Drivers installed.

Need help to understand kernel debugging error

Need help to understand kernel debugging error.
When I put my driver for Whck test for windows 8(32/64 bit), it fails CHAOS in RUN TEST.
So I did kernel debugging and got following debug message.But I don't understand where is the error in my ioctl.c file.Same driver has cleared the test for windows 7 32 bit.
*** Fatal System Error: 0x0000000a
(0x00000031,0x00000002,0x00000000,0x81CB1194)
Break instruction exception - code 80000003 (first chance)
A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.
A fatal system error has occurred.
nt!RtlpBreakWithStatusInstruction:
818d6ca4 cc int 3
2: kd> !analyze -v
Connected to Windows 8 9200 x86 compatible target at (Tue May 27 11:56:02.788 2014 (UTC - 7:00)), ptr64 FALSE
Loading Kernel Symbols
...............................................................
.............................................
Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.
...................
........................
Loading User Symbols
Loading unloaded module list
.........Unable to enumerate user-mode unloaded modules, Win32 error 0n30
*******************************************************************************
* *
* 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: 00000031, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, 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: 81cb1194, address which referenced memory
Debugging Details:
------------------
READ_ADDRESS: 00000031
CURRENT_IRQL: 2
FAULTING_IP:
nt!VerifierKeSynchronizeExecution+26
81cb1194 0fb64631 movzx eax,byte ptr [esi+31h]
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
BUGCHECK_STR: AV
PROCESS_NAME: System
TRAP_FRAME: b74a594c -- (.trap 0xffffffffb74a594c)
ErrCode = 00000000
eax=9132b7d8 ebx=b23f4a38 ecx=b74a59d8 edx=9184c628 esi=00000000 edi=9184c570
eip=81cb1194 esp=b74a59c0 ebp=b74a59c4 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
nt!VerifierKeSynchronizeExecution+0x26:
81cb1194 0fb64631 movzx eax,byte ptr [esi+31h] ds:0023:00000031=??
Resetting default scope
LAST_CONTROL_TRANSFER: from 818fefc7 to 818d6ca4
STACK_TEXT:
b74a54e4 818fefc7 00000003 d565b8ac 00000031 nt!RtlpBreakWithStatusInstruction
b74a5534 818fe861 00000003 8286a340 b74a5934 nt!KiBugCheckDebugBreak+0x1c
b74a5908 818d56a6 0000000a 00000031 00000002 nt!KeBugCheck2+0x655
b74a592c 8194ed9b 0000000a 00000031 00000002 nt!KiBugCheck2+0xc6
b74a592c 81cb1194 0000000a 00000031 00000002 nt!KiTrap0E+0x1b3
b74a59c4 9132b7d8 00000000 9132ef20 b74a59d8 nt!VerifierKeSynchronizeExecution+0x26
b74a5a30 81ca1f9b 9184c570 adcf4f00 adcf4f00 OxSer!OxserInternalIoControl+0x328 [c:\users\admin\desktop\trunk\uart_v7.0\source\uart\driver\wdm\ioctl.c # 2570]
b74a5a50 81830066 81cb97fd adcf4fd4 adcf4ff8 nt!IovCallDriver+0x2e3
b74a5a64 81cb97fd b74a5a8c 81cb98f4 9184c570 nt!IofCallDriver+0x73
b74a5a6c 81cb98f4 9184c570 adcf4f00 ace85a30 nt!ViFilterIoCallDriver+0x10
b74a5a8c 81ca1f9b ace85ae8 adcf4f00 81ca27c1 nt!ViFilterDispatchGeneric+0x5e
b74a5aac 81830066 8f7eab44 ace85a30 8ad0c710 nt!IovCallDriver+0x2e3
b74a5ac0 8f7eab44 b74a5b0c b74a5b0c b74a5c14 nt!IofCallDriver+0x73
b74a5ad0 8f7ea625 001b0010 00000001 ace85a30 serenum!Serenum_IoSyncIoctlEx+0x48
b74a5c14 8f7e537d b7196ed8 b74a5c33 b7a84340 serenum!Serenum_ReenumerateDevices+0x259
b74a5c34 81866b1b b7196ed8 d565b1e8 00000000 serenum!SerenumEnumThread+0x57
b74a5c70 81950579 8f7e5326 8ad0c710 00000000 nt!PspSystemThreadStartup+0x4a
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19
STACK_COMMAND: kb
FOLLOWUP_IP:
OxSer!OxserInternalIoControl+328 [c:\users\admin\desktop\trunk\uart_v7.0\source\uart\driver\wdm\ioctl.c # 2570]
9132b7d8 8b4dcc mov ecx,dword ptr [ebp-34h]
FAULTING_SOURCE_LINE: c:\users\admin\desktop\trunk\uart_v7.0\source\uart\driver\wdm\ioctl.c
FAULTING_SOURCE_FILE: c:\users\admin\desktop\trunk\uart_v7.0\source\uart\driver\wdm\ioctl.c
FAULTING_SOURCE_LINE_NUMBER: 2570
FAULTING_SOURCE_CODE:
No source found for 'c:\users\admin\desktop\trunk\uart_v7.0\source\uart\driver\wdm\ioctl.c'
SYMBOL_STACK_INDEX: 6
SYMBOL_NAME: OxSer!OxserInternalIoControl+328
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: OxSer
IMAGE_NAME: OxSer.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 53802c0f
BUCKET_ID_FUNC_OFFSET: 328
FAILURE_BUCKET_ID: AV_VRF_OxSer!OxserInternalIoControl
BUCKET_ID: AV_VRF_OxSer!OxserInternalIoControl
Followup: MachineOwner
---------

The routine that crashed was actually in the OS verifier. This is a set of function that perform additional validation on driver calls when driver development is performed in order to find driver bugs.
You are probably not crashing on Win7 because either the verifier is not turned on or the verifier was not detecting this problem in Win7. While your code is not crashing, it is probably still doing something that will cause OS instability at some point.
You should view this as Win8 helping you identify a real bug much more easily, rather than under weird circumstances after you shipped your driver.

What caused my NDIS miniport driver crashed on XP OS

I wrote a simple packet filter driver based on the example 'passthru' of the Windows DDK, when I turned on the filter function, the OS is crashed and I got the following message from the WinDbg:
Microsoft (R) Windows Debugger Version 6.12.0002.633 X86 Copyright (c)
Microsoft Corporation. All rights reserved.
Loading Dump File [D:\iCheckTool\dump\MEMORY.DMP] Kernel Summary Dump
File: Only kernel address space is available
WARNING: Whitespace at start of path element Symbol search path is:
D:\iCheckTool\dump;
SRV*E:\DebuggingSymbols*http://msdl.microsoft.com/download/symbols;SRV*C:\MyLocalSymbols*http://192.168.20.25/zfprisymbols/
Executable search path is: Windows XP Kernel Version 2600 (Service
Pack 3) MP (2 procs) Free x86 compatible Product: WinNt, suite:
TerminalServer SingleUserTS Built by: 2600.xpsp_sp3_qfe.120504-1617
Machine Name: Kernel base = 0x804d8000 PsLoadedModuleList = 0x8055e720
Debug session time: Tue Sep 11 09:41:02.828 2012 (UTC + 8:00) System
Uptime: 0 days 0:02:30.578 Loading Kernel Symbols
...............................................................
............................................................. Loading
User Symbols PEB is paged out (Peb.Ldr = 7ffd800c). Type ".hh
dbgerr001" for details Loading unloaded module list ........
*
Bugcheck Analysis *
*
Use !analyze -v to get detailed debugging information.
BugCheck C5, {4, 2, 1, 8054c10f}
Probably caused by : Pool_Corruption ( nt!ExDeferredFreePool+109 )
Followup: Pool_corruption
1: kd> !analyze -v
*
Bugcheck Analysis *
*
DRIVER_CORRUPTED_EXPOOL (c5) An attempt was made to access a pageable
(or completely invalid) address at an interrupt request level (IRQL)
that is too high. This is caused by drivers that have corrupted the
system pool. Run the driver verifier against any new (or suspect)
drivers, and if that doesn't turn up the culprit, then use gflags to
enable special pool. Arguments: Arg1: 00000004, memory referenced
Arg2: 00000002, IRQL Arg3: 00000001, value 0 = read operation, 1 =
write operation Arg4: 8054c10f, address which referenced memory
Debugging Details:
BUGCHECK_STR: 0xC5_2
CURRENT_IRQL: 2
FAULTING_IP: nt!ExDeferredFreePool+109 8054c10f 895f04 mov
dword ptr [edi+4],ebx
DEFAULT_BUCKET_ID: DRIVER_FAULT
PROCESS_NAME: explorer.exe
TRAP_FRAME: b42555dc -- (.trap 0xffffffffb42555dc) ErrCode = 00000002
eax=89cc1c60 ebx=89e4ded8 ecx=000001ff edx=89cc2a78 esi=80565d20
edi=00000000 eip=8054c10f esp=b4255650 ebp=b4255690 iopl=0 nv
up ei ng nz ac pe cy cs=0008 ss=0010 ds=0023 es=0023 fs=0030
gs=0000 efl=00010297 nt!ExDeferredFreePool+0x109: 8054c10f
895f04 mov dword ptr [edi+4],ebx
ds:0023:00000004=???????? Resetting default scope
LOCK_ADDRESS: 8055c4e0 -- (!locks 8055c4e0)
Resource # nt!PiEngineLock (0x8055c4e0) Available
Contention Count = 1 1 total locks
PNP_TRIAGE: Lock address : 0x8055c4e0 Thread Count : 0 Thread
address: 0x00000000 Thread wait : 0x0
LAST_CONTROL_TRANSFER: from 8054c10f to 80545768
STACK_TEXT: b42555dc 8054c10f badb0d00 89cc2a78 b8338538
nt!KiTrap0E+0x238 b4255690 8054c75f 00000001 8055c100 00020019
nt!ExDeferredFreePool+0x109 b42556d0 8058635e 899522e8 00000000
b42557d8 nt!ExFreePoolWithTag+0x47f b42556fc 805878b8 c0000023
00000007 8058758c nt!PiGetDeviceRegistryProperty+0x108 b425578c
bf879f40 8a523030 00000001 00000100 nt!IoGetDeviceProperty+0x25e
b42558f8 bf879735 00000000 e1b5e008 00000000
win32k!DrvEnumDisplayDevices+0x33b b425591c 8054268c 00000000 00000000
0007ecc4 win32k!NtUserEnumDisplayDevices+0x7c b425591c 7c92e514
00000000 00000000 0007ecc4 nt!KiFastCallEntry+0xfc WARNING: Frame IP
not in any known module. Following frames may be wrong. 0007f010
00000000 00000000 00000000 00000000 0x7c92e514
STACK_COMMAND: kb
FOLLOWUP_IP: nt!ExDeferredFreePool+109 8054c10f 895f04 mov
dword ptr [edi+4],ebx
SYMBOL_STACK_INDEX: 1
SYMBOL_NAME: nt!ExDeferredFreePool+109
FOLLOWUP_NAME: Pool_corruption
IMAGE_NAME: Pool_Corruption
DEBUG_FLR_IMAGE_TIMESTAMP: 0
MODULE_NAME: Pool_Corruption
FAILURE_BUCKET_ID: 0xC5_2_nt!ExDeferredFreePool+109
BUCKET_ID: 0xC5_2_nt!ExDeferredFreePool+109
Followup: Pool_corruption
Can someone tell me what caused this problem and how to fix it?
Thanks.

Apparently, you tried to write into invalid memory region (address = 0x4). Beyond this the debugger analysis you posted isn't too helpful. You can try finding your driver stack (which is not present in your posted debug output) in the debugger to get the failing code, but it's not guaranteed. Other methods to attack this include adding debug prints to your code and capturing it with DbgView (you can later extract them from the memory dump). And you can also connect kernel debugger and catch the error when it happens.

Resources