Need help to understand kernel debugging error - windows

Question

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
---------

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.