Re: 有意触发蓝屏

老专家如何破解新问题

有意触发蓝屏

---

土豆泥 2006-06-01, 21:51 下午

在XP及以前的Windows，产生一个蓝屏可以说是信手拈来，可以Kill掉CSRSS、LSASS等任一个系统进程，或者使用WinDbg的本地内核调试。

到了Vista，尝试Kill，得到权限不够的错误。尝试本地内核调试，不再支持了！！！

略微思考一下，通过Run as administrator启动cmd窗口，然后再用kill命令就成了。但是本地内核调试到底支持与否还有待考证。

 

Re: 有意触发蓝屏

---

skyworth 2008-07-29, 20:40 下午
ntds -p pid -c q应该也可以的。

Re: 有意触发蓝屏

---

skyworth 2008-07-29, 20:41 下午
然后Sysinternals Suite的Winobj在我的机器上每次启动必挂，哇咔咔，想调试一下看看什么原因，居然虚拟内存不足，缺页。。。。。。

Re: 有意触发蓝屏

---

王宇 2008-07-30, 08:41 上午
我觉得比较有趣的蓝屏触发代码是：

__asm lock nop

或者 lock sti 等等。

关于它的原理十分值得讨论，这牵涉到同步、地址交换操作、多核安全等诸多问题，说白了就是 Intel 手册第七章。

另 WinOBJ 蓝什么原因？传个 dump 我看看？

Re: 有意触发蓝屏

---

小喂 2008-08-01, 09:43 上午

tudouni wrote:

在XP及以前的Windows，产生一个蓝屏可以说是信手拈来，可以Kill掉CSRSS、LSASS等任一个系统进程，或者使用WinDbg的本地内核调试。 到了Vista，尝试Kill，得到权限不够的错误。尝试本地内核调试，不再支持了！！！ 略微思考一下，通过Run as administrator启动cmd窗口，然后再用kill命令就成了。但是本地内核调试到底支持与否还有待考证。

vista 上的本机内核调试，可以试试我写的 vistalkd 工具。呵呵！
http://hi.baidu.com/xiaoweitech/blog/item/2a344ddd735aa2315982dd58.html

Re: 有意触发蓝屏

---

skyworth 2008-08-01, 23:51 下午
我试试看吧，Mini Dump关键页缺失， Full Dump又太大。

Re: 有意触发蓝屏

---

skyworth 2008-08-02, 00:10 上午
先看看Windbg的CrashDump analyze report。

Microsoft (R) Windows Debugger Version 6.9.0003.113 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\WINDOWS\Minidump\Mini080208-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: srv*D:\SymbolsCache*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows Server 2003 Kernel Version 3790 (Service Pack 2) MP (2 procs) Free x86 compatible
Product: Server, suite: Enterprise TerminalServer SingleUserTS
Built by: 3790.srv03_sp2_gdr.070304-2240
Kernel base = 0x80800000 PsLoadedModuleList = 0x808a6ea8
Debug session time: Sat Aug 2 00:00:21.375 2008 (GMT+8)
System Uptime: 0 days 4:17:15.116
Loading Kernel Symbols
..............................................................................................................
Loading User Symbols
Loading unloaded module list
...............
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1000008E, {c0000005, 809366d2, b84b633c, 0}

Probably caused by : ntkrpamp.exe ( nt!NtQueryDirectoryObject+1a2 )

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

1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 809366d2, The address that the exception occurred at
Arg3: b84b633c, Trap Frame
Arg4: 00000000

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


EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - "0x%08lx"

FAULTING_IP:
nt!NtQueryDirectoryObject+1a2
809366d2 8a460c mov al,byte ptr [esi+0Ch]

TRAP_FRAME: b84b633c -- (.trap 0xffffffffb84b633c)
ErrCode = 00000000
eax=00000001 ebx=e5659008 ecx=0000000e edx=00000011 esi=10ec83d4 edi=f7728820
eip=809366d2 esp=b84b63b0 ebp=b84b6430 iopl=0 nv up ei pl nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010206
nt!NtQueryDirectoryObject+0x1a2:
809366d2 8a460c mov al,byte ptr [esi+0Ch] ds:0023:10ec83e0=??
Resetting default scope

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP

BUGCHECK_STR: 0x8E

PROCESS_NAME: Winobj.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 8088978c to 809366d2

STACK_TEXT:
b84b6430 8088978c 0000011c 0012dc04 00000800 nt!NtQueryDirectoryObject+0x1a2
b84b6430 7c9585ec 0000011c 0012dc04 00000800 nt!KiFastCallEntry+0xfc
WARNING: Frame IP not in any known module. Following frames may be wrong.
001788e8 00000000 00000000 00000000 00000000 0x7c9585ec


STACK_COMMAND: kb

FOLLOWUP_IP:
nt!NtQueryDirectoryObject+1a2
809366d2 8a460c mov al,byte ptr [esi+0Ch]

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt!NtQueryDirectoryObject+1a2

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrpamp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 45ec0a19

FAILURE_BUCKET_ID: 0x8E_nt!NtQueryDirectoryObject+1a2

BUCKET_ID: 0x8E_nt!NtQueryDirectoryObject+1a2

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

看上去好像是系统内核模块里面有一个hard code的断点在里面，但是系统不是以调试模式启动的。
另外，给我你的邮件地址，我给你一个mini dump。