APC_INDEX_MISMATCH an 3 verschiedenen Hardwarekonfigs

S

SB1888

Gast
Hallo Leute,
habe da mal ein phänomenales Problem wo ich eigentlich nur ein paar Gemeinsamkeiten erkenne:
- Windows Vista 64 Bit
- ATI Grafikkarten (verschiedener Generationen)
- AMD Prozessor

Rest ist unterschiedlich und auch die Prozessoren und Grafikkarten sind wie gesagt nicht gleich.

Problem bei Rechner 1, hin und wieder tritt der APC_INDEX_MISMATCH BOSD auf,
Regelmäßigkeit nicht erkennbar, ich vermute allerdings einen Treiber, da er sehr lang, trotz SSD
ohne Plattenaktivität beim grünen Balken verweilt.
Nach BSOD Reset und alles ist fein.

--> System wurde schon neu installiert


Rechner 2, jeder Kaltstart läuft in den APC_INDEX_MISMATCH nach Reset alles OK.

--> System wurde schon neu installiert


Rechner 3, unregelmäßiger BSOD beim Kaltstart und seltener BSOD während des Windowsbetrieb, damit stellt er eine Ausnahme dar, aber dennoch immer der APC_INDEX_MISMATCH.

Alle Rechner wurden schon mit Memtest und Prime auf Fehler geprüft.
An Rechner 1 wurde das Meiste gemacht, RAM getauscht, Grafikkarte getauscht, Netzteil getauscht.

Bringt alles keine Änderung, im Internet findet man viel zu dem Fehler, aber nichts genaues. :(

Hat da einer Erfahrung, das selbe Problem, oder nen Lösungsansatz?

Grüße
 
Hi,
danke soweit lad mir das Zeug mal runter. :rolleyes:

Was läuft auf allen PCs im Autostart hmm mal sehen
- CatalystControlcenter
- Realtek Audio
- Avast Antivirus

"hängen" tut er allerdings sehr direkt wenn er im Bluescreen endet.
Heißt er fängt mit dem grünen Ladebalken an, kurze Plattenaktivität und Ruhe.
Grafik sowie USB kommen ja immer ganz weit hinten.
Meine Vermutung ging eine Zeit lang in Richtung AMD AHCI Treiber, leider
ändert sich das Fehlerbild auch nicht mit dem Original MS Treiber, somit ist das auch raus. :(

Übrigens, ein PC wird immer mit Passwort angemeldet, soll heißen ich vermute nicht, dass
ein Programm welches bei der Windowsanmeldung geladen wird daran schuld ist.
 
Teste doch Rechner 2 (bei jedem Kaltstart..) mit deaktiviertem deinstalliertem Avast. (Ist ja kein soo großer Aufwand)

Die Ursache für den Bugcheck 0x1 kann auch bei nur teilweise geladenen/abgearbeiteten Treibern/Systemdiensten liegen. Zitat MS:
"This is a kernel internal error. This error occurs on exit from a system call. A possible cause for this bug check is when a file system or driver has a mismatched sequence of system calls to enter or leave guarded or critical regions. For example, each call to KeEnterCriticalRegion must have a matching call to KeLeaveCriticalRegion."
 
Zuletzt bearbeitet:
Gerade mal ausgewertet, schaut nicht nach Avast aus :(

3 Minidumps, alle identisch!

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1, {77676cba, 0, fffe, fffffa6009594ca0}

Probably caused by : ntkrnlmp.exe ( nt!KiSystemServiceExit+209 )

Followup: MachineOwner


4: 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->KernelApcDisable field. A negative value indicates that a driver
has disabled APC calls without re-enabling them. A positive value indicates
that the reverse is true. This check is made on exit from a system call.
Arguments:
Arg1: 0000000077546cba, address of system function (system call)
Arg2: 0000000000000000, Thread->ApcStateIndex << 8 | Previous ApcStateIndex
Arg3: 000000000000fffe, Thread->KernelApcDisable
Arg4: fffffa600b969ca0, Previous KernelApcDisable

Debugging Details:
------------------


FAULTING_IP:
+3137343566646339
00000000`77546cba ?? ???

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x1

PROCESS_NAME: services.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff800024bd22e to fffff800024bd490

STACK_TEXT:
fffffa60`0b969ad8 fffff800`024bd22e : 00000000`00000001 00000000`77546cba 00000000`00000000 00000000`0000fffe : nt!KeBugCheckEx
fffffa60`0b969ae0 fffff800`024bd144 : 00000000`018df8e0 fffffa60`00030019 00000000`018df870 00000000`00000000 : nt!KiBugCheckDispatch+0x6e
fffffa60`0b969c20 00000000`77546cba : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceExit+0x209
00000000`018df838 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x77546cba


STACK_COMMAND: kb

FOLLOWUP_IP:
nt!KiSystemServiceExit+209
fffff800`024bd144 4883ec50 sub rsp,50h

SYMBOL_STACK_INDEX: 2

SYMBOL_NAME: nt!KiSystemServiceExit+209

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4cb7275f

FAILURE_BUCKET_ID: X64_0x1_SysCallNum_f_nt!KiSystemServiceExit+209

BUCKET_ID: X64_0x1_SysCallNum_f_nt!KiSystemServiceExit+209

Followup: MachineOwner
 
PROCESS_NAME: services.exe zeigt an, das für den Absturz ein Nicht-Windows Dienst verantwortlich ist, die werden ja von selbiger geladen.
 
Naja aber ist nicht wirklich aussagekräftig, was hab ich laufen im Autostart an Services... hmm mom
services.png


Das sollten Dienste sein, die lediglich auf meinem Rechner laufen, nicht auf den anderen,
wobei ich mal ein paar von den anderen noch nachsehen muss, da ich damit nix anzufangen weiß :o

Danke soweit
 
So gerade vom System 2 die BSODs mal analysiert :rolleyes:
Bis gestern waren die BlueScreens regelmäßig.
4 Stück sind abgelegt.

20.07.:
* Bugcheck Analysis *

Use !analyze -v to get detailed debugging information.

BugCheck A, {58, 2, 1, fffff800018d8d9b}

mit:
1: kd> !analyze -v
*******************************************************************************
* *
* 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: 0000000000000058, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, 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: fffff800018d8d9b, address which referenced memory

Debugging Details:
------------------


WRITE_ADDRESS: 0000000000000058

CURRENT_IRQL: 2

FAULTING_IP:
nt!MiUnlinkFreeOrZeroedPage+db
fffff800`018d8d9b 488344ca10ff add qword ptr [rdx+rcx*8+10h],0FFFFFFFFFFFFFFFFh

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: msoobe.exe

TRAP_FRAME: fffffa60082ca0d0 -- (.trap 0xfffffa60082ca0d0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff900c20ee000 rbx=0000000000000000 rcx=fffff900c20f4000
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff96000134c30 rsp=fffffa60082ca268 rbp=0000000000000000
r8=0000000000000008 r9=0000000000000092 r10=0000000000000080
r11=0000000000000035 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
win32k!memset+0x80:
fffff960`00134c30 488911 mov qword ptr [rcx],rdx ds:b180:fffff900`c20f4000=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff800018b612e to fffff800018b6390

STACK_TEXT:
fffffa60`082c9a88 fffff800`018b612e : 00000000`0000000a 00000000`00000058 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx
fffffa60`082c9a90 fffff800`018b500b : 00000000`00000001 00000000`00000000 fffff800`01861000 fffffa80`03327f90 : nt!KiBugCheckDispatch+0x6e
fffffa60`082c9bd0 fffff800`018d8d9b : 00000000`00000000 00000000`0000007f fffff900`c1fe9000 fffff960`002197f3 : nt!KiPageFault+0x20b
fffffa60`082c9d60 fffff800`018d8aaa : 00000000`00000003 00000000`00000000 00000000`00000003 fffffa60`082ca3b8 : nt!MiUnlinkFreeOrZeroedPage+0xdb
fffffa60`082c9da0 fffff800`018d8336 : fffffa60`07ff9c00 00000000`00000001 00000000`40000003 fffff6fc`80610798 : nt!MiRemoveAnyPage+0xda
fffffa60`082c9df0 fffff800`018dc32a : 00000000`00000001 fffff900`c20f4000 fffffa60`07ff9c00 fffffa60`082c9f20 : nt!MiResolveDemandZeroFault+0x176
fffffa60`082c9e80 fffff800`018c54c9 : 00000000`00000000 fffff900`c20f4000 00000000`00000000 00000000`00000000 : nt!MiDispatchFault+0x7ea
fffffa60`082c9fe0 fffff800`018b4f19 : 00000000`00000001 00000000`00000021 00000031`00000000 fffff900`c20ee000 : nt!MmAccessFault+0x14c9
fffffa60`082ca0d0 fffff960`00134c30 : fffff960`00119c54 00000000`35316847 00000000`00008488 00000000`00000000 : nt!KiPageFault+0x119
fffffa60`082ca268 fffff960`00119c54 : 00000000`35316847 00000000`00008488 00000000`00000000 00000000`00000000 : win32k!memset+0x80
fffffa60`082ca270 fffff960`0011b206 : 00000000`00000000 fffffa60`082ca3b0 00000000`00000000 00000000`00000000 : win32k!AllocateObject+0xf0
fffffa60`082ca2b0 fffff960`000f7f52 : 00000000`00000000 00000000`00000000 fffff900`c0094000 00000000`00000000 : win32k!SURFMEM::bCreateDIB+0x1ce
fffffa60`082ca350 fffff960`000f8283 : 00000000`00000000 00000000`51080045 00000000`000001d3 00000000`000001d3 : win32k!hsurfCreateCompatibleSurface+0x182
fffffa60`082ca410 fffff800`018b5e33 : fffffa80`063c2060 fffffa60`082ca530 00000000`000001d3 fffff900`c0094000 : win32k!GreCreateCompatibleBitmap+0x163
fffffa60`082ca4b0 000007fe`fdbc226a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`0021ed98 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7fe`fdbc226a


STACK_COMMAND: kb

FOLLOWUP_IP:
win32k!memset+80
fffff960`00134c30 488911 mov qword ptr [rcx],rdx

SYMBOL_STACK_INDEX: 9

SYMBOL_NAME: win32k!memset+80

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: win32k

IMAGE_NAME: win32k.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 47919441

FAILURE_BUCKET_ID: X64_0xA_win32k!memset+80

BUCKET_ID: X64_0xA_win32k!memset+80

Followup: MachineOwner
---------

Kann man aber außer Acht lassen, den kenn ich, trat bei der Windowsinstallation auf, da der Speicher nicht genug Spannung hatte :freak:

Aber anschließend 3 abgelegte Minidumps identisch zum System 1.

Ich warte noch auf die Minis von System 3, bin gespannt....
 
Aha, also nix mit 0x1 bei allen Rechnern.
Für Rechner 2:
Wie du bereits erkannt aber mögl. noch nicht realisiert hast, kann der 0xA durch instabiles RAM ausgelöst werden: "trat bei der Windowsinstallation auf..".
Hier brauchts einen Hardwareauskenner, denke der wird auch noch hier aufschlagen, lade CPU-Z herunter und mach Screenshots der Reiter, bei SPD für jeden RAM Riegel extra und häng diese an deinen Post an.
https://www.computerbase.de/downloads/systemtools/cpu-z/


Hrmpf, war wohl noch etwas zu früh !
 
Zuletzt bearbeitet:
Hey, wenn du richtig gelesen hast ist der 0xA behoben ;)
Nach dem BIOS Update vor Neuinstallation waren die Speichersettings zurückgesetzt, was direkt mal in nem BSOD endete....
Nachdem die Speicherspannungen angepasst waren lief erst mal ne Runde Memtest und zwar problemlos.
So ganz unbeholfen bin ich ja auch nicht :D

Wie gesagt die anderen 3 abgelegten Minidumps sind identisch zu Rechner 1.
 
Zurück
Oben