一个莫明的错,有小64K转储

在有一次测试中，驱动出现在蓝屏，蓝屏在重启前后连接两次发生。而以前及今后的测试中。都没发生这样的情况。

通过小64K转储分析得到下面结果。


0: 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: 00000016, memory referenced
Arg2: 0000001c, 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: 805033b2, address which referenced memory

MODULE_NAME: ATWatch

FAULTING_MODULE: 804d8000 nt

DEBUG_FLR_IMAGE_TIMESTAMP:  490d8b27

READ_ADDRESS: unable to get nt!MmSpecialPoolStart
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPoolCodeStart
unable to get nt!MmPoolCodeEnd
00000016

CURRENT_IRQL:  1c

FAULTING_IP:
nt+2b3b2
805033b2 6683781601      cmp     word ptr [eax+16h],1

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  WRONG_SYMBOLS

BUGCHECK_STR:  0xA

LAST_CONTROL_TRANSFER:  from 804fb166 to 805033b2

STACK_TEXT:  
WARNING: Stack unwind information not available. Following frames may be wrong.
f79dbd44 804fb166 f7d6c2c4 f879bde8 864dfc30 nt+0x2b3b2
f79dbd58 f781c5a5 f879bde8 00000000 00000000 nt+0x23166
f79dbd7c 805389dd 844f0738 00000000 865b3da8 ATWatch!NLPGetDosDeviceNameWorker+0xaf [g:\ddk\filter0810\lib\namelookup.c @ 1505]
f79dbdac 805cf858 844f0738 00000000 00000000 nt+0x609dd
f79dbddc 8054634e 805388ee 00000001 00000000 nt+0xf7858
00000000 00000000 00000000 00000000 00000000 nt+0x6e34e


STACK_COMMAND:  kb

FOLLOWUP_IP:
ATWatch!NLPGetDosDeviceNameWorker+af [g:\ddk\filter0810\lib\namelookup.c @ 1505]
f781c5a5 8b7508          mov     esi,dword ptr [ebp+8]

FAULTING_SOURCE_CODE:  
  1501:       }
  1502:     }//else if(newDevExt->NLExtHeader.DosName.Length > 0)*/
  1503:   }//if(t_ControlDeviceObject != NULL)
  1504:
> 1505:     ObDereferenceObject( Context->DeviceObject );
  1506:     ExFreePoolWithTag( Context, NL_POOL_TAG );
  1507:
  1508:     return;
  1509:
  1510: }


SYMBOL_STACK_INDEX:  2

SYMBOL_NAME:  ATWatch!NLPGetDosDeviceNameWorker+af

FOLLOWUP_NAME:  MachineOwner

IMAGE_NAME:  ATWatch.sys

BUCKET_ID:  WRONG_SYMBOLS

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



这代码其实就是 filter 里 namelookup.c 中的。
很明显的，NLPGetDosDeviceNameWorker 工作在 PASSIVE_LEVEL 。是通过 ExQueueWorkItem( &completionContext->WorkItem ,DelayedWorkQueue ); 插入到 system 里执行的。

但是，蓝屏的时候提示 IRQL_NOT_LESS_OR_EQUAL (a) ，而 CURRENT_IRQL:  1c 。。。
天啦。我不懂了。难道微软出错了吗？？？？？

是微软错的可能性估计只是你程序错误可能性的万分之一都不到，除非你是大师级人物，否则先找自己的错误


IRQL_NOT_LESS_OR_EQUAL 这个出现的原因太多了，不能在一些IRQL访问分页变量之类的

呵呵，当然是开玩笑的。

只不过不明白，为什么都用 ExQueueWorkItem 降低IRQ 了。
为什么这段代码还会运行在 CURRENT_IRQL:  1c

出现此错误码不一定是由于IRQL不正确导致的，好好查查代码