Details
-
Bug
-
Resolution: Cannot Reproduce
-
Major
-
None
-
None
-
None
Description
While playing with Firefox 45 (from RAPPS) with a clean installation of a MSVC-build of ReactOS r71951, I got this assertion:
(H:\trunk\reactos_clean\ntoskrnl\io\iomgr\irp.c:1240) Dispatch function F8BA1E00 (major 18) changed IRQL (0 -> 0) or APC state (0xffff -> 0xfffe)
|
Assertion h:\trunk\reactos_clean\ntoskrnl\io\iomgr\irp.c(1242): Thread->CombinedApcDisable == CombinedApcDisable
|
nt!IofCallDriver+0x169:
|
80463549 cd2c int 2Ch
|
kd> .reload
|
Connected to Windows Server 2003 3790 x86 compatible target at (Fri Jul 22 02:23:15.786 2016 (UTC + 2:00)), ptr64 FALSE
|
Loading Kernel Symbols
|
........................................................
|
Loading User Symbols
|
................................................................
|
.........
|
|
(Here I remove the "ERROR: Module load completed but symbols could not be loaded" messages concerning Firefox stuff...)
|
|
kd> kp
|
ChildEBP RetAddr
|
f7e3bbe0 80457ca3 nt!IofCallDriver(struct _DEVICE_OBJECT * DeviceObject = 0xb123e018, struct _IRP * Irp = 0xb0d4a738)+0x169 [h:\trunk\reactos_clean\ntoskrnl\io\iomgr\irp.c @ 1242]
|
f7e3bc10 804c003f nt!IopCloseFile(struct _EPROCESS * Process = 0xff73d0e8, void * ObjectBody = 0xb0b2f320, unsigned long GrantedAccess = 0x120196, unsigned long HandleCount = 1, unsigned long SystemHandleCount = 1)+0x173 [h:\trunk\reactos_clean\ntoskrnl\io\iomgr\file.c @ 2003]
|
f7e3bc60 804c01be nt!ObpDecrementHandleCount(void * ObjectBody = 0xb0b2f320, struct _EPROCESS * Process = 0xff73d0e8, unsigned long GrantedAccess = 0x120196, struct _OBJECT_TYPE * ObjectType = 0xb13128e8)+0x1df [h:\trunk\reactos_clean\ntoskrnl\ob\obhandle.c @ 639]
|
f7e3bc8c 804c0f06 nt!ObpCloseHandleTableEntry(struct _HANDLE_TABLE * HandleTable = 0xe1641338, struct _HANDLE_TABLE_ENTRY * HandleEntry = 0xe16e1300, void * Handle = 0x00000980, char AccessMode = 0n1 '', unsigned char IgnoreHandleProtection = 0x00 '')+0x13e [h:\trunk\reactos_clean\ntoskrnl\ob\obhandle.c @ 767]
|
f7e3bcf8 804c2647 nt!ObpCloseHandle(void * Handle = 0x00000980, char AccessMode = 0n1 '')+0x126 [h:\trunk\reactos_clean\ntoskrnl\ob\obhandle.c @ 1775]
|
f7e3bd08 804f503b nt!NtClose(void * Handle = 0x00000980)+0x17 [h:\trunk\reactos_clean\ntoskrnl\ob\obhandle.c @ 3396]
|
f7e3bd1c 804f46df nt!KiSystemCallTrampoline(void * Handler = 0x804c2630, void * Arguments = 0x0c96fd0c, unsigned long StackBytes = 4)+0x1b [h:\trunk\reactos_clean\ntoskrnl\include\internal\i386\ke.h @ 742]
|
f7e3bd5c 80403e23 nt!KiSystemServiceHandler(struct _KTRAP_FRAME * TrapFrame = 0xf7e3bd64, void * Arguments = 0x0c96fd0c)+0x22f [h:\trunk\reactos_clean\ntoskrnl\ke\i386\traphdlr.c @ 1738]
|
f7e3bd5c 7c92c80e nt!KiFastCallEntry+0x8c
|
0c96fd00 7c950e91 ntdll!KiFastSystemCallRet
|
0c96fd04 7c7c7628 ntdll!ZwClose+0xc
|
0c96fd14 007183f7 KERNEL32!CloseHandle(void * hObject = 0x00000980)+0x38 [h:\trunk\reactos_clean\dll\win32\kernel32\client\handle.c @ 137]
|
WARNING: Stack unwind information not available. Following frames may be wrong.
|
0c96fd24 007183c5 nss3!PR_Close+0x3c
|
0c96fd2c 0116eb21 nss3!PR_Close+0xa
|
0c96fd3c 0116ee78 xul+0x45eb21
|
0c96fd44 0116ee47 xul+0x45ee78
|
0c96fd4c 00eb2126 xul+0x45ee47
|
0c96fd5c 00f495c2 xul+0x1a2126
|
00000000 00000000 xul+0x2395c2
|
Full log in attached file.
thfabba, thephysicist, heis spiter, any idea?
EDIT: By continuing execution (not shown in the attached log file), I get:
kd> gh
|
(H:\trunk\reactos_clean\win32ss\user\ntuser\hotkey.c:234) err: Hot key pressed for Debug Activation! ShiftF12 = 0 or F12 = 1
|
|
*** Fatal System Error: 0x00000001
|
(0x0000001B,0x00000000,0x0000FFFF,0x00000000)
|
|
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.
|
|
Connected to Windows Server 2003 3790 x86 compatible target at (Fri Jul 22 02:28:40.466 2016 (UTC + 2:00)), ptr64 FALSE
|
Loading Kernel Symbols
|
........................................................
|
Loading User Symbols
|
................................................................
|
.........
|
|
(Here I again remove the "ERROR: Module load completed but symbols could not be loaded" messages concerning Firefox stuff...)
|
|
*******************************************************************************
|
* *
|
* Bugcheck Analysis *
|
* *
|
*******************************************************************************
|
|
Use !analyze -v to get detailed debugging information.
|
|
BugCheck 1, {1b, 0, ffff, 0}
|
|
Probably caused by : ntoskrnl.exe ( nt!KiExitSystemCallDebugChecks+89 )
|
|
Followup: MachineOwner
|
---------
|
|
nt!RtlpBreakWithStatusInstruction:
|
8050e868 cc int 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->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: 0000001b, address of system function (system call)
|
Arg2: 00000000, Thread->ApcStateIndex << 8 | Previous ApcStateIndex
|
Arg3: 0000ffff, Thread->KernelApcDisable
|
Arg4: 00000000, Previous KernelApcDisable
|
|
Debugging Details:
|
------------------
|
|
|
FAULTING_IP:
|
+6433633865646363
|
0000001b ?? ???
|
|
DEFAULT_BUCKET_ID: DRIVER_FAULT
|
|
BUGCHECK_STR: 0x1
|
|
PROCESS_NAME: firefox.exe
|
|
CURRENT_IRQL: 0
|
|
LAST_CONTROL_TRANSFER: from 804774a8 to 8050e868
|
|
STACK_TEXT:
|
f7e3b914 804774a8 00000003 f7e3bc34 ffdff408 nt!RtlpBreakWithStatusInstruction
|
f7e3b944 80477db3 00000003 55555555 0b378020 nt!KiBugCheckDebugBreak+0x38 [h:\trunk\reactos_clean\ntoskrnl\ke\bug.c @ 538]
|
f7e3bce0 80478410 00000001 0000001b 00000000 nt!KeBugCheckWithTf+0x553 [h:\trunk\reactos_clean\ntoskrnl\ke\bug.c @ 1102]
|
f7e3bd00 804f4dd9 00000001 0000001b 00000000 nt!KeBugCheckEx+0x20 [h:\trunk\reactos_clean\ntoskrnl\ke\bug.c @ 1462]
|
f7e3bd20 804f4705 0000001b f7e3bd64 ffdff6b8 nt!KiExitSystemCallDebugChecks+0x89 [h:\trunk\reactos_clean\ntoskrnl\include\internal\i386\trap_x.h @ 230]
|
f7e3bd5c 80403e23 0c96fd14 7c92c80e badb0d00 nt!KiSystemServiceHandler+0x255 [h:\trunk\reactos_clean\ntoskrnl\ke\i386\traphdlr.c @ 1744]
|
f7e3bd5c 7c92c80e 0c96fd14 7c92c80e badb0d00 nt!KiFastCallEntry+0x8c
|
0c96fd00 7c950e91 7c7c7628 00000980 aaaaaaaa ntdll!KiFastSystemCallRet
|
0c96fd04 7c7c7628 00000980 aaaaaaaa 00684180 ntdll!ZwClose+0xc
|
0c96fd14 007183f7 00000980 00000000 091b9400 KERNEL32!CloseHandle+0x38 [h:\trunk\reactos_clean\dll\win32\kernel32\client\handle.c @ 137]
|
WARNING: Stack unwind information not available. Following frames may be wrong.
|
0c96fd24 007183c5 0b378020 0116eb21 0b378020 nss3!PR_Close+0x3c
|
0c96fd2c 0116eb21 0b378020 091b9408 091b9400 nss3!PR_Close+0xa
|
0c96fd3c 0116ee78 091b9400 0116ee47 091b9400 xul+0x45eb21
|
0c96fd44 0116ee47 091b9400 00eb2126 00000001 xul+0x45ee78
|
0c96fd4c 00eb2126 00000001 00000000 00000000 xul+0x45ee47
|
0c96fd5c 00f495c2 091b9400 00fcbf81 00000000 xul+0x1a2126
|
00000000 00000000 00000000 00000000 00000000 xul+0x2395c2
|
|
|
STACK_COMMAND: kb
|
|
FOLLOWUP_IP:
|
nt!KiExitSystemCallDebugChecks+89 [h:\trunk\reactos_clean\ntoskrnl\include\internal\i386\trap_x.h @ 230]
|
804f4dd9 8be5 mov esp,ebp
|
|
FAULTING_SOURCE_CODE:
|
226: KeGetCurrentThread()->CombinedApcDisable,
|
227: 0);
|
228: }
|
229: }
|
> 230: }
|
231:
|
232: //
|
233: // Generic Exit Routine
|
234: //
|
235: DECLSPEC_NORETURN VOID FASTCALL KiSystemCallReturn(IN PKTRAP_FRAME TrapFrame);
|
|
|
SYMBOL_STACK_INDEX: 4
|
|
SYMBOL_NAME: nt!KiExitSystemCallDebugChecks+89
|
|
FOLLOWUP_NAME: MachineOwner
|
|
MODULE_NAME: nt
|
|
IMAGE_NAME: ntoskrnl.exe
|
|
DEBUG_FLR_IMAGE_TIMESTAMP: 579164a9
|
|
FAILURE_BUCKET_ID: 0x1_nt!KiExitSystemCallDebugChecks+89
|
|
BUCKET_ID: 0x1_nt!KiExitSystemCallDebugChecks+89
|
|
Followup: MachineOwner
|
---------
|
|
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: 0000001b, address of system function (system call)
|
Arg2: 00000000, Thread->ApcStateIndex << 8 | Previous ApcStateIndex
|
Arg3: 0000ffff, Thread->KernelApcDisable
|
Arg4: 00000000, Previous KernelApcDisable
|
|
Debugging Details:
|
------------------
|
|
|
FAULTING_IP:
|
+6433633865646363
|
0000001b ?? ???
|
|
DEFAULT_BUCKET_ID: DRIVER_FAULT
|
|
BUGCHECK_STR: 0x1
|
|
PROCESS_NAME: firefox.exe
|
|
CURRENT_IRQL: 0
|
|
LAST_CONTROL_TRANSFER: from 804774a8 to 8050e868
|
|
STACK_TEXT:
|
f7e3b914 804774a8 00000003 f7e3bc34 ffdff408 nt!RtlpBreakWithStatusInstruction
|
f7e3b944 80477db3 00000003 55555555 0b378020 nt!KiBugCheckDebugBreak+0x38 [h:\trunk\reactos_clean\ntoskrnl\ke\bug.c @ 538]
|
f7e3bce0 80478410 00000001 0000001b 00000000 nt!KeBugCheckWithTf+0x553 [h:\trunk\reactos_clean\ntoskrnl\ke\bug.c @ 1102]
|
f7e3bd00 804f4dd9 00000001 0000001b 00000000 nt!KeBugCheckEx+0x20 [h:\trunk\reactos_clean\ntoskrnl\ke\bug.c @ 1462]
|
f7e3bd20 804f4705 0000001b f7e3bd64 ffdff6b8 nt!KiExitSystemCallDebugChecks+0x89 [h:\trunk\reactos_clean\ntoskrnl\include\internal\i386\trap_x.h @ 230]
|
f7e3bd5c 80403e23 0c96fd14 7c92c80e badb0d00 nt!KiSystemServiceHandler+0x255 [h:\trunk\reactos_clean\ntoskrnl\ke\i386\traphdlr.c @ 1744]
|
f7e3bd5c 7c92c80e 0c96fd14 7c92c80e badb0d00 nt!KiFastCallEntry+0x8c
|
0c96fd00 7c950e91 7c7c7628 00000980 aaaaaaaa ntdll!KiFastSystemCallRet
|
0c96fd04 7c7c7628 00000980 aaaaaaaa 00684180 ntdll!ZwClose+0xc
|
0c96fd14 007183f7 00000980 00000000 091b9400 KERNEL32!CloseHandle+0x38 [h:\trunk\reactos_clean\dll\win32\kernel32\client\handle.c @ 137]
|
WARNING: Stack unwind information not available. Following frames may be wrong.
|
0c96fd24 007183c5 0b378020 0116eb21 0b378020 nss3!PR_Close+0x3c
|
0c96fd2c 0116eb21 0b378020 091b9408 091b9400 nss3!PR_Close+0xa
|
0c96fd3c 0116ee78 091b9400 0116ee47 091b9400 xul+0x45eb21
|
0c96fd44 0116ee47 091b9400 00eb2126 00000001 xul+0x45ee78
|
0c96fd4c 00eb2126 00000001 00000000 00000000 xul+0x45ee47
|
0c96fd5c 00f495c2 091b9400 00fcbf81 00000000 xul+0x1a2126
|
00000000 00000000 00000000 00000000 00000000 xul+0x2395c2
|
|
|
STACK_COMMAND: kb
|
|
FOLLOWUP_IP:
|
nt!KiExitSystemCallDebugChecks+89 [h:\trunk\reactos_clean\ntoskrnl\include\internal\i386\trap_x.h @ 230]
|
804f4dd9 8be5 mov esp,ebp
|
|
FAULTING_SOURCE_CODE:
|
226: KeGetCurrentThread()->CombinedApcDisable,
|
227: 0);
|
228: }
|
229: }
|
> 230: }
|
231:
|
232: //
|
233: // Generic Exit Routine
|
234: //
|
235: DECLSPEC_NORETURN VOID FASTCALL KiSystemCallReturn(IN PKTRAP_FRAME TrapFrame);
|
|
|
SYMBOL_STACK_INDEX: 4
|
|
SYMBOL_NAME: nt!KiExitSystemCallDebugChecks+89
|
|
FOLLOWUP_NAME: MachineOwner
|
|
MODULE_NAME: nt
|
|
IMAGE_NAME: ntoskrnl.exe
|
|
DEBUG_FLR_IMAGE_TIMESTAMP: 579164a9
|
|
FAILURE_BUCKET_ID: 0x1_nt!KiExitSystemCallDebugChecks+89
|
|
BUCKET_ID: 0x1_nt!KiExitSystemCallDebugChecks+89
|
|
Followup: MachineOwner
|
---------
|
Attachments
Issue Links
- relates to
-
CORE-11555 reproductible BSOD APC_INDEX_MISMATCH without assertion beforehand
- Resolved
-
CORE-10026 APC_INDEX_MISMATCH in 2nd stage when running with 64 MB RAM
- Resolved
-
CORE-11328 APC_INDEX_MISMATCH (1) - Firefox 46.0.1 on ROS 0.5-svn r71430
- Resolved
-
CORE-11906 [NTOS] Regression BSOD APC_INDEX_MISMATCH is back
- Resolved