APC_INDEX_MISMATCH just before Windows completes shutdown

NTDEV
1

Hi I have an MPL PIp32 pc with 1 x Commtech FSCC HDLC PC104plus pc express and 3 x hilsher cifx profibus pc104plus pci express cards the apc_index _mismatch is extremely intermittent

If I run the x86 version with driver verifier
The HDLC card also causes an irql_less_equal
At startup do you have a feeling if this is worth
Investigating the FSCC driver is on GITHUB
And vendors are helpful but out of depth

I have also noticed other software problems
That occur if 3 or 4 cards are fitted but the
Problems are very hard to pin down these include
Profibus failing to start bus if two other cards
Are allready scanning and also occasional failure
Of PC to boot into windows

I believe mpl are willing to check the bus signals
But am not sure if they would need a problem
To hang the results onto or not.

As far as i understand the FSCC HDLC card uses
Lots of interupt but the CifX cards are purely
Scanning memory I can check this tomorrow

My understandIng is that the apc_index_mismatch
error might be caused by a memory corruption
earlier on to this end I an trying to run the
System in a checked build connected to windbg
But this is inconclusive so far

Many many thanks in advance Nick

2

Are you able to post the thread stack which is causing the APC
bugcheck?

Pete

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com http:</http:>
866.263.9295

------ Original Message ------
From: xxxxx@googlemail.com
To: “Windows System Software Devs Interest List”
Sent: 7/7/2016 2:49:55 PM
Subject: [ntdev] APC_INDEX_MISMATCH just before Windows completes
shutdown

>Hi I have an MPL PIp32 pc with 1 x Commtech FSCC HDLC PC104plus pc
>express and 3 x hilsher cifx profibus pc104plus pci express cards the
>apc_index _mismatch is extremely intermittent
>
>If I run the x86 version with driver verifier
>The HDLC card also causes an irql_less_equal
>At startup do you have a feeling if this is worth
>Investigating the FSCC driver is on GITHUB
>And vendors are helpful but out of depth
>
>I have also noticed other software problems
>That occur if 3 or 4 cards are fitted but the
>Problems are very hard to pin down these include
>Profibus failing to start bus if two other cards
>Are allready scanning and also occasional failure
>Of PC to boot into windows
>
>I believe mpl are willing to check the bus signals
>But am not sure if they would need a problem
>To hang the results onto or not.
>
>As far as i understand the FSCC HDLC card uses
>Lots of interupt but the CifX cards are purely
>Scanning memory I can check this tomorrow
>
>My understandIng is that the apc_index_mismatch
>error might be caused by a memory corruption
>earlier on to this end I an trying to run the
>System in a checked build connected to windbg
>But this is inconclusive so far
>
>Many many thanks in advance Nick
>
>
>
>—
>NTDEV is sponsored by OSR
>
>Visit the list online at:
>http:
>
>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>software drivers!
>Details at http:
>
>To unsubscribe, visit the List Server section of OSR Online at
>http:</http:></http:></http:>

3

Hi Pete, This is stack as requested, sorry, is all windbg can find, Nick.

Microsoft (R) Windows Debugger Version 10.0.10586.567 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\Users\Nick\AppData\Local\Microsoft\Windows\INetCache\IE\32LCG7HC\062716-3603-01[1].dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: srv*
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.19160.x86fre.win7sp1_gdr.160211-0600
Machine Name:
Kernel base = 0x82a12000 PsLoadedModuleList = 0x82b5de30
Debug session time: Mon Jun 27 16:41:31.323 2016 (UTC + 1:00)
System Uptime: 0 days 0:14:38.572
Loading Kernel Symbols
…
…
…
Loading User Symbols
Loading unloaded module list
…
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1, {82c8a993, 0, ffff, 0}

Probably caused by : ntkrpamp.exe ( nt!NtDeviceIoControlFile+0 )

Followup: MachineOwner

1: 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: 82c8a993, Address of system call function or worker routine
Arg2: 00000000, Thread->ApcStateIndex
Arg3: 0000ffff, (Thread->SpecialApcDisable << 16) | Thread->KernelApcDisable
Arg4: 00000000, Call type (0 - system call, 1 - worker routine)

Debugging Details:

DUMP_CLASS: 1

DUMP_QUALIFIER: 400

BUILD_VERSION_STRING: 7601.19160.x86fre.win7sp1_gdr.160211-0600

SYSTEM_MANUFACTURER: MPL AG

SYSTEM_PRODUCT_NAME: PIP30 Family

SYSTEM_SKU: System SKUNumber

SYSTEM_VERSION: System Version

BIOS_VENDOR: Phoenix Technologies Ltd.

BIOS_VERSION: PIP3x_ECC_2.2.0.400_MEV-10129-001_V0.61 X64

BIOS_DATE: 12/11/2014

BASEBOARD_MANUFACTURER: MPL AG

BASEBOARD_PRODUCT: PIP30 Family

BASEBOARD_VERSION: Board Version

DUMP_TYPE: 2

BUGCHECK_P1: ffffffff82c8a993

BUGCHECK_P2: 0

BUGCHECK_P3: ffff

BUGCHECK_P4: 0

FAULTING_IP:
nt!NtDeviceIoControlFile+0
82c8a993 8bff mov edi,edi

CPU_COUNT: 2

CPU_MHZ: 574

CPU_VENDOR: GenuineIntel

CPU_FAMILY: 6

CPU_MODEL: 3a

CPU_STEPPING: 9

CPU_MICROCODE: 6,3a,9,0 (F,M,S,R) SIG: 19’00000000 (cache) 19’00000000 (init)

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

BUGCHECK_STR: 0x1

PROCESS_NAME: AccosRTService

CURRENT_IRQL: 0

ANALYSIS_SESSION_HOST: U0932B

ANALYSIS_SESSION_TIME: 07-08-2016 11:43:11.0275

ANALYSIS_VERSION: 10.0.10586.567 x86fre

LAST_CONTROL_TRANSFER: from 770870d4 to 82a4fd93

STACK_TEXT:
98ebbd34 770870d4 badb0d00 1a18f088 00000000 nt!KiServiceExit2+0x178
WARNING: Frame IP not in any known module. Following frames may be wrong.
1a18f0e0 00000000 00000000 00000000 00000000 0x770870d4

STACK_COMMAND: kb

THREAD_SHA1_HASH_MOD_FUNC: 20f8e09602a91ea48c9b7ce040991b7b3978b6e5

THREAD_SHA1_HASH_MOD_FUNC_OFFSET: aa0c6ed3c4e903c188d30f6e53e2b7ce2c98d1e4

THREAD_SHA1_HASH_MOD: 76cd06466d098060a9eb26e5fd2a25cb1f3fe0a3

FOLLOWUP_IP:
nt!NtDeviceIoControlFile+0
82c8a993 8bff mov edi,edi

FAULT_INSTR_CODE: 8b55ff8b

SYMBOL_NAME: nt!NtDeviceIoControlFile+0

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrpamp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 56bcc726

IMAGE_VERSION: 6.1.7601.19160

FAILURE_BUCKET_ID: 0x1_SysCallNum_6b_nt!NtDeviceIoControlFile+0

BUCKET_ID: 0x1_SysCallNum_6b_nt!NtDeviceIoControlFile+0

PRIMARY_PROBLEM_CLASS: 0x1_SysCallNum_6b_nt!NtDeviceIoControlFile+0

TARGET_TIME: 2016-06-27T15:41:31.000Z

OSBUILD: 7601

OSSERVICEPACK: 1000

SERVICEPACK_NUMBER: 0

OS_REVISION: 0

SUITE_MASK: 272

PRODUCT_TYPE: 1

OSPLATFORM_TYPE: x86

OSNAME: Windows 7

OSEDITION: Windows 7 WinNt (Service Pack 1) TerminalServer SingleUserTS

OS_LOCALE:

USER_LCID: 0

OSBUILD_TIMESTAMP: 2016-02-11 17:38:46

BUILDDATESTAMP_STR: 160211-0600

BUILDLAB_STR: win7sp1_gdr

BUILDOSVER_STR: 6.1.7601.19160.x86fre.win7sp1_gdr.160211-0600

ANALYSIS_SESSION_ELAPSED_TIME: 9c9

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0x1_syscallnum_6b_nt!ntdeviceiocontrolfile+0

FAILURE_ID_HASH: {0f3743e9-02b4-f746-408b-3f63b3b68373}

Followup: MachineOwner

4

if you have a Verifier crash it’s always easiest to start there. It catches
all sorts of corruptions that can manifest themselves in strange ways.

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntdev…

Hi I have an MPL PIp32 pc with 1 x Commtech FSCC HDLC PC104plus pc express
and 3 x hilsher cifx profibus pc104plus pci express cards the apc_index
_mismatch is extremely intermittent

If I run the x86 version with driver verifier
The HDLC card also causes an irql_less_equal
At startup do you have a feeling if this is worth
Investigating the FSCC driver is on GITHUB
And vendors are helpful but out of depth

I have also noticed other software problems
That occur if 3 or 4 cards are fitted but the
Problems are very hard to pin down these include
Profibus failing to start bus if two other cards
Are allready scanning and also occasional failure
Of PC to boot into windows

I believe mpl are willing to check the bus signals
But am not sure if they would need a problem
To hang the results onto or not.

As far as i understand the FSCC HDLC card uses
Lots of interupt but the CifX cards are purely
Scanning memory I can check this tomorrow

My understandIng is that the apc_index_mismatch
error might be caused by a memory corruption
earlier on to this end I an trying to run the
System in a checked build connected to windbg
But this is inconclusive so far

Many many thanks in advance Nick