Server 2003 stürzt bei Robocopy Job ab
Hallo liebe Community,
Ein gar seltsames Problem beschäftigt mich seit heute:
Wir haben einen Server 2003 SP2, auf dem täglich eine Sicherung auf Fileebene durchgeführt werden soll.
Der Hintergrund dazu ist, daß wir zwar eine Bandsicherung haben, aber im worst case 3 Tage auf die Bänder warten müssen, da diese extern ausgelagert sind.
Um unseren Entwicklern den Zugriff auf die aktuellen Dateien gewährleisten zu können, nun also der Sicherungsjob mit Robocopy.
Ich habe nun ein Robocopy Script, daß den Job auch brav startet, aber nach ca 50 GB(ca ein Viertel der zu kopierenden Daten) den Server mit einem
schwerwiegenden Fehler neu startet.
Das Gleiche passiert auch, wenn man die Daten manuell kopieren möchte......
Hier der Auszug aus dem Dump File:
Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\WINDOWS\Minidump\Mini010710-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: * Invalid *
Executable search path is:
*
Unable to load image \WINDOWS\system32\ntoskrnl.exe, Win32 error 0n2
* WARNING: Unable to verify timestamp for ntoskrnl.exe
* ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe
Windows Server 2003 Kernel Version 3790 (Service Pack 2) MP (8 procs) Free x86 compatible
Product: Server, suite: TerminalServer SingleUserTS
Machine Name:
Kernel base = 0x80800000 PsLoadedModuleList = 0x808af9c8
Debug session time: Thu Jan 7 20:03:22.439 2010 (GMT+1)
System Uptime: 0 days 10:33:18.171
*
Unable to load image \WINDOWS\system32\ntoskrnl.exe, Win32 error 0n2
* WARNING: Unable to verify timestamp for ntoskrnl.exe
* ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe
Loading Kernel Symbols
Loading User Symbols
Loading unloaded module list
*
Use !analyze -v to get detailed debugging information.
BugCheck A, {95c, d000001b, 1, 8083eef1}
* WARNING: Unable to verify timestamp for mssmbios.sys
* ERROR: Module load completed but symbols could not be loaded for mssmbios.sys
* Kernel symbols are WRONG. Please fix symbols to do analysis.
*
* *
* *
* Your debugger is not using the correct symbols *
* *
* In order for this command to work properly, your symbol path *
* must point to .pdb files that have full type information. *
* *
* Certain .pdb files (such as the public OS symbols) do not *
* contain the required information. Contact the group that *
* provided you with these symbols if you need this command to *
* work. *
* *
* Type referenced: nt!_KPRCB *
* *
*
*
* *
* *
* Your debugger is not using the correct symbols *
* *
* In order for this command to work properly, your symbol path *
* must point to .pdb files that have full type information. *
* *
* Certain .pdb files (such as the public OS symbols) do not *
* contain the required information. Contact the group that *
* provided you with these symbols if you need this command to *
* work. *
* *
* Type referenced: nt!_KPRCB *
* *
*
*
* *
* *
* Your debugger is not using the correct symbols *
* *
* In order for this command to work properly, your symbol path *
* must point to .pdb files that have full type information. *
* *
* Certain .pdb files (such as the public OS symbols) do not *
* contain the required information. Contact the group that *
* provided you with these symbols if you need this command to *
* work. *
* *
* Type referenced: nt!_KPRCB *
* *
*
*
*
Probably caused by : ntoskrnl.exe ( nt+3eef1 )
Followup: MachineOwner
0: kd> !analyze -v
*
IRQL_NOT_LESS_OR_EQUAL (a)
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 a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 0000095c, memory referenced
Arg2: d000001b, IRQL
Arg3: 00000001, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 8083eef1, address which referenced memory
Debugging Details:
* Kernel symbols are WRONG. Please fix symbols to do analysis.
*
* *
* *
* Your debugger is not using the correct symbols *
* *
* In order for this command to work properly, your symbol path *
* must point to .pdb files that have full type information. *
* *
* Certain .pdb files (such as the public OS symbols) do not *
* contain the required information. Contact the group that *
* provided you with these symbols if you need this command to *
* work. *
* *
* Type referenced: nt!_KPRCB *
* *
*
*
* *
* *
* Your debugger is not using the correct symbols *
* *
* In order for this command to work properly, your symbol path *
* must point to .pdb files that have full type information. *
* *
* Certain .pdb files (such as the public OS symbols) do not *
* contain the required information. Contact the group that *
* provided you with these symbols if you need this command to *
* work. *
* *
* Type referenced: nt!_KPRCB *
* *
*
*
* *
* *
* Your debugger is not using the correct symbols *
* *
* In order for this command to work properly, your symbol path *
* must point to .pdb files that have full type information. *
* *
* Certain .pdb files (such as the public OS symbols) do not *
* contain the required information. Contact the group that *
* provided you with these symbols if you need this command to *
* work. *
* *
* Type referenced: nt!_KPRCB *
* *
*
*
*
ADDITIONAL_DEBUG_TEXT:
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols.
MODULE_NAME: nt
FAULTING_MODULE: 80800000 nt
DEBUG_FLR_IMAGE_TIMESTAMP: 4a79a70a
WRITE_ADDRESS: unable to get nt!MmSpecialPoolStart
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPoolCodeStart
unable to get nt!MmPoolCodeEnd
0000095c
CURRENT_IRQL: 0
FAULTING_IP:
nt+3eef1
8083eef1 ?? ???
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP
BUGCHECK_STR: 0xA
LAST_CONTROL_TRANSFER: from 8083eef1 to 80836dfd
STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
808a343c 8083eef1 badb0d00 ffdff120 00000000 nt+0x36dfd
808a34d0 8083d57f 00000000 8083d617 808a3574 nt+0x3eef1
808a34f4 8083fc15 ffdffa40 ffdff120 00000000 nt+0x3d57f
808a35a8 8083d47c 00000000 00000000 02251b8a nt+0x3fc15
808a3600 80839b3f 00000000 0000000e 00000000 nt+0x3d47c
808a6b40 00000000 808a6b48 808a6b48 808a6b50 nt+0x39b3f
STACK_COMMAND: kb
FOLLOWUP_IP:
nt+3eef1
8083eef1 ?? ???
SYMBOL_STACK_INDEX: 1
SYMBOL_NAME: nt+3eef1
FOLLOWUP_NAME: MachineOwner
IMAGE_NAME: ntoskrnl.exe
BUCKET_ID: WRONG_SYMBOLS
Followup: MachineOwner
Dass die Datei ntoskrnl.exe wahrscheinlich daran schuld ist, hab ich schon rauslesen können.....
Interessant in dem Zusammenhang vielleicht auch, daß nach dem Neustart(der selbständig durchgeführt wurde, kein Eingreifen von mir)
der Server aus der Domäne geflogen war.....
Irgendwelche Ideen dazu?
Schon mal Danke und LG
Ein gar seltsames Problem beschäftigt mich seit heute:
Wir haben einen Server 2003 SP2, auf dem täglich eine Sicherung auf Fileebene durchgeführt werden soll.
Der Hintergrund dazu ist, daß wir zwar eine Bandsicherung haben, aber im worst case 3 Tage auf die Bänder warten müssen, da diese extern ausgelagert sind.
Um unseren Entwicklern den Zugriff auf die aktuellen Dateien gewährleisten zu können, nun also der Sicherungsjob mit Robocopy.
Ich habe nun ein Robocopy Script, daß den Job auch brav startet, aber nach ca 50 GB(ca ein Viertel der zu kopierenden Daten) den Server mit einem
schwerwiegenden Fehler neu startet.
Das Gleiche passiert auch, wenn man die Daten manuell kopieren möchte......
Hier der Auszug aus dem Dump File:
Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\WINDOWS\Minidump\Mini010710-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: * Invalid *
- Symbol loading may be unreliable without a symbol search path. *
- Use .symfix to have the debugger choose a symbol path. *
- After setting your symbol path, use .reload to refresh symbol locations. *
Executable search path is:
*
- Symbols can not be loaded because symbol path is not initialized. *
- *
- The Symbol Path can be set by: *
- using the _NT_SYMBOL_PATH environment variable. *
- using the -y <symbol_path> argument when starting the debugger. *
- using .sympath and .sympath+ *
Unable to load image \WINDOWS\system32\ntoskrnl.exe, Win32 error 0n2
* WARNING: Unable to verify timestamp for ntoskrnl.exe
* ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe
Windows Server 2003 Kernel Version 3790 (Service Pack 2) MP (8 procs) Free x86 compatible
Product: Server, suite: TerminalServer SingleUserTS
Machine Name:
Kernel base = 0x80800000 PsLoadedModuleList = 0x808af9c8
Debug session time: Thu Jan 7 20:03:22.439 2010 (GMT+1)
System Uptime: 0 days 10:33:18.171
*
- Symbols can not be loaded because symbol path is not initialized. *
- *
- The Symbol Path can be set by: *
- using the _NT_SYMBOL_PATH environment variable. *
- using the -y <symbol_path> argument when starting the debugger. *
- using .sympath and .sympath+ *
Unable to load image \WINDOWS\system32\ntoskrnl.exe, Win32 error 0n2
* WARNING: Unable to verify timestamp for ntoskrnl.exe
* ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe
Loading Kernel Symbols
Loading User Symbols
Loading unloaded module list
*
- *
- Bugcheck Analysis *
- *
Use !analyze -v to get detailed debugging information.
BugCheck A, {95c, d000001b, 1, 8083eef1}
* WARNING: Unable to verify timestamp for mssmbios.sys
* ERROR: Module load completed but symbols could not be loaded for mssmbios.sys
* Kernel symbols are WRONG. Please fix symbols to do analysis.
*
* *
* *
* Your debugger is not using the correct symbols *
* *
* In order for this command to work properly, your symbol path *
* must point to .pdb files that have full type information. *
* *
* Certain .pdb files (such as the public OS symbols) do not *
* contain the required information. Contact the group that *
* provided you with these symbols if you need this command to *
* work. *
* *
* Type referenced: nt!_KPRCB *
* *
*
*
* *
* *
* Your debugger is not using the correct symbols *
* *
* In order for this command to work properly, your symbol path *
* must point to .pdb files that have full type information. *
* *
* Certain .pdb files (such as the public OS symbols) do not *
* contain the required information. Contact the group that *
* provided you with these symbols if you need this command to *
* work. *
* *
* Type referenced: nt!_KPRCB *
* *
*
*
* *
* *
* Your debugger is not using the correct symbols *
* *
* In order for this command to work properly, your symbol path *
* must point to .pdb files that have full type information. *
* *
* Certain .pdb files (such as the public OS symbols) do not *
* contain the required information. Contact the group that *
* provided you with these symbols if you need this command to *
* work. *
* *
* Type referenced: nt!_KPRCB *
* *
*
*
- Symbols can not be loaded because symbol path is not initialized. *
- *
- The Symbol Path can be set by: *
- using the _NT_SYMBOL_PATH environment variable. *
- using the -y <symbol_path> argument when starting the debugger. *
- using .sympath and .sympath+ *
*
- Symbols can not be loaded because symbol path is not initialized. *
- *
- The Symbol Path can be set by: *
- using the _NT_SYMBOL_PATH environment variable. *
- using the -y <symbol_path> argument when starting the debugger. *
- using .sympath and .sympath+ *
Probably caused by : ntoskrnl.exe ( nt+3eef1 )
Followup: MachineOwner
0: kd> !analyze -v
*
- *
- Bugcheck Analysis *
- *
IRQL_NOT_LESS_OR_EQUAL (a)
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 a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 0000095c, memory referenced
Arg2: d000001b, IRQL
Arg3: 00000001, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 8083eef1, address which referenced memory
Debugging Details:
* Kernel symbols are WRONG. Please fix symbols to do analysis.
*
* *
* *
* Your debugger is not using the correct symbols *
* *
* In order for this command to work properly, your symbol path *
* must point to .pdb files that have full type information. *
* *
* Certain .pdb files (such as the public OS symbols) do not *
* contain the required information. Contact the group that *
* provided you with these symbols if you need this command to *
* work. *
* *
* Type referenced: nt!_KPRCB *
* *
*
*
* *
* *
* Your debugger is not using the correct symbols *
* *
* In order for this command to work properly, your symbol path *
* must point to .pdb files that have full type information. *
* *
* Certain .pdb files (such as the public OS symbols) do not *
* contain the required information. Contact the group that *
* provided you with these symbols if you need this command to *
* work. *
* *
* Type referenced: nt!_KPRCB *
* *
*
*
* *
* *
* Your debugger is not using the correct symbols *
* *
* In order for this command to work properly, your symbol path *
* must point to .pdb files that have full type information. *
* *
* Certain .pdb files (such as the public OS symbols) do not *
* contain the required information. Contact the group that *
* provided you with these symbols if you need this command to *
* work. *
* *
* Type referenced: nt!_KPRCB *
* *
*
*
- Symbols can not be loaded because symbol path is not initialized. *
- *
- The Symbol Path can be set by: *
- using the _NT_SYMBOL_PATH environment variable. *
- using the -y <symbol_path> argument when starting the debugger. *
- using .sympath and .sympath+ *
*
- Symbols can not be loaded because symbol path is not initialized. *
- *
- The Symbol Path can be set by: *
- using the _NT_SYMBOL_PATH environment variable. *
- using the -y <symbol_path> argument when starting the debugger. *
- using .sympath and .sympath+ *
ADDITIONAL_DEBUG_TEXT:
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols.
MODULE_NAME: nt
FAULTING_MODULE: 80800000 nt
DEBUG_FLR_IMAGE_TIMESTAMP: 4a79a70a
WRITE_ADDRESS: unable to get nt!MmSpecialPoolStart
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPoolCodeStart
unable to get nt!MmPoolCodeEnd
0000095c
CURRENT_IRQL: 0
FAULTING_IP:
nt+3eef1
8083eef1 ?? ???
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP
BUGCHECK_STR: 0xA
LAST_CONTROL_TRANSFER: from 8083eef1 to 80836dfd
STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
808a343c 8083eef1 badb0d00 ffdff120 00000000 nt+0x36dfd
808a34d0 8083d57f 00000000 8083d617 808a3574 nt+0x3eef1
808a34f4 8083fc15 ffdffa40 ffdff120 00000000 nt+0x3d57f
808a35a8 8083d47c 00000000 00000000 02251b8a nt+0x3fc15
808a3600 80839b3f 00000000 0000000e 00000000 nt+0x3d47c
808a6b40 00000000 808a6b48 808a6b48 808a6b50 nt+0x39b3f
STACK_COMMAND: kb
FOLLOWUP_IP:
nt+3eef1
8083eef1 ?? ???
SYMBOL_STACK_INDEX: 1
SYMBOL_NAME: nt+3eef1
FOLLOWUP_NAME: MachineOwner
IMAGE_NAME: ntoskrnl.exe
BUCKET_ID: WRONG_SYMBOLS
Followup: MachineOwner
Dass die Datei ntoskrnl.exe wahrscheinlich daran schuld ist, hab ich schon rauslesen können.....
Interessant in dem Zusammenhang vielleicht auch, daß nach dem Neustart(der selbständig durchgeführt wurde, kein Eingreifen von mir)
der Server aus der Domäne geflogen war.....
Irgendwelche Ideen dazu?
Schon mal Danke und LG
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 132936
Url: https://administrator.de/contentid/132936
Ausgedruckt am: 23.11.2024 um 01:11 Uhr
7 Kommentare
Neuester Kommentar
Hallo, solche Abstürze unter Last beim kopieren können leider alles möglich sein:
- RAM
- Controller
- HDD
- Mainboard
Dabei sowohl Hardware und auch Treiber.
Teste doch erstmal die Festplatten und RAM mit z.B. der UBCD.
Steht im EventLog was drin? Was sagt das Log des RaidContrllers (wenn vorhanden/möglich).
Stefan
- RAM
- Controller
- HDD
- Mainboard
Dabei sowohl Hardware und auch Treiber.
Teste doch erstmal die Festplatten und RAM mit z.B. der UBCD.
Steht im EventLog was drin? Was sagt das Log des RaidContrllers (wenn vorhanden/möglich).
Stefan