Need help to understand kernel debugging error

1

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
 ---------
windows
driver
windbg
asked on Stack Overflow May 27, 2014 by Akatsuki • edited Jun 20, 2020 by Community

1 Answer

1

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.

answered on Stack Overflow Jun 27, 2014 by AndreVa

User contributions licensed under CC BY-SA 3.0