搜索论坛 帖子排序:  Oldest to newest Newest to oldest

2008-08-21, 17:21 下午 holly 注册: 2008-07-14 发 贴: 22 一个困扰很久的蓝屏 总是偶然出现的蓝屏，能力有限，无法判断该如何处理，来求教各位前辈高手！   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 注册: 2008-05-31 发 贴: 103 Re: 一个困扰很久的蓝屏 从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 上午 holly 注册: 2008-07-14 发 贴: 22 Re: 一个困扰很久的蓝屏 谢谢！ DIRQL的具体值有参考吗？ 似乎这只是一个设备中断的统称，该把这个值作为多少呢？ DDK的头文件中也没有该值的定义。 IP 地址: 已记录   报告

2008-08-22, 10:03 上午 holly 注册: 2008-07-14 发 贴: 22 Re: 一个困扰很久的蓝屏 DIRQL: from 3 to 26 for device ISR 重新翻看了一下《Understanding IRQL》 找到这样一句话，看来你的猜测正确，DbgPrint即使是非Unicode版本也不能用于超过IRQL>26的上下文中. Thanks! IP 地址: 已记录   报告

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

2008-08-22, 12:10 下午 holly 注册: 2008-07-14 发 贴: 22 Re: 一个困扰很久的蓝屏--仍是疑难杂症 按上述推测进行代码调整，依然会出现蓝屏，不知道如何处理了！ 调整的代码为在进入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 下午 格蠹老雷 注册: 2005-12-19 发 贴: 1,303 Re: 一个困扰很久的蓝屏--仍是疑难杂症 KeAttachProcess是个比较危险的操作，估计是这个操作导致了问题。建议你仔细跟踪你的代码或者写LOG，了解调用这个函数前后的情况。 下面链接中的介绍或许对你有帮助： http://www.windowsitlibrary.com/Content/356/04/7.html IP 地址: 已记录   报告

2008-08-27, 12:08 下午 holly 注册: 2008-07-14 发 贴: 22 Re: 一个困扰很久的蓝屏 IRQL 0x1c是一个CLOCK2_LEVEL的中断。 我在上层应用程序中是采用定时器调用驱动接口，不知道有什么影响。 现在测试改为普通的程序循环不停的调用中断2千万次，目前还没有发现问题。 ~~ 郁闷中。。。 IP 地址: 已记录   报告

2008-09-29, 16:20 下午 johnl 注册: 2008-09-29 发 贴: 9 Re: 一个困扰很久的蓝屏 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 下午 johnl 注册: 2008-09-29 发 贴: 9 Re: 一个困扰很久的蓝屏 WDK doc 讲的比较清楚，在call KeAttachProcess之前应该检查irql <= irql_dispatch_level. 我建议你严格条件为passive_level更符合逻辑。另外，detach 也要 <= irql_dispatch_level. 你自己的dispatch routine的irql要清楚。 IP 地址: 已记录   报告

高端调试 » 软件调试 » Windows内核调试 » Re: 一个困扰很久的蓝屏--仍是疑难杂症

请选择 论坛首页 |- 论坛搜索 |- 热门主题 |- 未回复的主题 用户选项 |- 登录 |- 注册 |- 找回密码 软件调试 |- Windows内核调试 |- C/C++本地代码调试 |- .Net程序调试 |- 脚本程序调试 |- Java程序调试 |- Linux内核调试 |- 《程序员》杂志调试专栏 |- WinDbg |- GDB |- 远程调试 |- 调试ACPI和BIOS |- 特殊的调试任务 |- 转储分析 |- GDK7 内核探秘 |- Windows内核 |- Linux内核 系统架构 |- CPU架构 |- PCI/PCI Express架构 程序人生 |- 软件物语 |- 社区活动 |- 名人逸事 联盟论坛 |- 欢迎使用CnForums 没有银弹 |- BUG也精彩 |- 豆腐工程 |- 软件圈里十大怪 Windows Vista |- 用调试利剑剖析VISTA内幕 |- 老专家如何破解新问题 |- 我的电脑谁说了算？ |- 资源 Office开发 |- Visio 驱动程序开发 |- Windows驱动开发 |- Linux驱动开发 |- Windows CE驱动开发 用户态开发 |- Windows本地代码（native）高级开发 |- Web应用开发 |- WinFX和.Net |- Office开发 本站建设 |- 高端调试团队 |- 版面布局 |- 活动建议 |- 网站维护 64位计算 |- 64-bit Windows |- 64-bit CPU 图书 |- 《软件调试》的示例程序 |- 《软件调试》的工具 |- 《软件调试》书友 |- 《软件调试》答疑 |- 《软件调试》勘误和意见 |- 《格蠹汇编》 |- 《软件调试》第二版卷1 |- 《软件调试》第二版卷2 云计算 |- IaaS |- 云存储 |- 大数据 |- PaaS和SaaS GPU |- CUDA |- OpenCL |- HSA |- 游戏开发与调试