Garnostay, так же, как вы.
Кстати, полный текст с опцией
-v
Код:
Kernel Summary Dump File: Only kernel address space is available
Symbol search path is: srv*E:\Symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: srv*E:\Symbols*http://msdl.microsoft.com/download/symbols
Windows Server 2003 Kernel Version 3790 (Service Pack 2) MP (4 procs) Free x86 compatible
Product: Server, suite: Enterprise TerminalServer SingleUserTS
Built by: 3790.srv03_sp2_gdr.100216-1301
Kernel base = 0x80800000 PsLoadedModuleList = 0x808af9c8
Debug session time: Thu Jan 20 01:28:47.850 2011 (GMT+3)
System Uptime: 26 days 23:41:30.296
WARNING: Process directory table base 132E1000 doesn't match CR3 00039000
WARNING: Process directory table base 132E1000 doesn't match CR3 00039000
Loading Kernel Symbols
...........................................................................................................
Loading User Symbols
PEB is paged out (Peb.Ldr = 7ffdd00c). Type ".hh dbgerr001" for details
Loading unloaded module list
....
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 7F, {8, 80042000, 0, 0}
*** ERROR: Module load completed but symbols could not be loaded for grdkey.sys
Probably caused by : grdkey.sys ( grdkey+1fd03 )
Followup: MachineOwner
---------
0: kd> kd: Reading initial command '!analyze -v; q'
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
Arg2: 80042000
Arg3: 00000000
Arg4: 00000000
Debugging Details:
------------------
BUGCHECK_STR: 0x7f_8
TSS: 00000028 -- (.tss 0x28)
eax=0000038c ebx=af12e320 ecx=af12e30c edx=00000000 esi=00000013 edi=00000013
eip=8083dd59 esp=af12df54 ebp=af12e2f0 iopl=0 nv up ei ng nz ac po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010292
nt!_SEH_prolog+0x1a:
8083dd59 53 push ebx
Resetting default scope
DEFAULT_BUCKET_ID: DRIVER_FAULT
PROCESS_NAME: grdsrv.exe
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 808346cc to 8083dd59
STACK_TEXT:
af12e2f0 808346cc af12e30c 00000000 af12e360 nt!_SEH_prolog+0x1a
af12e358 80834680 af130b48 b9e3b068 badb0d00 nt!CommonDispatchException+0x4a
af12e3d4 b9e42d03 00000000 af130b48 b9e438d0 nt!Kei386EoiHelper+0x186
WARNING: Stack unwind information not available. Following frames may be wrong.
af130c3c 80840153 893365d0 84ee2a08 88393af0 grdkey+0x1fd03
af130b80 001ee792 88cf9c98 00000001 afaaebc9 nt!IofCallDriver+0x45
af130c3c 80840153 893365d0 84ee2a08 88393af0 0x1ee792
af130c24 0029ae64 893365d0 84ee2a08 89336688 nt!IofCallDriver+0x45
af130c3c 80840153 893365d0 84ee2a08 88393af0 0x29ae64
af130c50 8092b57f 84ee2a9c 88393af0 84ee2a08 nt!IofCallDriver+0x45
af130c64 8092b4b4 893365d0 84ee2a08 88393af0 nt!IopSynchronousServiceTail+0x10b
af130d00 8092b5d4 000003e4 00000000 00000000 nt!IopXxxControlFile+0x60f
af130d34 80833bef 000003e4 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
af130d34 7c93860c 000003e4 00000000 00000000 nt!KiFastCallEntry+0xfc
01eee098 00000000 00000000 00000000 00000000 0x7c93860c
STACK_COMMAND: .tss 0x28 ; kb
FOLLOWUP_IP:
grdkey+1fd03
b9e42d03 5b pop ebx
SYMBOL_STACK_INDEX: 3
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: grdkey
IMAGE_NAME: grdkey.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 49a663e9
SYMBOL_NAME: grdkey+1fd03
FAILURE_BUCKET_ID: 0x7f_8_grdkey+1fd03
BUCKET_ID: 0x7f_8_grdkey+1fd03
Теперь понятно: в минидампах стек был пустой (потому и причина не видна).
