Bluescreen

Kalish

Newbie
Registriert
Apr. 2012
Beiträge
2
Ich habe nun schon oft BlueScreens gehabt mit BUGCODE_USB_DRIVER und IRQL_NOT_LESS_OR_EQUAL.
Es gab leider nie MEMORY.DMP und daher habe ich mich hier auch nicht gemeldet, aber nun gerade tadaaaaa:

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


Loading Dump File [E:\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available

Symbol search path is: SRV*C:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17713.x86fre.win7sp1_gdr.111025-1505
Machine Name:
Kernel base = 0x82c47000 PsLoadedModuleList = 0x82d87230
Debug session time: Wed Apr 25 21:22:27.772 2012 (UTC + 2:00)
System Uptime: 0 days 10:09:26.225
WARNING: Process directory table base CA616000 doesn't match CR3 18F23000
WARNING: Unable to reset page directories
Loading Kernel Symbols
...............................................................
................................................................
............................
Loading User Symbols
WARNING: Process directory table base CA616000 doesn't match CR3 18F23000
Unable to get PEB pointer
Loading unloaded module list
.........
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 7F, {d, 0, 0, 0}

Probably caused by : ntkrnlmp.exe ( nt!KiSystemFatalException+f )

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

1: kd> !analyze -v
*******************************************************************************
* *
* 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: 0000000d, EXCEPTION_GP_FAULT
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

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


BUGCHECK_STR: 0x7f_d

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from 82c9c227 to 82c8037b

STACK_TEXT:
bb9caaec 82c9c227 badb0d00 00000000 bb9cab78 nt!KiSystemFatalException+0xf
bb9cab64 82c9bef6 bb9cabb0 899e3b58 80dc5120 nt!SwapContext_XRstorEnd+0x9f
bb9cab78 82ca2d65 899e3b58 80dc8308 80dc5120 nt!KiSwapContext+0x26
bb9cabb0 82ca1bc3 899e3c18 899e3b58 874a5380 nt!KiSwapThread+0x266
bb9cabd8 82ca28b5 899e3b58 899e3c18 0000008e nt!KiCommitThreadWait+0x1df
bb9cac3c 82e450a4 874a5380 02ebfc01 00000000 nt!KeRemoveQueueEx+0x4f8
bb9cac94 82e9ba66 874a5380 bb9caccc bb9cace4 nt!IoRemoveIoCompletion+0x23
bb9cad18 82c7c85a 00000b7c 02ebfc4c 02ebfc40 nt!NtRemoveIoCompletion+0x106
bb9cad18 77577094 00000b7c 02ebfc4c 02ebfc40 nt!KiFastCallEntry+0x12a
WARNING: Frame IP not in any known module. Following frames may be wrong.
02ebfc28 00000000 00000000 00000000 00000000 0x77577094


STACK_COMMAND: kb

FOLLOWUP_IP:
nt!KiSystemFatalException+f
82c8037b c3 ret

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt!KiSystemFatalException+f

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4ea76e9b

FAILURE_BUCKET_ID: 0x7f_d_nt!KiSystemFatalException+f

BUCKET_ID: 0x7f_d_nt!KiSystemFatalException+f

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

WIN7 ist neu drauf und zuvor hatte ich XP, da lief alles super. Ich habe die Vermutung, dass es an meinem WLAN-Stick liegt. Ist ein USRobotics und der hat zu Beginn nicht funktioniert. Habe da auch alles moeliche an Foren durchsucht, aber es gibt keinen ordentlichen treiber fuer WIN7. Habs dann geschafft ihn unter VISTA Einstellungen laufen zu lassen, aber das scheint auch nicht das wahre zu sein...mhhhh


lg
 
Hi, schon mal dann versucht Abgesichert zu Starten und den Treiber mal zu kicken ????
Ergänzung ()

Und ggf. mal Im Bios Datum Uhrzeit prüfen !

Evtl auch mal deine Ram´s überprüfen, da Xp nicht so knausig mit def. Ram´s umgeht ;)
 
Zuletzt bearbeitet:
RAM habe ich ueberprueft, da scheint alles okay zu sein. Jaja ich denke, dass ist echt der dumme Treiber+Stick. :P

Danke aber soweit. ;)

lg
 
Parameter1: 0x0000000D, eine Schutzverletzung die zu einer Zugriffsverletzung fuehrt.
Wenn du schon WinDbg anwirfst, warum dann auf dem 1/4 des Weges stehenbleiben?
Im Textteil von !analyze -v steht ja ein Hinweis:

Debugging: Always begin with the !analyze extension.
If this extension is not sufficient, use the kv (Display Stack Backtrace) debugger command.
* If kv shows a taskGate, use the .tss (Display Task State Segment) command on the part before the colon.
* If kv shows a trap frame, use the .trap (Display Trap Frame) command to format the frame.
* Otherwise, use the .trap (Display Trap Frame) command on the appropriate frame.
(On x86-based platforms, this frame is associated with the procedure NT!KiTrap.)

After using one of these commands, use kv again to display the new stack.
 
Zurück
Oben