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

2008-08-26, 09:23 上午 pch 注册: 2008-08-26 发 贴: 28 请教！在win2003内核中加入了些读取系统信息的DbgPrint,出现了以下错误，不知为什么？ *** Fatal System Error: 0x0000000a (0x00000002,0x0000001B,0x00000000,0x8087DCCC) 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. Connected to Windows Server 2003 3800 x86 compatible target, ptr64 FALSE Loading Kernel Symbols ..WARNING: Process directory table base 04357000 doesn't match CR3 005A2000 WARNING: Process directory table base 04357000 doesn't match CR3 005A2000 ...................................................................................... Loading User Symbols WARNING: Loader 7c889e0c timestamp 42435e37 != header timestamp 42435b9a ................................................................................................................. Loading unloaded module list ...*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll - ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck A, {2, 1b, 0, 8087dccc} *** ERROR: Module load completed but symbols could not be loaded for mssmbios.sys *** ERROR: Symbol file could not be found. Defaulted to export symbols for HALACPIM.DLL - *** ERROR: Module load completed but symbols could not be loaded for Ntfs.sys *** ERROR: Symbol file could not be found. Defaulted to export symbols for fltMgr.sys - Probably caused by : wrkx86.exe ( nt!_output+663 ) Followup: MachineOwner --------- nt!RtlpBreakWithStatusInstruction: 8086244c cc int 3 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: 00000002, memory referenced Arg2: 0000001b, IRQL Arg3: 00000000, value 0 = read operation, 1 = write operation Arg4: 8087dccc, address which referenced memory Debugging Details: ------------------ READ_ADDRESS: 00000002 CURRENT_IRQL: 1b FAULTING_IP: nt!_output+663 [d:\dnsrv\base\crts\crtw32\stdio\output.c @ 871] 8087dccc 803800 cmp byte ptr [eax],0 DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO BUGCHECK_STR: 0xA PROCESS_NAME: svchost.exe TRAP_FRAME: f7c989e0 -- (.trap fffffffff7c989e0) ErrCode = 00000000 eax=00000100 ebx=00000000 ecx=00000040 edx=0100b000 esi=0100b000 edi=f7c98a60 eip=80901859 esp=f7c98a54 ebp=f7c98cbc iopl=0 nv up ei pl nz na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000202 nt!MiDoPoolCopy+0xd3: 80901859 f3a5 rep movs dword ptr es:[edi],dword ptr [esi] es:0023:f7c98a60={svchost (01000000)} ds:0023:0100b000=???????? Resetting default scope LAST_CONTROL_TRANSFER: from 808245df to 8086244c STACK_TEXT: f7c979bc 808245df 00000003 00000000 0000000a nt!RtlpBreakWithStatusInstruction [C:\WRK-v1.2\base\ntos\rtl\i386\debug2.asm @ 47] f7c97a08 8082507e 00000003 00000002 8087dccc nt!KiBugCheckDebugBreak+0x19 [c:\wrk-v1.2\base\ntos\ke\bugcheck.c @ 252] f7c97da0 808861a3 0000000a 00000002 0000001b nt!KeBugCheck2+0x5a4 [c:\wrk-v1.2\base\ntos\ke\bugcheck.c @ 860] f7c97da0 8087dccc 0000000a 00000002 0000001b nt!_KiTrap0E+0x2a7 [C:\WRK-v1.2\base\ntos\ke\i386\trap.asm @ 5739] f7c9809c 808737d2 f7c980b8 80830452 f7c9836c nt!_output+0x663 [d:\dnsrv\base\crts\crtw32\stdio\output.c @ 871] f7c980d8 808624f3 f7c98124 00000200 80830452 nt!_vsnprintf+0x2f [d:\dnsrv\base\crts\crtw32\stdio\vsprintf.c @ 130] f7c98340 808626be 808626a2 ffffffff 00000000 nt!vDbgPrintExWithPrefixInternal+0x9d [c:\wrk-v1.2\base\ntos\rtl\debug.c @ 323] f7c98360 80830643 80830452 00000780 00000002 nt!DbgPrint+0x1a [c:\wrk-v1.2\base\ntos\rtl\debug.c @ 75] f7c98388 80887400 80a4bb6c 00000000 f7c98420 nt!KiQuantumEnd+0x1c5 [c:\wrk-v1.2\base\ntos\ke\dpcsup.c @ 339] f7c9838c 80a4bb6c 00000000 f7c98420 fbf27567 nt!KiDispatchInterrupt+0xd0 [C:\WRK-v1.2\base\ntos\ke\i386\ctxswap.asm @ 315] WARNING: Stack unwind information not available. Following frames may be wrong. f7c98420 fbf27e5f ff7b8c10 f7c9856c 00000000 HALACPIM!HalClearSoftwareInterrupt+0x1b0 f7c985e8 fbf2575e f7c986e8 ff7b8c10 e10d9a30 Ntfs+0x5e5f f7c986d4 fbf288de f7c986e8 ff7b8c10 00000001 Ntfs+0x375e f7c98880 8081f7ad 8120f020 ff7b8c10 812546e8 Ntfs+0x68de f7c98894 fbfe2c53 812546e8 00000000 00000306 nt!IofCallDriver+0x43 [c:\wrk-v1.2\base\ntos\io\iomgr\iosubs.c @ 2253] f7c988bc 8081f7ad 81210020 ff7b8c10 ff7b8c10 fltMgr!FltGetIrpName+0x11ed f7c988d0 80820083 81205378 ff7db870 81205368 nt!IofCallDriver+0x43 [c:\wrk-v1.2\base\ntos\io\iomgr\iosubs.c @ 2253] f7c988e8 8084c28c ffa40c09 812053a0 81205380 nt!IoPageRead+0x107 [c:\wrk-v1.2\base\ntos\io\iomgr\iosubs.c @ 9266] f7c9896c 80857682 00000000 0100b000 c000402c nt!MiDispatchFault+0xd28 [c:\wrk-v1.2\base\ntos\mm\pagfault.c @ 1241] f7c989c8 80885fd8 00000000 0100b000 00000000 nt!MmAccessFault+0x9c0 [c:\wrk-v1.2\base\ntos\mm\mmfault.c @ 2001] f7c989c8 80901859 00000000 0100b000 00000000 nt!_KiTrap0E+0xdc [C:\WRK-v1.2\base\ntos\ke\i386\trap.asm @ 5527] f7c98cbc 80901a0e 81160d88 0100b000 ff88d020 nt!MiDoPoolCopy+0xd3 [c:\wrk-v1.2\base\ntos\mm\readwrt.c @ 901] f7c98cec 80901b08 81160d88 0100b000 ff88d020 nt!MmCopyVirtualMemory+0x98 [c:\wrk-v1.2\base\ntos\mm\readwrt.c @ 432] f7c98d48 8088303c 00000594 0100b000 0206d304 nt!NtReadVirtualMemory+0xd0 [c:\wrk-v1.2\base\ntos\mm\readwrt.c @ 199] f7c98d48 7c82ed54 00000594 0100b000 0206d304 nt!KiFastCallEntry+0xfc [C:\WRK-v1.2\base\ntos\ke\i386\trap.asm @ 1369] 0206d438 00000000 00000000 00000000 00000000 ntdll!KiFastSystemCallRet STACK_COMMAND: kb FOLLOWUP_IP: nt!_output+663 [d:\dnsrv\base\crts\crtw32\stdio\output.c @ 871] 8087dccc 803800 cmp byte ptr [eax],0 SYMBOL_STACK_INDEX: 4 SYMBOL_NAME: nt!_output+663 FOLLOWUP_NAME: MachineOwner MODULE_NAME: nt IMAGE_NAME: wrkx86.exe DEBUG_FLR_IMAGE_TIMESTAMP: 48afbfe8 FAILURE_BUCKET_ID: 0xA_nt!_output+663 BUCKET_ID: 0xA_nt!_output+663 Followup: MachineOwner IP 地址: 已记录   报告

2008-08-26, 10:22 上午 王宇 注册: 2007-05-08 发 贴: 306 Re: 请教！在win2003内核中加入了些读取系统信息的DbgPrint,出现了以下错误，不知为什么？ 表象倒是不难，又是一寻址问题.. 楼主改的KiQuantumEnd()做调度实验？ 楼主把什么参数传给DbgPrint了？要小心呀，这时的IRQL非常高的。 IP 地址: 已记录   报告

2008-08-26, 10:33 上午 Coding 注册: 2008-05-31 发 贴: 103 Re: 请教！在win2003内核中加入了些读取系统信息的DbgPrint,出现了以下错误，不知为什么？ 我觉得可以从两个地方分析 第一 Arg4: 8087dccc, address which referenced memory nt!_output+663 [d:\dnsrv\base\crts\crtw32\stdio\output.c @ 871] 8087dccc 803800 cmp byte ptr [eax],0 eax=00000100 ebx=00000000 ecx=00000040 edx=0100b000 esi=0100b000 edi=f7c98a60 可以看到对[eax]的访问可能有问题。 第二 f7c98360 80830643 80830452 00000780 00000002 nt!DbgPrint+0x1a [c:\wrk-v1.2\base\ntos\rtl\debug.c @ 75] f7c98388 80887400 80a4bb6c 00000000 f7c98420 nt!KiQuantumEnd+0x1c5 [c:\wrk-v1.2\base\ntos\ke\dpcsup.c @ 339] f7c9838c 80a4bb6c 00000000 f7c98420 fbf27567 nt!KiDispatchInterrupt+0xd0 [C:\WRK-v1.2\base\ntos\ke\i386\ctxswap.asm @ 315] Arg2: 0000001b, IRQL 1b==27,DbgPrint运行在了比较高的IRQL上，根据MSDN “DbgPrint and DbgPrintEx can be called at IRQL<=DIRQL”，可能是这里除了问题 在x86的处理器上，DIRQL = 3~26。 IP 地址: 已记录   报告

2008-08-26, 12:17 下午 pch 注册: 2008-08-26 发 贴: 28 Re: 请教！在win2003内核中加入了些读取系统信息的DbgPrint,出现了以下错误，不知为什么？ 首先谢谢您的回复； 我是在KiQuantumEnd()中加入了一条DbgPrint，用来输出在KiQuantumEnd()中进行修改的线程的状态。难道是这地方IRQL过高了？ IP 地址: 已记录   报告

2008-08-26, 12:59 下午 格蠹老雷 注册: 2005-12-19 发 贴: 1,303 Re: 请教！在win2003内核中加入了些读取系统信息的DbgPrint,出现了以下错误，不知为什么？ 准确说是IRQL高时触发了非法访问，访问了地址2，小于4KB的线性地址都是无效的。 IP 地址: 已记录   报告

2008-08-27, 08:40 上午 pch 注册: 2008-08-26 发 贴: 28 Re: 请教！在win2003内核中加入了些读取系统信息的DbgPrint,出现了以下错误，不知为什么？ 我想在KiQuantumEnd 函数中加入DbgPrint获取一些系统运行信息，但是DbgPrint and DbgPrintEx can be called at IRQL<=DIRQL，DIRQL = 3~26，而KiQuantumEnd is called at DISPATCH level and returns at DISPATCH level. IP 地址: 已记录   报告

2008-08-27, 08:57 上午 王宇 注册: 2007-05-08 发 贴: 306 Re: 请教！在win2003内核中加入了些读取系统信息的DbgPrint,出现了以下错误，不知为什么？ 我只是提醒一下楼主这个例程的IRQL会很高，而蓝的主要问题还是寻址，和 http://advdbg.org/forums/991/ShowPost.aspx 的问题类似。 8087dccc 803800 cmp byte ptr [eax],0 在取指针里的值比较的时候，访问的地址是 READ_ADDRESS: 00000002，所以我问楼主把什么参数传给了DbgPrint，下个断点跟踪一下应该就能找到问题的。 呵呵，线程优先级实验好呀... IP 地址: 已记录   报告

2008-08-27, 11:46 上午 holly 注册: 2008-07-14 发 贴: 22 Re: 请教！在win2003内核中加入了些读取系统信息的DbgPrint,出现了以下错误，不知为什么？ http://advdbg.org/forums/1001/ShowPost.aspx 准确的说和这个帖子的情况类似，也就是我至今未解决的问题。 不过我的例程中断是0x1c，这个是0x1b 我的那个问题似乎是KeAttachProcess引起的，目前还没有想法怎么处理。 IP 地址: 已记录   报告

2008-08-27, 16:32 下午 pch 注册: 2008-08-26 发 贴: 28 Re: 请教！在win2003内核中加入了些读取系统信息的DbgPrint,出现了以下错误，不知为什么？ 我想在KiQuantumEnd 函数中加入DbgPrint获取一些系统运行信息，线程id和状态，但是DbgPrint and DbgPrintEx can be called at IRQL<=DIRQL，DIRQL = 3~26，而KiQuantumEnd is called at DISPATCH level and returns at DISPATCH level. 是不是要改变Irql级别啊，如何改啊？请推荐些资料参考。 IP 地址: 已记录   报告

2008-08-28, 09:22 上午 王宇 注册: 2007-05-08 发 贴: 306 Re: 请教！在win2003内核中加入了些读取系统信息的DbgPrint,出现了以下错误，不知为什么？ 你是在KiQuantumEnd() Release the thread lock 之后加的打印信息吧。 ;) 这时候的IRQL还没有降到DISPATCH level，不知道用DbgPrint()某些参数会不会有问题，我还没实验过。另外，你输出的格式有宽字符吗？用(%wc and %ws)宽字符会蓝的。 我觉得还是要从你出问题的地方下手，这是一寻址问题呀，你看看是什么指针访问了地址00000002。另外是每次都蓝还是偶尔蓝？ IP 地址: 已记录   报告

2008-08-29, 08:23 上午 pch 注册: 2008-08-26 发 贴: 28 Re: 请教！在win2003内核中加入了些读取系统信息的DbgPrint,出现了以下错误，不知为什么？ 首先感谢你的回复。 可能是irql级别的问题，但是不知道怎么修改，下面是我改动的地方。我做的实验是想提取windows运行过程中所有线程的状态变换，除了用DbgPrint来输出信息，有没有其他的办法。 VOID KiQuantumEnd ( VOID ) /*++ Routine Description: This function is called when a quantum end event occurs on the current processor. Its function is to determine whether the thread priority should be decremented and whether a redispatch of the processor should occur. N.B. This function is called at DISPATCH level and returns at DISPATCH level. Arguments: None. Return Value: None. --*/ { PKPRCB Prcb; PKPROCESS Process; PRKTHREAD Thread; PRKTHREAD NewThread; //自定义变量 PEPROCESS DebugEProcess; PKPROCESS DebugKProcess; PETHREAD DebugEThread; extern DebugBegin; // // If DPC thread activation is requested, then set the DPC event. // Prcb = KeGetCurrentPrcb(); Thread = KeGetCurrentThread(); if (InterlockedExchange(&Prcb->DpcSetEventRequest, FALSE) == TRUE) { KeSetEvent(&Prcb->DpcEvent, 0, FALSE); } // // Raise IRQL to SYNCH level, acquire the thread lock, and acquire the // PRCB lock. // // If the quantum has expired for the current thread, then update its // quantum and priority. // KeRaiseIrqlToSynchLevel(); KiAcquireThreadLock(Thread); KiAcquirePrcbLock(Prcb); if (Thread->Quantum ApcState.Process; if ((Process->DisableQuantum != FALSE) && (Thread->Priority >= LOW_REALTIME_PRIORITY)) { Thread->Quantum = MAXCHAR; } else { Thread->Quantum = Thread->QuantumReset; // // Compute the new thread priority and attempt to reschedule the // current processor. // // N.B. The new priority will never be greater than the previous // priority. // Thread->Priority = KiComputeNewPriority(Thread, 1); if (Prcb->NextThread == NULL) { if ((NewThread = KiSelectReadyThread(Thread->Priority, Prcb)) != NULL) { NewThread->State = Standby; Prcb->NextThread = NewThread; } } else { Thread->Preempted = FALSE; } } } // // Release the thread lock. // // If a thread was scheduled for execution on the current processor, then // acquire the PRCB lock, set the current thread to the new thread, set // next thread to NULL, set the thread state to running, release the PRCB // lock, set the wait reason, ready the old thread, and swap context to // the new thread. // KiReleaseThreadLock(Thread); if (Prcb->NextThread != NULL) { KiSetContextSwapBusy(Thread); NewThread = Prcb->NextThread; Prcb->NextThread = NULL; Prcb->CurrentThread = NewThread; NewThread->State = Running; //添加的代码 DebugKProcess = NewThread->ApcState.Process; DebugEThread = CONTAINING_RECORD(NewThread, ETHREAD, Tcb); DebugEProcess = CONTAINING_RECORD(DebugKProcess, EPROCESS, Pcb); if(DebugBegin) DbgPrint("dpcsup.c330 change threadid=0x%x state=%s \n",DebugEThread->Cid.UniqueThread,NewThread->State); Thread->WaitReason = WrQuantumEnd; KxQueueReadyThread(Thread, Prcb); Thread->WaitIrql = APC_LEVEL; KiSwapContext(Thread, NewThread); } else { KiReleasePrcbLock(Prcb); } // // Lower IRQL to DISPATCH level and return. // KeLowerIrql(DISPATCH_LEVEL); return; } IP 地址: 已记录   报告

2008-08-29, 12:06 下午 格蠹老雷 注册: 2005-12-19 发 贴: 1,303 Re: 请教！在win2003内核中加入了些读取系统信息的DbgPrint,出现了以下错误，不知为什么？ State字段是UCHAR类型的: 1: kd> dt KTHREAD -y state nt!KTHREAD +0x05c State : UChar 因此DbgPrint语句中的%s明显是错误的，在前面的蓝屏中，State的值为2，因为%s，DbgPrint将2当作字符串指针来用了，所以在高IRQL导致了一个空指针访问. IP 地址: 已记录   报告

2008-08-29, 13:08 下午 王宇 注册: 2007-05-08 发 贴: 306 Re: 请教！在win2003内核中加入了些读取系统信息的DbgPrint,出现了以下错误，不知为什么？ 嘿嘿 楼主还是16进制打印好了 IP 地址: 已记录   报告

2008-08-29, 15:39 下午 pch 注册: 2008-08-26 发 贴: 28 Re: 请教！在win2003内核中加入了些读取系统信息的DbgPrint,出现了以下错误，不知为什么？ 非常感谢！ 我做的实验是想提取windows运行过程中所有线程的所有状态变换，以及一些中断信息。对于内核调试懂得不多，可否给我推荐些学习的材料。 IP 地址: 已记录   报告

2008-08-29, 17:30 下午 王宇 注册: 2007-05-08 发 贴: 306 Re: 请教！在win2003内核中加入了些读取系统信息的DbgPrint,出现了以下错误，不知为什么？ 我觉得这个领域更多的还是要靠积累。 ^_^ IP 地址: 已记录   报告

总页数 1 第 2 页 [共有 16 条记录] 1 2 >

高端调试 » 软件调试 » Windows内核调试 » 请教！在win2003内核中加入了些读取系统信息的DbgPrint,出现了以下错误，不知为什么？

请选择 论坛首页 |- 论坛搜索 |- 热门主题 |- 未回复的主题 用户选项 |- 登录 |- 注册 |- 找回密码 软件调试 |- 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 |- 游戏开发与调试