Aby wygenerować pełny opis problemu, odpowiedz na następujące pytania:
    - W jakich okolicznościach proces się załamuje. Czy to zachowanie jest spójne?
    - Czy wcześniej działało to lepiej.
    - Czasy wystąpień i zaobserwowany trend
zachowania — czy problem występuje tylko w okresach dużego obciążenia środowiska kopii zapasowych, kopii zapasowych lub określonego typu grupy kopii zapasowych.
    - Kiedy problem wystąpił po raz pierwszy. Co się wtedy zmieniło?
    - Jaki jest zakres problemu (wszyscy klienci/niektórzy klienci, wszystkie cele kopii zapasowych lub niektóre)
- Co do tej pory próbowano naprawić i jakie wnioski z tego wyciągnięto.

     - Który proces NetWorker nie odpowiada i na jakim komputerze (serwerze, węźle pamięci masowej lub kliencie).
     - Wersja i platforma
serwera NetWorker - Omówienie rozmiaru i charakteru strefy
danych kopii zapasowej - Nośnik docelowy dla tych kopii zapasowych

      - Korzystając z internetowego przewodnika zgodności NetWorker, sprawdź, czy wszystkie komponenty (serwer NetWorker, wersja systemu plików, proxy, węzły pamięci masowej, klienci, element docelowy) są obsługiwane.
      - Sprawdź, czy nie ma podstawowego systemu operacyjnego lub wad sprzętowych, które mogłyby spowodować awarie procesu (awarie dysków, pełny dysk, błędy sieciowe itp.).

      Podręcznik planowania optymalizacji wydajności NetWorker zawiera kilka sugerowanych wymagań programowych i sprzętowych oraz zalecenia, które należy wdrożyć, aby uzyskać optymalne dostrojenie środowiska NetWorker. Należy to sprawdzić, aby upewnić się, że stosowane są najlepsze praktyki dla tej strefy danych. Ma to zastosowanie, jeśli proces nie reaguje w okresach największego obciążenia.

       Sposób, w jaki znajdziemy pierwotną przyczynę braku odpowiedzi procesu, zależy od zachowania zdefiniowanego w kroku 1. Jeśli wyzwalacz jest nieznany, można przeprowadzić testy, aby spróbować ustalić, co powoduje awarię:

    - Monitoruj wydajność systemu przy dużym obciążeniu
- Sprawdź pliki dziennika systemu operacyjnego w czasie awarii pod kątem podobieństwa w zachowaniu
- Przeczytaj harmonogram NetWorker, aby określić, czy istnieje korelacja między czasami wystąpienia określonej zaplanowanej aktywności NetWorker.
    - Dowiedz się, jakie operacje inne niż NetWorker są uruchamiane na tym komputerze, które mogą mieć wpływ na jego zachowanie i czy ich harmonogram jest skorelowany z czasami awarii.
    - Jeśli awaria występuje konsekwentnie, zmień niektóre parametry, aby spróbować zawęzić przyczynę.  Na przykład tworzenie kopii zapasowej na innym nośniku docelowym lub tworzenie kopii zapasowych różnych typów danych z tego samego klienta NetWorker

Coredump to specjalny plik, który reprezentuje zrzut pamięci roboczej procesu w określonym czasie, zwykle gdy program zakończył się nieprawidłowo.  Pliki zrzutu pamięci rdzenia mogą służyć do diagnozowania przyczyny braku odpowiedzi procesu przez analizę, jakie funkcje procesu były uruchomione w momencie awarii i jakie dane były używane.

Większość systemów operacyjnych nie generuje automatycznie plików zrzutu pamięci.  Parametry systemu operacyjnego należy zmodyfikować w taki sposób, aby w momencie awarii procesu został wygenerowany plik zrzutu pamięci.  Ta modyfikacja musi zostać wykonana przed awarią.

1) Sprawdź katalog /nsr/cores, aby uzyskać ostatnie zrzuty rdzeni procesów NetWorker w systemie Unix lub Linux, lub sprawdź katalog awarii zdefiniowany w rejestrze systemu Windows (patrz krok 2).

2) Jeśli go nie ma, sprawdź, czy system operacyjny jest skonfigurowany do generowania plików zrzutu pamięci rdzenia w przypadku awarii procesu.  Szczegółowe informacje można znaleźć w dokumentacji systemu operacyjnego, ale w skrócie, prawdopodobnie będzie to wymagało zmiany wartości ulimit -c i -f w systemie Linux lub Unix oraz wprowadzenia zmian w rejestrze w systemie Windows.

Dla systemu Windows 2008R2:  
— Zaktualizuj rejestr przy użyciu nowego klucza podanego w http://msdn.microsoft.com/en-us/library/bb787181(VS.85).aspx.
- Korzystając z zalecanych wartości, plik zrzutu jest tworzony w C:\Users\Administrator\AppData\Local\CrashDumps- Włącz pełne zrzuty awaryjne
.

3) Plik rdzenia może być zbadany na samym komputerze hosta lub może być spakowany do analizy na innym komputerze.  Szczegółowe informacje na temat pakowania tych plików podstawowych są dostępne tutaj:

Pakowanie plików podstawowych UNIX i Linux:
489272: Zbieranie informacji o zrzucie rdzenia/zrzutu awaryjnego i powiązanych dziennikach

4) Analiza dostępnych danych:

- Pliki
dziennika systemu operacyjnego- Plik dziennika demona NetWorker z serwera NetWorker i odpowiedniego węzła pamięci masowej.  
- Plik rdzenia lub plik

awarii Szczegółowa analiza pliku rdzenia wymaga zaawansowanej wiedzy na temat wewnętrznych operacji NetWorker i powinna być wykonywana przez dział pomocy technicznej EMC NetWorker.  Można jednak wykonać wstępny odczyt pliku rdzenia, aby porównać zawartość pliku rdzenia ze znanymi problemami.

Linux i HP-UX
gdb [pełna ścieżka do przetworzenia] [plik podstawowy]
(gdb) gdzie

AIX
dbx [pełna ścieżka do przetworzenia] [plik rdzenia]
(dbx) gdzie

Solaris
pstack [ plik rdzenia ]
dbx [pełna ścieżka do procesu] [plik rdzeniowy]
(dbx) gdzie

Windows
- Uruchom program
debuggera windows windbg- Kliknij plik i otwórz plik zrzutu w windbg.
- Wpisz analyze --v w dolnym oknie poleceń, aby pobrać pełne informacje.
    
5) Na podstawie powyższej analizy i wiedzy na temat zachowania systemu można porównać incydent z listą znanych problemów opisanych w informacjach dotyczących wydania najnowszej wersji NetWorker.

Jeśli podejrzewasz, że wystąpił błąd w oprogramowaniu NetWorker, który jest przyczyną braku odpowiedzi procesu, musisz spakować plik awarii (patrz krok 3) i dostarczyć pełny opis zaobserwowanego zachowania do pomocy technicznej Dell Technologies NetWorker w celu szczegółowej analizy problemu.