Advanced Debugging
About AdvDbg Consult Train Services Products Tools Community Contact  
欢迎光临 高端调试 登录 | 注册 | FAQ
 
  ACPI调试
Linux内核调试
Windows内核调试
 
  调试战役
调试原理
新工具观察
 
  Linux
Windows Vista
Windows
 
  Linux驱动
WDF
WDM
 
  PCI Express
PCI/PCI-X
USB
无线通信协议
 
  64位CPU
ARM
IA-32
  CPU Info Center
 
  ACPI标准
系统认证
Desktop
服务器
 
  Embedded Linux
嵌入式开发工具
VxWorks
WinCE
嵌入式Windows
 
  格蠹调试套件(GDK)
  格蠹学院
  小朱书店
  老雷的微博
  《软件调试》
  《格蠹汇编》
  《软件调试(第二版)》
沪ICP备11027180号-1

Windows内核调试

帖子发起人: holly   发起时间: 2008-08-21 17:21 下午   回复: 9

Print Search
帖子排序:    
   2008-08-21, 17:21 下午
hollyhunter 离线,最后访问时间: 2009/10/10 9:42:36 holly

发帖数前50位
注册: 2008-07-14
发 贴: 22
一个困扰很久的蓝屏
Reply Quote

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

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

 


IP 地址: 已记录   报告
   2008-08-21, 18:04 下午
Coding 离线,最后访问时间: 2010/2/20 12:12:52 Coding

发帖数前10位
注册: 2008-05-31
发 贴: 103
Re: 一个困扰很久的蓝屏
Reply Quote

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

 我猜也许是这个原因。


IP 地址: 已记录   报告
   2008-08-22, 09:56 上午
hollyhunter 离线,最后访问时间: 2009/10/10 9:42:36 holly

发帖数前50位
注册: 2008-07-14
发 贴: 22
Re: 一个困扰很久的蓝屏
Reply Quote
谢谢!
DIRQL的具体值有参考吗?
似乎这只是一个设备中断的统称,该把这个值作为多少呢?
DDK的头文件中也没有该值的定义。

IP 地址: 已记录   报告
   2008-08-22, 10:03 上午
hollyhunter 离线,最后访问时间: 2009/10/10 9:42:36 holly

发帖数前50位
注册: 2008-07-14
发 贴: 22
Re: 一个困扰很久的蓝屏
Reply Quote
DIRQL: from 3 to 26 for device ISR
重新翻看了一下《Understanding IRQL》
找到这样一句话,看来你的猜测正确,DbgPrint即使是非Unicode版本也不能用于超过IRQL>26的上下文中.
Thanks!

IP 地址: 已记录   报告
   2008-08-22, 10:25 上午
hollyhunter 离线,最后访问时间: 2009/10/10 9:42:36 holly

发帖数前50位
注册: 2008-07-14
发 贴: 22
Re: 一个困扰很久的蓝屏
Reply Quote
看来KeAttachProcess这个动作可能进入到某进程的高IRQL的上下文代码中。
我想通常我们的驱动程序代码是不应当具备这么高的中断级别的吧,遇到这种高IRQL的情况,安全起见,是否应该避开更为妥当些?
也就是发现IRQL过高,直接调用KeDetachProcess等待下一次进入。

IP 地址: 已记录   报告
   2008-08-22, 12:10 下午
hollyhunter 离线,最后访问时间: 2009/10/10 9:42:36 holly

发帖数前50位
注册: 2008-07-14
发 贴: 22
Re: 一个困扰很久的蓝屏--仍是疑难杂症
Reply Quote
按上述推测进行代码调整,依然会出现蓝屏,不知道如何处理了!
调整的代码为在进入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
---------


IP 地址: 已记录   报告
   2008-08-23, 23:12 下午
Raymond 离线,最后访问时间: 2020/7/3 3:40:25 格蠹老雷

发帖数前10位
注册: 2005-12-19
发 贴: 1,303
Re: 一个困扰很久的蓝屏--仍是疑难杂症
Reply Quote
KeAttachProcess是个比较危险的操作,估计是这个操作导致了问题。建议你仔细跟踪你的代码或者写LOG,了解调用这个函数前后的情况。
下面链接中的介绍或许对你有帮助:
http://www.windowsitlibrary.com/Content/356/04/7.html

IP 地址: 已记录   报告
   2008-08-27, 12:08 下午
hollyhunter 离线,最后访问时间: 2009/10/10 9:42:36 holly

发帖数前50位
注册: 2008-07-14
发 贴: 22
Re: 一个困扰很久的蓝屏
Reply Quote

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

IP 地址: 已记录   报告
   2008-09-29, 16:20 下午
irp 离线,最后访问时间: 2010/3/8 23:15:26 johnl

发帖数前150位
注册: 2008-09-29
发 贴: 9
Re: 一个困扰很久的蓝屏
Reply Quote
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));
IP 地址: 已记录   报告
   2008-09-29, 16:20 下午
irp 离线,最后访问时间: 2010/3/8 23:15:26 johnl

发帖数前150位
注册: 2008-09-29
发 贴: 9
Re: 一个困扰很久的蓝屏
Reply Quote
WDK doc 讲的比较清楚,在call KeAttachProcess之前应该检查irql <= irql_dispatch_level.
我建议你严格条件为passive_level更符合逻辑。另外,detach 也要 <= irql_dispatch_level.
你自己的dispatch routine的irql要清楚。

IP 地址: 已记录   报告
高端调试 » 软件调试 » Windows内核调试 » Re: 一个困扰很久的蓝屏

 
Legal Notice Privacy Statement Corporate Governance Corporate Governance
(C)2004-2020 ADVDBG.ORG All Rights Reserved.