Re: 一个困扰很久的蓝屏

Windows内核调试

一个困扰很久的蓝屏

holly 2008-08-21, 17:21 下午

总是偶然出现的蓝屏，能力有限，无法判断该如何处理，来求教各位前辈高手！

  CurIRQL = KeGetCurrentIrql();Crach Dump的指示似乎总是这一句的问题，但是这句如何导致空地址访问的呢？

而且IROL又是一个CLOCK2_LEVEL的代码。

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: 00000000, 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: 804f9913, address which referenced memory

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


READ_ADDRESS:  00000000

CURRENT_IRQL:  1c

FAULTING_IP:
nt!KeStartThread+11
804f9913 8b10            mov     edx,dword ptr [eax]

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0xA

MISALIGNED_IP:
nt!KeStartThread+11
804f9913 8b10            mov     edx,dword ptr [eax]

LAST_CONTROL_TRANSFER:  from 804f9a20 to 804f9913

STACK_TEXT: 
b434864c 804f9a20 89240020 8952bc90 8952bc00 nt!KeStartThread+0x11
b434866c b3faf38d 8952bc00 894f4920 b4348690 nt!RtlAppendUnicodeToString+0x2f
b43486b0 b3faeb20 89082568 88fdb000 00040000 Freezer!GetAllProcessBeEP+0xfd [e:\working\withlenovo\withlenovo\freezerdrv\freezer.cpp @ 534]
b43486ec 804f0095 890824b0 8b5a8f68 806e5428 Freezer!FzIOCtrlDispatch+0x180 [e:\working\withlenovo\withlenovo\freezerdrv\freezer.cpp @ 204]
b4348720 8057f70a 8b5a8fd8 8917a3b8 8b5a8f68 nt!CcAcquireByteRangeForWrite+0x726
b4348734 8058056d 890824b0 8b5a8f68 8917a3b8 nt!NtImpersonateThread+0xda
b43487d0 805790c2 00000f58 00000000 00000000 nt!NtQueryObject+0x107
b4348804 8054186c 00000f58 00000000 00000000 nt!NtCreateMutant+0x89
b4348834 7c90eb94 badb0d00 0012f0d8 00000000 nt!RtlIpv6StringToAddressA+0x17f
WARNING: Frame IP not in any known module. Following frames may be wrong.
b4348844 00000000 00000000 00000000 b4348938 0x7c90eb94


STACK_COMMAND:  kb

FOLLOWUP_IP:
Freezer!GetAllProcessBeEP+fd [e:\working\withlenovo\withlenovo\freezerdrv\freezer.cpp @ 534]
b3faf38d ??              ???

FAULTING_SOURCE_CODE: 
   530: //  EnableLog(FALSE);
   531:   KeAttachProcess(pNode->eProcess);
   532:
   533:   KIRQL   CurIRQL;
>  534:   CurIRQL = KeGetCurrentIrql();
   535:   DbgPrint ("Current IRQL is %d\r\n", CurIRQL);
   536:   if (PASSIVE_LEVEL == CurIRQL)
   537:   {  
   538:    pstrProcPath = GetImagePathFromEP(pNode->eProcess);
   539:    if((pstrProcPath != NULL)


SYMBOL_STACK_INDEX:  2

SYMBOL_NAME:  Freezer!GetAllProcessBeEP+fd

FOLLOWUP_NAME:  MachineOwner

IMAGE_NAME:  hardware

DEBUG_FLR_IMAGE_TIMESTAMP:  0

MODULE_NAME: hardware

FAILURE_BUCKET_ID:  IP_MISALIGNED

BUCKET_ID:  IP_MISALIGNED

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

 

Re: 一个困扰很久的蓝屏

Coding 2008-08-21, 18:04 下午

从RtlAppendUnicodeToString来看，似乎KeGetCurrentIrql已经执行完了，正在处理DbgPrint里面的字符串。 在MSDN里面有一段话          

DbgPrint and DbgPrintEx can be called at IRQL<=DIRQL. However, Unicode format codes can be used only at IRQL PASSIVE_LEVEL. Also, because the debugger uses interprocess interrupts (IPIs) to communicate with other processors, calling DbgPrint at IRQL>DIRQL can cause deadlocks.

 我猜也许是这个原因。

Re: 一个困扰很久的蓝屏

holly 2008-08-22, 09:56 上午
谢谢！
DIRQL的具体值有参考吗？
似乎这只是一个设备中断的统称，该把这个值作为多少呢？
DDK的头文件中也没有该值的定义。

Re: 一个困扰很久的蓝屏

holly 2008-08-22, 10:03 上午
DIRQL: from 3 to 26 for device ISR
重新翻看了一下《Understanding IRQL》
找到这样一句话，看来你的猜测正确，DbgPrint即使是非Unicode版本也不能用于超过IRQL>26的上下文中.
Thanks!

Re: 一个困扰很久的蓝屏

holly 2008-08-22, 10:25 上午
看来KeAttachProcess这个动作可能进入到某进程的高IRQL的上下文代码中。
我想通常我们的驱动程序代码是不应当具备这么高的中断级别的吧，遇到这种高IRQL的情况，安全起见，是否应该避开更为妥当些？
也就是发现IRQL过高，直接调用KeDetachProcess等待下一次进入。

Re: 一个困扰很久的蓝屏--仍是疑难杂症

holly 2008-08-22, 12:10 下午
按上述推测进行代码调整，依然会出现蓝屏，不知道如何处理了！
调整的代码为在进入KeAttachProcess之后，判断如果IRQL过高，即调用KeDetachProcess然后稍作等待，再次尝试，等目标进程合适的IRQL的出现。
运行环境WinXP SP2 VS2005 调试状态下运行应用程序并调用驱动。


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: 00000000, 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: 804f9913, address which referenced memory

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


READ_ADDRESS: 00000000

CURRENT_IRQL: 1c

FAULTING_IP:
nt!KeStartThread+11
804f9913 8b10 mov edx,dword ptr [eax]

CUSTOMER_CRASH_COUNT: 2

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

MISALIGNED_IP:
nt!KeStartThread+11
804f9913 8b10 mov edx,dword ptr [eax]

LAST_CONTROL_TRANSFER: from 804f9a20 to 804f9913

STACK_TEXT:
aef75644 804f9a20 896129a8 8962bda0 8962bd00 nt!KeStartThread+0x11
aef75664 b3fbc38d 8962bd00 8963af38 b3fbd9de nt!RtlAppendUnicodeToString+0x2f
aef756b0 b3fbbb20 89354798 89312000 00040000 Freezer!GetAllProcessBeEP+0xfd [e:\working\withlenovo\withlenovo\freezerdrv\freezer.cpp @ 533]
aef756ec 804f0095 893546e0 8b2cef68 806e5428 Freezer!FzIOCtrlDispatch+0x180 [e:\working\withlenovo\withlenovo\freezerdrv\freezer.cpp @ 204]
aef75720 8057f70a 8b2cefd8 893a58d0 8b2cef68 nt!CcAcquireByteRangeForWrite+0x726
aef75734 8058056d 893546e0 8b2cef68 893a58d0 nt!NtImpersonateThread+0xda
aef757d0 805790c2 00000f58 00000000 00000000 nt!NtQueryObject+0x107
aef75804 8054186c 00000f58 00000000 00000000 nt!NtCreateMutant+0x89
aef75834 7c90eb94 badb0d00 0012e9b0 00000000 nt!RtlIpv6StringToAddressA+0x17f
WARNING: Frame IP not in any known module. Following frames may be wrong.
aef75844 00000000 00000000 00000000 aef75938 0x7c90eb94


STACK_COMMAND: kb

FOLLOWUP_IP:
Freezer!GetAllProcessBeEP+fd [e:\working\withlenovo\withlenovo\freezerdrv\freezer.cpp @ 533]
b3fbc38d ?? ???

FAULTING_SOURCE_CODE:
529: PUNICODE_STRING pstrProcPath;
530: // EnableLog(FALSE);
531: KeAttachProcess(pNode->eProcess);
532: KIRQL CurIRQL;
> 533: CurIRQL = KeGetCurrentIrql();
534: while(CurIRQL > DISPATCH_LEVEL)
535: {
536: KeDetachProcess();
537: // wait for low IRQL
538: LogPrint((g_DevExt->hLogFile, "KeAttachProcess IRQL is %d\r\n", CurIRQL));


SYMBOL_STACK_INDEX: 2

SYMBOL_NAME: Freezer!GetAllProcessBeEP+fd

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: hardware

DEBUG_FLR_IMAGE_TIMESTAMP: 0

MODULE_NAME: hardware

FAILURE_BUCKET_ID: IP_MISALIGNED

BUCKET_ID: IP_MISALIGNED

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

Re: 一个困扰很久的蓝屏--仍是疑难杂症

格蠹老雷 2008-08-23, 23:12 下午
KeAttachProcess是个比较危险的操作，估计是这个操作导致了问题。建议你仔细跟踪你的代码或者写LOG，了解调用这个函数前后的情况。
下面链接中的介绍或许对你有帮助：
http://www.windowsitlibrary.com/Content/356/04/7.html

Re: 一个困扰很久的蓝屏

holly 2008-08-27, 12:08 下午

IRQL 0x1c是一个CLOCK2_LEVEL的中断。
我在上层应用程序中是采用定时器调用驱动接口，不知道有什么影响。
现在测试改为普通的程序循环不停的调用中断2千万次，目前还没有发现问题。
~~
郁闷中。。。

Re: 一个困扰很久的蓝屏

johnl 2008-09-29, 16:20 下午
WDK doc 讲的比较清楚，在call KeAttachProcess之前应该检查irql 533: CurIRQL = KeGetCurrentIrql();
534: while(CurIRQL > DISPATCH_LEVEL) ？？？
535: {
536: KeDetachProcess();
537: // wait for low IRQL
538: LogPrint((g_DevExt->hLogFile, "KeAttachProcess IRQL is %d\r\n", CurIRQL));

Re: 一个困扰很久的蓝屏

johnl 2008-09-29, 16:20 下午
WDK doc 讲的比较清楚，在call KeAttachProcess之前应该检查irql <= irql_dispatch_level.
我建议你严格条件为passive_level更符合逻辑。另外，detach 也要 <= irql_dispatch_level.
你自己的dispatch routine的irql要清楚。

Powered by Community Server Powered by CnForums.Net