Frank Helk
asked on
BOSD APC_INDEX_MISMATCH - who's the culprit ?
Hi friends,
from time to time I get a BOSD with the error description APC_INDEX_MISMATCH. I've installed WinDbgX64 to analyze the crash dump, but it seems that I'm not bright enough to nail down the culprit.
The description of the problem implies a faulty driver (from the line
Any idea how & where to search the offending driver ?
The analysis of the crash dump reads
from time to time I get a BOSD with the error description APC_INDEX_MISMATCH. I've installed WinDbgX64 to analyze the crash dump, but it seems that I'm not bright enough to nail down the culprit.
The description of the problem implies a faulty driver (from the line
Arg3: 000000000000ffff, (Thread->SpecialApcDisable << 16) | Thread->KernelApcDisable
I would suspect that the "enabled too many times" hint is true).Any idea how & where to search the offending driver ?
The analysis of the crash dump reads
Microsoft (R) Windows Debugger Version 10.0.14321.1024 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Temp\010217-33593-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 14393 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 14393.576.amd64fre.rs1_release_inmarket.161208-2252
Machine Name:
Kernel base = 0xfffff800`79a79000 PsLoadedModuleList = 0xfffff800`79d7e060
Debug session time: Mon Jan 2 11:27:01.518 2017 (UTC + 1:00)
System Uptime: 0 days 0:06:46.843
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 1, {7ffa52de6734, 0, ffff, ffffb28097ef7b80}
Probably caused by : ntkrnlmp.exe ( nt!KiSystemServiceExitPico+194 )
Followup: MachineOwner
---------
3: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
APC_INDEX_MISMATCH (1)
This is a kernel internal error. The most common reason to see this
bugcheck is when a filesystem or a driver has a mismatched number of
calls to disable and re-enable APCs. The key data item is the
Thread->CombinedApcDisable field. This consists of two separate 16-bit
fields, the SpecialApcDisable and the KernelApcDisable. A negative value
of either indicates that a driver has disabled special or normal APCs
(respectively) without re-enabling them; a positive value indicates that
a driver has enabled special or normal APCs (respectively) too many times.
Arguments:
Arg1: 00007ffa52de6734, Address of system call function or worker routine
Arg2: 0000000000000000, Thread->ApcStateIndex
Arg3: 000000000000ffff, (Thread->SpecialApcDisable << 16) | Thread->KernelApcDisable
Arg4: ffffb28097ef7b80, Call type (0 - system call, 1 - worker routine)
Debugging Details:
------------------
DUMP_CLASS: 1
DUMP_QUALIFIER: 400
BUILD_VERSION_STRING: 10.0.14393.576 (rs1_release_inmarket.161208-2252)
SYSTEM_MANUFACTURER: Gigabyte Technology Co., Ltd.
SYSTEM_PRODUCT_NAME: Z68X-UD7-B3
BIOS_VENDOR: Award Software International, Inc.
BIOS_VERSION: F6
BIOS_DATE: 05/02/2011
BASEBOARD_MANUFACTURER: Gigabyte Technology Co., Ltd.
BASEBOARD_PRODUCT: Z68X-UD7-B3
BASEBOARD_VERSION: x.x
DUMP_TYPE: 2
DUMP_FILE_ATTRIBUTES: 0xc
Insufficient Dumpfile Size
Kernel Generated Triage Dump
BUGCHECK_P1: 7ffa52de6734
BUGCHECK_P2: 0
BUGCHECK_P3: ffff
BUGCHECK_P4: ffffb28097ef7b80
FAULTING_IP:
+0
00007ffa`52de6734 c3 ret
CPU_COUNT: 8
CPU_MHZ: d40
CPU_VENDOR: GenuineIntel
CPU_FAMILY: 6
CPU_MODEL: 2a
CPU_STEPPING: 7
CPU_MICROCODE: 6,2a,7,0 (F,M,S,R) SIG: 29'00000000 (cache) 29'00000000 (init)
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
BUGCHECK_STR: 0x1
PROCESS_NAME: rundll32.exe
CURRENT_IRQL: 0
ANALYSIS_SESSION_HOST: RSC
ANALYSIS_SESSION_TIME: 01-02-2017 16:45:04.0755
ANALYSIS_VERSION: 10.0.14321.1024 amd64fre
LAST_CONTROL_TRANSFER: from fffff80079bce829 to fffff80079bc36f0
STACK_TEXT:
ffffb280`97ef7948 fffff800`79bce829 : 00000000`00000001 00007ffa`52de6734 00000000`00000000 00000000`0000ffff : nt!KeBugCheckEx
ffffb280`97ef7950 fffff800`79bce72b : ffff9f4f`80001d68 ffff9f4f`a7c00008 ffff9f4f`a7d3e000 ffff6360`87a958f5 : nt!KiBugCheckDispatch+0x69
ffffb280`97ef7a90 00007ffa`52de6734 : 00000000`51335a59 00000000`04e5ee24 00000000`00000000 00000000`04e5eea8 : nt!KiSystemServiceExitPico+0x194
00000000`04aee4b8 00000000`51335a59 : 00000000`04e5ee24 00000000`00000000 00000000`04e5eea8 00000000`0047f000 : 0x00007ffa`52de6734
00000000`04aee4c0 00000000`04e5ee24 : 00000000`00000000 00000000`04e5eea8 00000000`0047f000 00000000`00000005 : 0x51335a59
00000000`04aee4c8 00000000`00000000 : 00000000`04e5eea8 00000000`0047f000 00000000`00000005 00000000`00000060 : 0x4e5ee24
STACK_COMMAND: kb
THREAD_SHA1_HASH_MOD_FUNC: 1b1fd012b2a510c586295e696f84a9476c8f91e5
THREAD_SHA1_HASH_MOD_FUNC_OFFSET: 2f23c0fd5d286fdc1748b3b41b103ae80a3b4264
THREAD_SHA1_HASH_MOD: 2a7ca9d3ab5386d53fea7498e1d81b9c4a4c036b
FOLLOWUP_IP:
nt!KiSystemServiceExitPico+194
fffff800`79bce72b 4883ec50 sub rsp,50h
FAULT_INSTR_CODE: 50ec8348
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: nt!KiSystemServiceExitPico+194
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 584a77f6
IMAGE_VERSION: 10.0.14393.576
BUCKET_ID_FUNC_OFFSET: 194
FAILURE_BUCKET_ID: 0x1_SysCallNum_33_nt!KiSystemServiceExitPico
BUCKET_ID: 0x1_SysCallNum_33_nt!KiSystemServiceExitPico
PRIMARY_PROBLEM_CLASS: 0x1_SysCallNum_33_nt!KiSystemServiceExitPico
TARGET_TIME: 2017-01-02T10:27:01.000Z
OSBUILD: 14393
OSSERVICEPACK: 576
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-12-09 10:23:02
BUILDDATESTAMP_STR: 161208-2252
BUILDLAB_STR: rs1_release_inmarket
BUILDOSVER_STR: 10.0.14393.576
ANALYSIS_SESSION_ELAPSED_TIME: 4f9
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:0x1_syscallnum_33_nt!kisystemserviceexitpico
FAILURE_ID_HASH: {2bd3eae7-7dba-e557-de8c-cb94f004c93d}
Followup: MachineOwner
---------
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
The link posted includes a link to hardware. You may have some hardware that the kernel seems to try and reset that throws it into a .....
Unfortunately, it does not seem to point to a culprit app/device/resource
Try using nirsoft's http://www.nirsoft.net/utils/blue_screen_view.html
and see if it points to a resource, graphics, controller, etc
Your issue, is that for one of your components, there was no windows 10 driver, so you used an older windows 8 (
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT)
This is where your issue is, check whether there is an updated windows 10 driver for this component.
Check Gigabyte site for updated firmware .....
Unfortunately, it does not seem to point to a culprit app/device/resource
Try using nirsoft's http://www.nirsoft.net/utils/blue_screen_view.html
and see if it points to a resource, graphics, controller, etc
Your issue, is that for one of your components, there was no windows 10 driver, so you used an older windows 8 (
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT)
This is where your issue is, check whether there is an updated windows 10 driver for this component.
Check Gigabyte site for updated firmware .....
ASKER
Thanks for that link - it's helpful, and it pointed me to the driver verifier, a tool I didn't knew of. Besides of that it geave me the hint to check for stale device drivers and do updates of 'em.
I've just updated all stale device drivers and now I presume that I'll have to sit and wait if the BSOD occurs agin. If not, I'll try the driver verifier.
I've just updated all stale device drivers and now I presume that I'll have to sit and wait if the BSOD occurs agin. If not, I'll try the driver verifier.
ASKER
All the hardware I have should meet the specs ... at least the Win10 update from Win7 didn't nag ... and I've changed almost nothing ... besides of replacing the memory to kill the cause of the other BOSD's (was a defective memory brick and that problem is fixed now - I've exchanged the the complete set, thereby upgrading from 16GB to 32GB). But the BOSD's in question came before, too.
Nothing special ... it occurs usually when I'm not near the machine, and I feel it is more frequent when booting it up.
No. I'm mostly not in front of the machine when it occurs.
Neither ... it occurs sporadic within the last months. Since it was mixed with the band mem brick promblem, I can't tell for sure, but it's not regulary. Occurs every now and then, but could fire twice a day if in bad mood ...
It's too rare to wait for it ...