Gå til innhold

BSOD (Blue Screen) Forhåpentligvis løst


Anbefalte innlegg

Hei.

 

Har en server som tryner alt for ofte. Jeg har kjørt en minnedump og analyse, men kan ikke si jeg skjønner stort. Noen som skjønner mer enn meg? ;) Her er minnedumpen:

 

 

 

Microsoft ® Windows Debugger Version 6.6.0007.5

Copyright © Microsoft Corporation. All rights reserved.

 

 

Loading Dump File [c:\memdump\Mini100807-01.dmp]

Mini Kernel Dump File: Only registers and stack trace are available

 

Symbol search path is: srv*c:\symbols*http://msdl.microsoft.com/download/symbols

Executable search path is: c:\i386

Windows Server 2003 Kernel Version 3790 (Service Pack 2) MP (2 procs) Free x86 compatible

Product: LanManNt, suite: TerminalServer SingleUserTS

Built by: 3790.srv03_sp2_gdr.070304-2240

Kernel base = 0x80800000 PsLoadedModuleList = 0x808af9c8

Debug session time: Mon Oct 8 02:24:56.785 2007 (GMT+2)

System Uptime: 1 days 9:09:28.240

Loading Kernel Symbols

..........................................................................................

....................

Loading User Symbols

Loading unloaded module list

..

Unable to load image msiscsi.sys, Win32 error 2

*** WARNING: Unable to verify timestamp for msiscsi.sys

*** ERROR: Module load completed but symbols could not be loaded for msiscsi.sys

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

 

Use !analyze -v to get detailed debugging information.

 

BugCheck 100000D1, {d606f0e, d0000002, 1, ba638405}

 

Unable to load image tm_cfw.sys, Win32 error 2

*** WARNING: Unable to verify timestamp for tm_cfw.sys

*** ERROR: Module load completed but symbols could not be loaded for tm_cfw.sys

*** WARNING: Unable to verify timestamp for e1000325.sys

*** ERROR: Module load completed but symbols could not be loaded for e1000325.sys

Probably caused by : msiscsi.sys ( msiscsi+4405 )

 

Followup: MachineOwner

---------

 

0: kd> !analyze -v

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

 

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)

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 kernel debugger is available get stack backtrace.

Arguments:

Arg1: 0d606f0e, memory referenced

Arg2: d0000002, IRQL

Arg3: 00000001, value 0 = read operation, 1 = write operation

Arg4: ba638405, address which referenced memory

 

Debugging Details:

------------------

 

 

WRITE_ADDRESS: 0d606f0e

 

CURRENT_IRQL: 2

 

FAULTING_IP:

msiscsi+4405

ba638405 10803e010f85 adc byte ptr [eax-7AF0FEC2h],al

 

CUSTOMER_CRASH_COUNT: 1

 

DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP

 

BUGCHECK_STR: 0xD1

 

PROCESS_NAME: Idle

 

LAST_CONTROL_TRANSFER: from 8083ffb5 to ba638405

 

STACK_TEXT:

WARNING: Stack unwind information not available. Following frames may be wrong.

808a33f0 8083ffb5 00000000 00000000 87fa2008 msiscsi+0x4405

808a3420 ba35fb41 87d28170 87c76710 89055ad8 nt!IopfCompleteRequest+0xcd

808a3438 ba369627 8859cab0 00000000 00000030 tcpip!TCPDataRequestComplete+0xa6

808a345c ba36276a 00000000 89055a70 00000000 tcpip!TCPSendComplete+0x151

808a3494 ba36161b 890d8658 009b5c18 00000000 tcpip!IPSendComplete+0x126

808a34b8 b9488b3f 8906a008 879b5c18 00000000 tcpip!ARPSendComplete+0x108

808a3500 ba91f996 89972ab0 879b5c18 00000000 tm_cfw+0x6b3f

808a3518 ba91ffa8 808a3538 879b5c18 00000000 e1000325+0x996

808a3530 ba924ece 89a09e78 879b5c18 00000000 e1000325+0xfa8

808a3554 ba9245c7 89442008 879b5c18 808a3580 e1000325+0x5ece

808a3588 ba91f56a 00442008 f7235466 89a09e78 e1000325+0x55c7

808a35a8 8083d99a 89442394 89442380 00000000 e1000325+0x56a

808a3600 80839b2f 00000000 0000000e 00000000 nt!KiRetireDpcList+0xca

808a3604 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x37

 

 

STACK_COMMAND: kb

 

FOLLOWUP_IP:

msiscsi+4405

ba638405 10803e010f85 adc byte ptr [eax-7AF0FEC2h],al

 

SYMBOL_STACK_INDEX: 0

 

FOLLOWUP_NAME: MachineOwner

 

MODULE_NAME: msiscsi

 

IMAGE_NAME: msiscsi.sys

 

DEBUG_FLR_IMAGE_TIMESTAMP: 41939183

 

SYMBOL_NAME: msiscsi+4405

 

FAILURE_BUCKET_ID: 0xD1_W_msiscsi+4405

 

BUCKET_ID: 0xD1_W_msiscsi+4405

 

Followup: MachineOwner

 

/greigutt

Endret av greigutt
Lenke til kommentar
Videoannonse
Annonse

Ser at det er iscsi initiator tjenesten som svikter i dette tilfellet (msiscsi.sys).. Bruker dere Iscsi (sentral lagring) ?

Eller er det andre systemfiler den svikter på andre ganger?

 

Om det er samme filen som svikter hver gang, prøv å stenge ned denne tjenesten (ev. avinstallere ms iscsi initiatoren)

 

Kan det være en ressurskonflikt? (nic eller eventuell iscsi hba)

 

DRIVER_IRQL_NOT_LESS_OR_EQUAL pleier å være ustabile drivere eller maskinvare.. (minnebrikker??)

Lenke til kommentar

Bruker iscsi ja...

 

Jeg ser at msiscsi.sys er gammel (Type år 2004), men har en identisk server med samme oppsett som ikke sliter.... Jeg har lyst til å reinstallere iscsi initiatoren ja, men tør ikke da jeg ikke har passord til iscsikabinettet... Når er det egentligl man trenger dette? ;)

 

Jeg skal sjekke flere .dmp-filer imorgen, for å se om det er samme hver gang, kom aldri så langt idag... Jeg tipper også det er driverproblemer, må bare finne ut hvilke (er jo nærliggende å tro det er msiscsi, men siden den andre serveren kjører greit så blir jeg i tvil)

 

Bare å komme med flere innspill eller spørsmål ;)

 

/greigutt

Lenke til kommentar
  • 2 uker senere...

Hei igjen.

 

Har nå oppdatert server med IBMs nyeste Update Xpress (drivere, firmware og bios), har fått to ulike stop errors etter dette, men begge er DRIVER_IRQL_NOT_LESS_OR_EQUAL, så jeg vil tro det er drivere, minne eller disk. Kjører IBMs diagnoseverktøy nå, og memtest86 står for tur.

 

Tenkte bare jeg skulle oppdatere tråden på hva jeg har gjort. Det er bare å komme med innspill! ;)

 

/greigutt

Lenke til kommentar
  • 3 uker senere...

Man lærer så lenge man lever, jeg kjørte diagnose av de ørten siste bsodene, og veldig mange av de gikk på tcpip og noen trend.sys-filer. Oppdaterte nettverkskortdriverne og fjerna antivirus, nå har serveren 2 uker oppetid motfor 2-3 dager tidligere....

 

I tillegg gikk backup cånn ca akkurat dobbelt så fort uten antivirus.....

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...