Fault Page in nonepaged area 0x50 Bluescreen

autkom

Newbie
Registriert
Feb. 2005
Beiträge
6
Hi Leute,

habe seit einiger Zeit erhebliche Probleme beim SBS 2003 eines unserer Kunden:
Beim Reboot des Servers kommt alle 2-3 mal ein mysteriöser Bluescreen.
Fault_Page_in_nonepaged_Area mit folgender Adress:
0x0000050 (0xF1BC700C , 0x00000000 , 0xF7957671 , 0x00000002)
ohne irgendeine fehlerhafte Datei !!


Vorgeschichte:
Ich habe einen SCSI Controller mit einem externen Bandlaufwerk eingebaut (Ontream ADR50- Tape) und Veritas Bandsicherungssoftware. Damals hatte ich, egal welchen Treiber ich verwendete (den von Onstream oder von Veritas) auch diesen Bluescreen. Aber mit entsrechendem Treiber angegeben.
Nach dem ich alles entfernt habe (SCSI-Controller und Bandlaufwerk) kam der BS immer noch sporadisch und ich habe ihn bis dato nicht wegbekommen!

Habe in einem älteren Beitrag gelesen, dass man
a) per "DrWatson" nach Fehlern suchen sollte
b) mal nach mini- bzw. Memory.dmp´s suchen sollte.

Zu a): Ich habe eine fehlerhafte Windowsdate gefunden (C:\Windows\system32\rsmui.exe (c0000005 <nosymbol> (000ADDF2)). Keine Ahnung was das File macht.

Zu b): Habe 2 Mini-dmp- Files gefunden (sind mit hochgeladen) und eine riesige Memory.dmp (über 1GB groß)



Vielleicht könnte mit jemand die dmp´s debuggen oder einen Tip geben was ich noch machen kann um das System wieder stabil zu bekommen?!

Schon mal vielen Dank im Voraus!!!

Gruß
Autkom
 

Anhänge

  • Mini.zip
    22,1 KB · Aufrufe: 332
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: dedddcdf, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: f7678c91, address which referenced memory

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


OVERLAPPED_MODULE:

READ_ADDRESS: dedddcdf

CURRENT_IRQL: 2

FAULTING_IP:
ndistapi!NdisTapiRegisterProvider+27
f7678c91 837e0401 cmp dword ptr [esi+0x4],0x1

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from f6eaf71e to f7678c91

TRAP_FRAME: f78ceab0 -- (.trap fffffffff78ceab0)
ErrCode = 00000000
eax=8618f968 ebx=f78cec20 ecx=8618f9b4 edx=00000000 esi=dedddcdb edi=f78cec34
eip=f7678c91 esp=f78ceb24 ebp=f78ceb4c iopl=0 nv up ei ng nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010286
ndistapi!NdisTapiRegisterProvider+0x27:
f7678c91 837e0401 cmp dword ptr [esi+0x4],0x1 ds:0023:dedddcdf=????????
Resetting default scope

STACK_TEXT:
f78ceb4c f6eaf71e 00000005 f78cec20 00000000 ndistapi!NdisTapiRegisterProvider+0x27
f78cec3c f7237ea7 f78cecd4 f78cec64 862ebe8c ndiswan!ProtoBindAdapter+0x25e
f78cecd8 f7238b18 85558160 85558130 804f0b90 NDIS!ndisInitializeBinding+0x187
f78ced60 f723bfa3 865a88a0 80582d80 f78cedac NDIS!ndisCheckAdapterBindings+0x138
f78ced74 f723381a 85eb7e18 85558100 804eebdb NDIS!ndisQueuedCheckAdapterBindings+0x83
f78ced80 804eebdb 85eb7e18 00000000 865a88a0 NDIS!ndisWorkItemHandler+0xa
f78cedac 8059b35e 85eb7e18 00000000 00000000 nt!ExpWorkerThread+0xe9
f78ceddc 805008e6 804eeb10 00000000 00000000 nt!PspSystemThreadStartup+0x2e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


FOLLOWUP_IP:
ndistapi!NdisTapiRegisterProvider+27
f7678c91 837e0401 cmp dword ptr [esi+0x4],0x1

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: ndistapi!NdisTapiRegisterProvider+27

MODULE_NAME: ndistapi

IMAGE_NAME: ndistapi.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3e800120

STACK_COMMAND: .trap fffffffff78ceab0 ; kb

FAILURE_BUCKET_ID: 0xD1_ndistapi!NdisTapiRegisterProvider+27

BUCKET_ID: 0xD1_ndistapi!NdisTapiRegisterProvider+27

Followup: MachineOwner

_________________________________________________________________


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

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e)
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: f4c6a5a2, The address that the exception occurred at
Arg3: f78e2638, Exception Record Address
Arg4: f78e2288, Context Record Address

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


ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

FAULTING_IP:
trscsi+35a2
f4c6a5a2 8a430c mov al,[ebx+0xc]

EXCEPTION_PARAMETER1: f78e2638

CONTEXT: f78e2288 -- (.cxr fffffffff78e2288)
eax=2f726964 ebx=11f50964 ecx=00000054 edx=00000000 esi=806db4e8 edi=e282a018
eip=f4c6a5a2 esp=f78e2700 ebp=f78e2720 iopl=0 nv up ei pl nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202
trscsi+0x35a2:
f4c6a5a2 8a430c mov al,[ebx+0xc] ds:0023:11f50970=??
Resetting default scope

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP

BUGCHECK_STR: 0x7E

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from f4c6a51d to f4c6a5a2

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
f78e2720 f4c6a51d 86bec810 87070af8 00000002 trscsi+0x35a2
f78e285c 8062d521 86bec810 85c5b000 00000000 trscsi+0x351d
f78e2918 80637709 80004e54 85c5b000 86bec810 nt!IopLoadDriver+0x5e1
f78e295c 805b5fdc e1c976e0 00000001 80004e54 nt!PipCallDriverAddDeviceQueryRoutine+0x239
f78e29a8 805b5d5b f78e2a34 e1c976c4 f78e2a08 nt!RtlpCallQueryRegistryRoutine+0x3af
f78e2a0c 80638af7 00000000 00000084 00000001 nt!RtlQueryRegistryValues+0x2a4
f78e2adc 8063a557 00000000 00000001 f78e2d60 nt!PipCallDriverAddDevice+0x237
f78e2d28 8063aa8e 86f61e48 00000001 00000000 nt!PipProcessDevNodeTree+0x147
f78e2d58 8053fd8a 00000003 87067b20 80582dbc nt!PiRestartDevice+0x7e
f78e2d80 804eebdb 00000000 00000000 87067b20 nt!PipDeviceActionWorker+0x17a
f78e2dac 8059b35e 00000000 00000000 00000000 nt!ExpWorkerThread+0xe9
f78e2ddc 805008e6 804eeb10 00000001 00000000 nt!PspSystemThreadStartup+0x2e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


FOLLOWUP_IP:
trscsi+35a2
f4c6a5a2 8a430c mov al,[ebx+0xc]

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: trscsi+35a2

MODULE_NAME: trscsi

IMAGE_NAME: trscsi.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3e651a45

STACK_COMMAND: .cxr fffffffff78e2288 ; kb

FAILURE_BUCKET_ID: 0x7E_trscsi+35a2

BUCKET_ID: 0x7E_trscsi+35a2

Followup: MachineOwner
 
Hallo FBrenner,

könntest Du vielleicht 2-3 Sätze bzw. Erlärungen dazu schreiben.
Das sagt mir ehrlich gesagt nicht viel...

Wäre super und danke nochmal

Gruß
Autkom
 
Hi

eras: Nein, habe kein Alc installiert!

Fiona: DIe NL-Seite hat mich schon wieder weiter gebracht.

Ich befürchte, die beiden Treiber (adr2k.sys von Onstream und der trscsi.sys von Veritas) wurden nach nicht befriedigender Funktion nicht sauber deinstalliert!

Ich war heute morgen noch einmal vor Ort und hab mir die Registry angeschaut, wusste aber nur wie der Treiber von Onstream heisst, und nicht wie der Veritastreiber.

Die Reg ist voll davon und der Teiber hängt immer noch im System. Muss jetzt noch mal schauen ob der von Veritas noch drin sitzt!

Die Sache ist halt die, dass der Streamer nicht mehr da ist und ich somit die Treiber nicht mehr sauber deinstallieren kann!!

Kann die Reste "einfach so" aus der Registry löschen ohne dass ich was verschiesse??? Das ist mein größtes Problem glaube ich...

Viele Grüße
Autkom
 
Ich weiß nicht ob es hilft den Treiber und Veritas erneut zu installieren.
Damit hättest du vielleicht wieder eine volle Deinstallationsroutine.
Öfters passiert es, wenn bei Dienste oder Systemstart etwas geladen wird und somit aktiv ist kann es nicht richtig deinstalliert werden, da in Verwendung.
Vielleicht weißt du, ob bei deiner Deinstallation alles deaktiviert war.
Oftmals hilft es dann wenn man bei Start / Ausführen / msconfig bei Systemstart alles deaktiviert.
Weiter auf Reiter "Dienste".
Dort bei "Microsoft Dienste ausblenden" den Haken reinmachen sonst startet Windows nicht richtig.
Den Rest auch deaktivieren.
Neustart und versuchen erneut zu deinstallieren.

Wenn etwas als Dienste gelistet ist kann man den auch komplett mit delsrv.exe löschen.
Info in diesem Post weiter unten.
https://www.computerbase.de/forum/threads/bluescreen-ohne-fehlerangabe.78187/page-2#post-999332

Hoffe es hilft

Gruß

Fiona
 
Veritas läuft noch (wir sichern auf nen andern BackupServer), aber ich denke der Treiber lässt sich ohne den Streamer nicht wieder reibungslos installieren. Genausowenig wie der Onstream Treiber.

Aber die Idee mit msconfig werde ich am Mo gleich testen.

Vielen Dank und euch ein schönes Wochenende !!!

Gruß
Autkom
 
Leider habe ich auch unter msconfig keine ungewöhnlichen Startereignisse sehen können. Sind ausschliesslich nur Dienste von BackupExec, AVM, Datev, Exchange und DIenste der USV-Software gestartet.
Nochmal auf meine Idee die Reste aus der Registry zu löschen zurück zu kommen.Ist das sinnvoll???oder überhaupt möglich??

DIe Treiber kann ich (denk ich) nicht ohne Bandlaufwerk wieder installieren bzw. auch wieder deinstallieren.

Hat noch jemand einen Tip??

Wäre super dankbar !!!

Gruß
AUTKOM
 
Zurück
Oben