|
阅读：5271回复：14
还是diskperf的问题,一启动就蓝屏
操作系统: win xp
ddk版本:windows_server_2003_sp1_ddk 我编译了里面的diskperf,并用inf安装,重启的时候就是蓝屏.请帮忙看下,谢谢了. 另:我另外一台win7机器,用的win7 ddk,一样有蓝屏这个问题, 可是我搜索论坛,就没发现有人说系统启动的时候蓝屏呀 用windbg调试,输出如下: *** Fatal System Error: 0x0000007b (0xF8901528,0xC0000034,0x00000000,0x00000000) 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 XP 2600 x86 compatible target at (Tue Sep 14 15:58:31.975 2010 (GMT+8)), ptr64 FALSE *** ERROR: Symbol file could not be found. Defaulted to export symbols for ntkrnlpa.exe - Loading Kernel Symbols .............................. Loading User Symbols ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 7B, {f8901528, c0000034, 0, 0} ***** Kernel symbols are WRONG. Please fix symbols to do analysis. ************************************************************************* *** *** *** *** *** Your debugger is not using the correct symbols *** *** *** *** In order for this command to work properly, your symbol path *** *** must point to .pdb files that have full type information. *** *** *** *** Certain .pdb files (such as the public OS symbols) do not *** *** contain the required information. Contact the group that *** *** provided you with these symbols if you need this command to *** *** work. *** *** *** *** Type referenced: nt!_KPRCB *** *** *** ************************************************************************* ************************************************************************* *** *** *** *** *** Your debugger is not using the correct symbols *** *** *** *** In order for this command to work properly, your symbol path *** *** must point to .pdb files that have full type information. *** *** *** *** Certain .pdb files (such as the public OS symbols) do not *** *** contain the required information. Contact the group that *** *** provided you with these symbols if you need this command to *** *** work. *** *** *** *** Type referenced: nt!_KPRCB *** *** *** ************************************************************************* Probably caused by : ntkrnlpa.exe ( nt!KeRegisterBugCheckReasonCallback+77c ) Followup: MachineOwner --------- nt!DbgBreakPointWithStatus+0x4: 80528c0c cc int 3 |
|
禁止发言
|
沙发#
发布于：2010-09-14 16:30
用户被禁言,该主题自动屏蔽! |
|
板凳#
发布于：2010-09-14 17:29
谢谢关注
我就是用原版的inf安装的,注册表也看了下,没什么异常,下面是!analyze -v输出 ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* INACCESSIBLE_BOOT_DEVICE (7b) During the initialization of the I/O system, it is possible that the driver for the boot device failed to initialize the device that the system is attempting to boot from, or it is possible for the file system that is supposed to read that device to either fail its initialization or to simply not recognize the data on the boot device as a file system structure that it recognizes. In the former case, the argument (#1) is the address of a Unicode string data structure that is the ARC name of the device from which the boot was being attempted. In the latter case, the argument (#1) is the address of the device object that could not be mounted. If this is the initial setup of the system, then this error can occur if the system was installed on an unsupported disk or SCSI controller. Note that some controllers are supported only by drivers which are in the Windows Driver Library (WDL) which requires the user to do a custom install. See the Windows Driver Library for more information. This error can also be caused by the installation of a new SCSI adapter or disk controller or repartitioning the disk with the system partition. If this is the case, on x86 systems the boot.ini file must be edited or on ARC systems setup must be run. See the "Advanced Server System Administrator's User Guide" for information on changing boot.ini. If the argument is a pointer to an ARC name string, then the format of the first two (and in this case only) longwords will be: USHORT Length; USHORT MaximumLength; PWSTR Buffer; That is, the first longword will contain something like 00800020 where 20 is the actual length of the Unicode string, and the next longword will contain the address of buffer. This address will be in system space, so the high order bit will be set. If the argument is a pointer to a device object, then the format of the first word will be: USHORT Type; That is, the first word will contain a 0003, where the Type code will ALWAYS be 0003. Note that this makes it immediately obvious whether the argument is a pointer to an ARC name string or a device object, since a Unicode string can never have an odd number of bytes, and a device object will always have a Type code of 3. Arguments: Arg1: f89c5528, Pointer to the device object or Unicode string of ARC name Arg2: c0000034 Arg3: 00000000 Arg4: 00000000 Debugging Details: ------------------ ***** Kernel symbols are WRONG. Please fix symbols to do analysis. ************************************************************************* *** *** *** *** *** Your debugger is not using the correct symbols *** *** *** *** In order for this command to work properly, your symbol path *** *** must point to .pdb files that have full type information. *** *** *** *** Certain .pdb files (such as the public OS symbols) do not *** *** contain the required information. Contact the group that *** *** provided you with these symbols if you need this command to *** *** work. *** *** *** *** Type referenced: nt!_KPRCB *** *** *** ************************************************************************* ************************************************************************* *** *** *** *** *** Your debugger is not using the correct symbols *** *** *** *** In order for this command to work properly, your symbol path *** *** must point to .pdb files that have full type information. *** *** *** *** Certain .pdb files (such as the public OS symbols) do not *** *** contain the required information. Contact the group that *** *** provided you with these symbols if you need this command to *** *** work. *** *** *** *** Type referenced: nt!_KPRCB *** *** *** ************************************************************************* ADDITIONAL_DEBUG_TEXT: Use '!findthebuild' command to search for the target build information. If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols. MODULE_NAME: nt FAULTING_MODULE: 804d8000 nt DEBUG_FLR_IMAGE_TIMESTAMP: 4bd6e0e9 DEFAULT_BUCKET_ID: DRIVER_FAULT BUGCHECK_STR: 0x7B LAST_CONTROL_TRANSFER: from 804f979a to 80528c0c STACK_TEXT: WARNING: Stack unwind information not available. Following frames may be wrong. f89c50dc 804f979a 00000003 00000000 80087000 nt!DbgBreakPointWithStatus+0x4 f89c54bc 804f9cc5 0000007b f89c5528 c0000034 nt!KeRegisterBugCheckReasonCallback+0x77c f89c54dc 80687fe9 0000007b f89c5528 c0000034 nt!KeBugCheckEx+0x1b f89c5644 8068c10a 80087000 00000000 80087000 nt!NlsOemLeadByteInfo+0x14d49 f89c5694 80688e48 80087000 f89c56b0 00043000 nt!IoReportHalResourceUsage+0x1cc2 f89c583c 806872dd 80087000 00000000 82db95b8 nt!NlsOemLeadByteInfo+0x15ba8 f89c5dac 805c71e0 80087000 00000000 00000000 nt!NlsOemLeadByteInfo+0x1403d f89c5ddc 80542e12 80686928 80087000 00000000 nt!PsRemoveCreateThreadNotifyRoutine+0x21e 00000000 00000000 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x5a2 STACK_COMMAND: kb FOLLOWUP_IP: nt!KeRegisterBugCheckReasonCallback+77c 804f979a e8f1710000 call nt!ZwYieldExecution+0x630 (80500990) SYMBOL_STACK_INDEX: 1 SYMBOL_NAME: nt!KeRegisterBugCheckReasonCallback+77c FOLLOWUP_NAME: MachineOwner IMAGE_NAME: ntkrnlpa.exe BUCKET_ID: WRONG_SYMBOLS Followup: MachineOwner --------- |
|
|
地板#
发布于：2010-09-15 10:07
哪位大牛帮行给看看吧,谢谢了.
|
|
|
地下室#
发布于：2010-09-15 21:12
经过一点点的屏蔽,找到了表面原因:
DriverObject->MajorFunction[IRP_MJ_POWER] = DiskPerfDispatchPower; 把这行屏蔽了就行了,但是关机的时候总蓝屏 上面那行应该是处理关机消息的吧,是不是因为屏蔽这个处理导致关机蓝屏? 另外: 驱动已经加载起来了,但是看不到debug信息输出呀,这个是为什么? 还需要用addfilter吗?用过的帮忙告诉下,谢谢了 .出错部分我可以慢慢调,起码先看到效果. |
|
|
5楼#
发布于：2010-09-15 22:31
输出的问题解决了,现在需要取两个值:
currentIrpStack->Parameters.ReadWriteConfig.Offset,currentIrpStack->Parameters.ReadWriteConfig.Length 但是结构里面,currentIrpStack->Parameters是 <unnamed-tag>,继续研究 |
|
|
6楼#
发布于：2010-09-16 14:01
做了如下输出,结果根本对不上偏移和长度.......................
if(partitionCounters != NULL&&IRP_MJ_WRITE == currentIrpStack->MajorFunction) { DebugPrint(( 1001,L"Device %ws Offset=%I64u Length= %I32u diskoffset= %I64u VolumeIndex= %I32u", deviceExtension->PhysicalDeviceNameBuffer, currentIrpStack->Parameters.Write.ByteOffset, currentIrpStack->Parameters.Write.Length, currentIrpStack->Parameters.Write.ByteOffset.QuadPart, Irp->IoStatus.Pointer )); |
|
|
7楼#
发布于：2010-09-17 11:34
ULONGLONG aaa1=currentIrpStack->Parameters.Write.ByteOffset.QuadPart;
ULONG aaa2=currentIrpStack->Parameters.Write.Length; 这两个值怎么一直是变大啊,这里是不是读写偏移和长度? |
|
|
8楼#
发布于：2010-09-17 14:34
你最好找当前版本的wdk中的例子测试，看例子的说明，通常是可以安装的，如果货不对版就不好说了．具体的dump分析要和符号，源码对上，直接帖个analyze -v 作用不大，不好判断
|
|
|
|
9楼#
发布于：2010-11-01 10:59
高手们有没有时间看看我这个啊？
非常的郁闷~ *** Fatal System Error: 0x0000007b (0xFAC24528,0xC0000034,0x00000000,0x00000000) 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 XP 2600 x86 compatible target at (Mon Nov 1 10:53:37.843 2010 (GMT+8)), ptr64 FALSE Loading symbols for 804d8000 ntkrnlpa.exe -> ntkrnlpa.exe ModLoad: 804d8000 806d0480 ntkrnlpa.exe Loading Kernel Symbols .ModLoad: 806d1000 806f1300 halaacpi.dll .ModLoad: facfd000 facfeb80 kdcom.dll .ModLoad: fac0d000 fac10000 \WINDOWS\system32\BOOTVID.dll .ModLoad: fa6ce000 fa6fb500 ACPI.sys .ModLoad: facff000 fad00100 \WINDOWS\system32\DRIVERS\WMILIB.SYS .ModLoad: fa6bd000 fa6cd280 pci.sys .ModLoad: fa7fd000 fa805d80 isapnp.sys Unable to read image header at fac11000 .ModLoad: fac11000 fac14000 compbatt.sys -- User interrupt ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 7B, {fac24528, c0000034, 0, 0} Probably caused by : ntkrnlpa.exe ( nt!IopMarkBootPartition+f5 ) Followup: MachineOwner --------- nt!RtlpBreakWithStatusInstruction: 80528bdc cc int 3 kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* INACCESSIBLE_BOOT_DEVICE (7b) During the initialization of the I/O system, it is possible that the driver for the boot device failed to initialize the device that the system is attempting to boot from, or it is possible for the file system that is supposed to read that device to either fail its initialization or to simply not recognize the data on the boot device as a file system structure that it recognizes. In the former case, the argument (#1) is the address of a Unicode string data structure that is the ARC name of the device from which the boot was being attempted. In the latter case, the argument (#1) is the address of the device object that could not be mounted. If this is the initial setup of the system, then this error can occur if the system was installed on an unsupported disk or SCSI controller. Note that some controllers are supported only by drivers which are in the Windows Driver Library (WDL) which requires the user to do a custom install. See the Windows Driver Library for more information. This error can also be caused by the installation of a new SCSI adapter or disk controller or repartitioning the disk with the system partition. If this is the case, on x86 systems the boot.ini file must be edited or on ARC systems setup must be run. See the "Advanced Server System Administrator's User Guide" for information on changing boot.ini. If the argument is a pointer to an ARC name string, then the format of the first two (and in this case only) longwords will be: USHORT Length; USHORT MaximumLength; PWSTR Buffer; That is, the first longword will contain something like 00800020 where 20 is the actual length of the Unicode string, and the next longword will contain the address of buffer. This address will be in system space, so the high order bit will be set. If the argument is a pointer to a device object, then the format of the first word will be: USHORT Type; That is, the first word will contain a 0003, where the Type code will ALWAYS be 0003. Note that this makes it immediately obvious whether the argument is a pointer to an ARC name string or a device object, since a Unicode string can never have an odd number of bytes, and a device object will always have a Type code of 3. Arguments: Arg1: fac24528, Pointer to the device object or Unicode string of ARC name Arg2: c0000034 Arg3: 00000000 Arg4: 00000000 Debugging Details: ------------------ DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO BUGCHECK_STR: 0x7B PROCESS_NAME: System LAST_CONTROL_TRANSFER: from 804f8b9d to 80528bdc STACK_TEXT: fac24090 804f8b9d 00000003 fac243ec 00000000 nt!RtlpBreakWithStatusInstruction fac240dc 804f978a 00000003 00000000 80087000 nt!KiBugCheckDebugBreak+0x19 fac244bc 804f9cb5 0000007b fac24528 c0000034 nt!KeBugCheck2+0x574 fac244dc 80687ce9 0000007b fac24528 c0000034 nt!KeBugCheckEx+0x1b fac24644 8068be0a 80087000 00000000 80087000 nt!IopMarkBootPartition+0xf5 fac24694 80688b48 80087000 fac246b0 00043000 nt!IopInitializeBootDrivers+0x4ba fac2483c 80686fdd 80087000 00000000 80f1cda8 nt!IoInitSystem+0x712 fac24dac 805c7160 80087000 00000000 00000000 nt!Phase1Initialization+0x9b5 fac24ddc 80542dd2 80686628 80087000 00000000 nt!PspSystemThreadStartup+0x34 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16 STACK_COMMAND: kb FOLLOWUP_IP: nt!IopMarkBootPartition+f5 80687ce9 8d85e0feffff lea eax,[ebp-120h] SYMBOL_STACK_INDEX: 4 SYMBOL_NAME: nt!IopMarkBootPartition+f5 FOLLOWUP_NAME: MachineOwner MODULE_NAME: nt IMAGE_NAME: ntkrnlpa.exe DEBUG_FLR_IMAGE_TIMESTAMP: 4802516a FAILURE_BUCKET_ID: 0x7B_nt!IopMarkBootPartition+f5 BUCKET_ID: 0x7B_nt!IopMarkBootPartition+f5 Followup: MachineOwner --------- |
|
|
|
10楼#
发布于：2010-11-01 11:02
用的diskperf想做个透明加密。安装用的DDK里面的inf。
上面的那个东西完全的搞不懂什么意思~ 编译环境是xp+IFS kit and DDK3790。 |
|
|
|
11楼#
发布于：2010-11-11 17:40
 还是搞不懂啊~~~ "牛人们都忙得很呢~~~~ |
|
|
|
12楼#
发布于：2010-11-24 13:13
你把你的driver设置成Boot类型了吗
------------------------------------------------------------------ 帆子内核驱动网 bbs.kerneldev.com |
|
|
|
13楼#
发布于：2011-03-08 09:32
不知道我的情况，是否跟你一样。我用的WDK7600下的WIN7 check编译的，得到的sys放到WXP sp3系统中运行，启动的时候，跟你一样蓝屏，windbg分析的结果也是一样的。根据你的提示是IRP_MJ_POWER这个功能号对应的派遣函数的问题，我在里面发现一点点东西：
Power请求可以直接下发给下层设备处理的。 但是在vista系统以前下发是用PoCallDriver的，vista以后变简单了，直接使用IoCallDriver就OK。diskperf中使用的是一个宏NTDDI_VERSION来判断当前的驱动版本的。 我猜测蓝屏的原因是：用了win7 check版本来编译驱动，自然编译后，驱动采用的是IoCallDriver的方式下发。得到的驱动放到XP下运行，自然会蓝屏。 改用XP check版本编译后，放XP下运行，驱动就正常了。 小菜鸟，猜测蓝屏的原因，就是上面的那个原因。 希望高手能点拨下，因为只测试了1个，不能说明这个理由就是正确的。 |
|
|
14楼#
发布于：2011-03-09 15:54
回 13楼(yvqvan) 的帖子
多谢，可能是这个原因，我用2003的编译看看。 |
|