Jump to content

Bluescreen mit nichts-sagendem Speicher-DMP...


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo,

 

wir haben seit Beginn BLuescreens auf einem Server...verbessert hatte sich die Situation, nachdem der Treiber für einen internen Adaptec (Bandlaufwerk) upgedatet wurde...drauf war eine MS Version aus 2002..nun ists ein Treiber aus 2004.

 

Es war ein paar Wochen Ruhe: letzte Woche jedoch wieder ein Absturz. Der Dump gibt keinen Hinweis auf eine beteiligte Treiberdatei, aber ggf. könt ihr mir beim Suchen helfen:

 

Microsoft ® Windows Debugger Version 6.4.0007.2

Copyright © Microsoft Corporation. All rights reserved.

Loading Dump File [C:\Dokumente und Einstellungen\Administrator\Desktop\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:

*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntkrpamp.exe -

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

Product: LanManNt, suite: SmallBusiness TerminalServer SmallBusinessRestricted SingleUserTS

Built by: 3790.srv03_sp2_gdr.070304-2240

Kernel base = 0x80800000 PsLoadedModuleList = 0x808a6ea8

Debug session time: Fri Apr 18 22:53:33.756 2008 (GMT+2)

System Uptime: 1 days 21:40:34.140

*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntkrpamp.exe -

Loading Kernel Symbols

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

Loading unloaded module list

..

Loading User Symbols

PEB is paged out (Peb.Ldr = 7ffdc00c). Type ".hh dbgerr001" for details

...

BugCheck C5, {0, d0000002, 1, 808921dd}

 

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

...

Followup: MachineOwner

---------

 

0: kd> !analyze -v

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

* *

* Bugcheck Analysis *

* *

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

 

DRIVER_CORRUPTED_EXPOOL (c5)

An attempt was made to access a pageable (or completely invalid) address at an

interrupt request level (IRQL) that is too high. This is

caused by drivers that have corrupted the system pool. Run the driver

verifier against any new (or suspect) drivers, and if that doesn't turn up

the culprit, then use gflags to enable special pool.

Arguments:

Arg1: 00000000, memory referenced

Arg2: d0000002, IRQL

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

Arg4: 808921dd, address which referenced memory

 

Debugging Details:

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

 

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

...

MODULE_NAME: nt

 

FAULTING_MODULE: 80800000 nt

 

DEBUG_FLR_IMAGE_TIMESTAMP: 45ec0a19

 

BUGCHECK_STR: 0xC5_D0000002

 

CURRENT_IRQL: d0000002

 

FAULTING_IP:

nt!RtlCaptureContext+341d

808921dd 8937 mov [edi],esi

 

DEFAULT_BUCKET_ID: DRIVER_FAULT

 

LAST_CONTROL_TRANSFER: from 808921dd to 8088c963

 

STACK_TEXT:

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

b83b788c 808921dd badb0d00 8b310c88 00000000 nt!Kei386EoiHelper+0x28d3

b83b7938 808928c3 808aeae0 8a0423c0 00000000 nt!RtlCaptureContext+0x341d

b83b7990 80938fcf 888d9da8 00000000 b83b7c80 nt!ExFreePoolWithTag+0x57f

b83b7bf4 809390ca 00000019 b83b7c1c 00000001 nt!NtWaitForSingleObject+0x35d

b83b7d48 8088978c 00000019 00159070 00000001 nt!NtWaitForSingleObject+0x458

b83b7d64 7c9485ec badb0d00 0012f74c 00000000 nt!KeReleaseInStackQueuedSpinLockFromDpcLevel+0xb64

0012f7ec 00000000 00000000 00000000 00000000 0x7c9485ec

 

 

STACK_COMMAND: .bugcheck ; kb

 

FOLLOWUP_NAME: MachineOwner

 

BUCKET_ID: WRONG_SYMBOLS

 

Followup: MachineOwner

---------

Link zu diesem Kommentar

Hallo,

 

hab nun noch das Symbols-Proble des Debuggers gelöst....sagt Jemandem dieses Problem mit vmware.exe was????? ODer kann das auch ein Hardwaredefekt sein? Warum hatte sich der Bluescreen nach dem Update des Adaptec Treibers erledigt, kommt jetzt aber zwischendrin "mal wieder" vor? Seither läuft wieder alles einwandfrei (seit dem Absturz wieder 5 Tage!). Oder ist dieser Fehler ein anderer als damal der Adaptec?

 

Microsoft ® Windows Debugger Version 6.8.0004.0 X86

Loading Dump File [C:\WINDOWS\MEMORY.DMP]

Kernel Summary Dump File: Only kernel address space is available

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

Product: LanManNt, suite: SmallBusiness TerminalServer SmallBusinessRestricted SingleUserTS

Built by: 3790.srv03_sp2_gdr.070304-2240

Kernel base = 0x80800000 PsLoadedModuleList = 0x808a6ea8

Debug session time: Fri Apr 18 22:53:33.756 2008 (GMT+2)

System Uptime: 1 days 21:40:34.140

Loading Kernel Symbols

Loading User Symbols

PEB is paged out (Peb.Ldr = 7ffdc00c). Type ".hh dbgerr001" for details

Loading unloaded module list

..

Use !analyze -v to get detailed debugging information.

BugCheck C5, {0, d0000002, 1, 808921dd}

PEB is paged out (Peb.Ldr = 7ffdc00c). Type ".hh dbgerr001" for details

PEB is paged out (Peb.Ldr = 7ffdc00c). Type ".hh dbgerr001" for details

Probably caused by : Pool_Corruption ( nt!ExDeferredFreePool+1d7 )

Followup: Pool_corruption

---------

0: kd> !analyze -v

 

DRIVER_CORRUPTED_EXPOOL (c5)

An attempt was made to access a pageable (or completely invalid) address at an

interrupt request level (IRQL) that is too high. This is

caused by drivers that have corrupted the system pool. Run the driver

verifier against any new (or suspect) drivers, and if that doesn't turn up

the culprit, then use gflags to enable special pool.

Arguments:

Arg1: 00000000, memory referenced

Arg2: d0000002, IRQL

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

Arg4: 808921dd, address which referenced memory

Debugging Details:

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

PEB is paged out (Peb.Ldr = 7ffdc00c). Type ".hh dbgerr001" for details

PEB is paged out (Peb.Ldr = 7ffdc00c). Type ".hh dbgerr001" for details

BUGCHECK_STR: 0xC5_D0000002

CURRENT_IRQL: 2

FAULTING_IP:

nt!ExDeferredFreePool+1d7

808921dd 8937 mov dword ptr [edi],esi

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: vmware-vmx.exe

TRAP_FRAME: b83b788c -- (.trap 0xffffffffb83b788c)

ErrCode = 00000002

eax=8b310db0 ebx=00000000 ecx=000001ff edx=8b310c88 esi=8b33fe28 edi=00000000

eip=808921dd esp=b83b7900 ebp=b83b7938 iopl=0 nv up ei ng nz ac pe cy

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010297

nt!ExDeferredFreePool+0x1d7:

808921dd 8937 mov dword ptr [edi],esi ds:0023:00000000=????????

Resetting default scope

 

LAST_CONTROL_TRANSFER: from 808921dd to 8088c963

 

STACK_TEXT:

b83b788c 808921dd badb0d00 8b310c88 00000000 nt!KiTrap0E+0x2a7

b83b7938 808928c3 808aeae0 8a0423c0 00000000 nt!ExDeferredFreePool+0x1d7

b83b7990 80938fcf 888d9da8 00000000 b83b7c80 nt!ExFreePoolWithTag+0x57f

b83b7bf4 809390ca 00000019 b83b7c1c 00000001 nt!ObpWaitForMultipleObjects+0x269

b83b7d48 8088978c 00000019 00159070 00000001 nt!NtWaitForMultipleObjects+0xc8

b83b7d48 7c9485ec 00000019 00159070 00000001 nt!KiFastCallEntry+0xfc

WARNING: Frame IP not in any known module. Following frames may be wrong.

0012f7ec 00000000 00000000 00000000 00000000 0x7c9485ec

 

STACK_COMMAND: kb

FOLLOWUP_IP:

nt!ExDeferredFreePool+1d7

808921dd 8937 mov dword ptr [edi],esi

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt!ExDeferredFreePool+1d7

FOLLOWUP_NAME: Pool_corruption

IMAGE_NAME: Pool_Corruption

DEBUG_FLR_IMAGE_TIMESTAMP: 0

MODULE_NAME: Pool_Corruption

FAILURE_BUCKET_ID: 0xC5_D0000002_nt!ExDeferredFreePool+1d7

BUCKET_ID: 0xC5_D0000002_nt!ExDeferredFreePool+1d7

Followup: Pool_corruption

---------

Link zu diesem Kommentar
  • 2 Wochen später...

Hallo

 

nun gabs gestern wieder einen BOD! Kann mir niemand einen Tip hierzu geben? In diesem Minidmp scheint keine VMWare schuld zu sein...

 

 

Anbei nochmals ein Minidump aus dem Debugger:

 

BugCheck C5, {0, d0000002, 1, 808921dd}

 

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

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

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

 

 

Probably caused by : srv.sys ( srv!SrvSnapRemoveShare+44 )

 

DRIVER_CORRUPTED_EXPOOL (c5)

An attempt was made to access a pageable (or completely invalid) address at an

interrupt request level (IRQL) that is too high. This is

caused by drivers that have corrupted the system pool. Run the driver

verifier against any new (or suspect) drivers, and if that doesn't turn up

the culprit, then use gflags to enable special pool.

Arguments:

Arg1: 00000000, memory referenced

Arg2: d0000002, IRQL

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

Arg4: 808921dd, address which referenced memory

Debugging Details:

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

BUGCHECK_STR: 0xC5_D0000002

CURRENT_IRQL: 2

FAULTING_IP:

nt!KiDoubleFaultStack+92d

808921dd ?? ???

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP

PROCESS_NAME: System

LAST_CONTROL_TRANSFER: from 808921dd to 8088c963

STACK_TEXT:

b9917858 808921dd badb0d00 8b315c88 00000000 nt!ExFreePoolWithTag+0x62d

b9917904 808928c3 808aeae0 80892344 88ae7a60 nt!KiDoubleFaultStack+0x92d

b991795c f7b89d45 8aba4350 00000000 b99179c8 nt!KiDoubleFaultStack+0x1013

b9917970 f7bb92fb 88ae7a60 8087c914 f7b6d5b0 Ntfs!NtfsFreeRestartTable+0x19

b991799c f7b581e2 88709ef8 009179c8 b9917ab8 Ntfs!NtfsDeleteVcb+0x2a0

b99179bc f7b7efdb 88709ef8 88ae77f8 00000002 Ntfs!NtfsReleaseVcbCheckDelete+0xe2

b99179c0 88709ef8 88ae77f8 00000002 00000000 Ntfs!NtfsCommonClose+0x439

WARNING: Frame IP not in any known module. Following frames may be wrong.

b9917a3c f7b9280e 88709ef8 e21d1980 e21d18b8 0x88709ef8

b9917adc 8081df65 88ae7718 88b16628 8b32ef38 Ntfs!NtfsFsdClose+0x23e

b9917af0 f76e6c45 8b32ef38 88b16628 00000000 nt!IoCsqInitialize+0x31

b9917b18 8081df65 893a3ee8 88b16628 88b16638 fltMgr!FltpDispatch+0x6f

b9917b2c 808f98e0 00000000 00000000 00000000 nt!IoCsqInitialize+0x31

b9917b64 80933914 0083dee8 80a5bf00 8883ded0 nt!IoReportResourceUsage+0x17a

b9917b80 8086c955 8883dee8 00000000 00004338 nt!ObInsertObject+0x4fa

b9917ba0 809344b5 e1001e90 8b57d5d8 8a1c1db0 nt!PsGetVersion+0x31

b9917bb8 80934546 e1001e90 8883dee8 00004338 nt!ObpQueryNameString+0x447

b9917bfc 80934663 00004338 00000000 b9917c1c nt!ObpQueryNameString+0x4d8

b9917c0c b986edbb 80004338 e220cc68 b9917c48 nt!ObpQueryNameString+0x5f5

b9917c1c b986f64d e4c30130 e45519e8 e220cc68 srv!SrvSnapRemoveShare+0x44

b9917c48 b986f6be 000000c9 00000000 8931a4d0 srv!SrvSnapRefreshSnapShotsForShare+0x1c4

b9917c6c b982e89e 8931a4d0 8931a4d0 e45519e8 srv!SrvSnapEnumerateSnapShots+0x3d

b9917d08 b984cf52 8931a4d0 808825e0 8931a4d0 srv!SrvSmbNtIoctl+0x7c2

b9917d1c b986d5c9 b983180c 8931a4d0 893424d8 srv!ExecuteTransaction+0x176

b9917d78 b9822e87 8931a4d8 893424a0 b98366c7 srv!SrvSmbNtTransaction+0x4e2

b9917d84 b98366c7 00000000 8a1c1db0 00000000 srv!SrvProcessSmb+0xb7

b9917dac 80949b7c 003424a0 00000000 00000000 srv!WorkerThread+0x138

b9917ddc 8088e062 b9836602 893424a0 00000000 nt!NtSetInformationJobObject+0x58c

00000000 00000000 00000000 00000000 00000000 nt!CmpDelayedCloseSize+0x2

STACK_COMMAND: kb

FOLLOWUP_IP:

srv!SrvSnapRemoveShare+44

b986edbb ?? ???

SYMBOL_STACK_INDEX: 12

SYMBOL_NAME: srv!SrvSnapRemoveShare+44

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: srv

IMAGE_NAME: srv.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 45d6a048

FAILURE_BUCKET_ID: 0xC5_D0000002_srv!SrvSnapRemoveShare+44

BUCKET_ID: 0xC5_D0000002_srv!SrvSnapRemoveShare+44

Followup: MachineOwner

Link zu diesem Kommentar

hi tramor.

 

du solltest uns erstmal eine aufstellung der software geben,

dann welche hardware,

also HP DL380 oder was für einen server?

 

wichtiger halt die software.

 

- was ist denn jetzt mit vmware, welche vmware?

- Veritas Software drauf?

 

 

bug reports hin oder her,

du hast seit anfang an ein problem,

und da musst du dir das problem erstmal global anschauen.

 

 

wir warten auf deine aufstellung...

du verwendest aber wohl nicht einen sbs mit terminaldiensten,

wo die benutzer im rdp vmware workstation ausführen?

 

*herzinfakt*

:-)

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...