Для того, щоб згенерувати повний опис проблеми, зверніться до наступних питань:
    - За яких обставин відбувається збій процесу. Чи є така поведінка послідовною?
    - Раніше краще це робилося.
    - Час виникнення та спостережувана тенденція
поведінки - Проблема виникає лише під час великого навантаження на середовище резервного копіювання або резервні копії, або певний тип групи резервного копіювання.
    - Коли вперше виникла проблема. Що ж тоді змінилося?
    - Який обсяг проблеми (всі клієнти/деякі клієнти, всі цілі резервного копіювання або деякі)
- Що було намагалися виправити до цього часу і які висновки були зроблені з цього.

     - Який процес NetWorker не відповідає і на якій машині (сервер, вузол зберігання або клієнт).
     - Версія сервера та платформа
NetWorker - Огляд розміру та характеру резервної зони
даних - Цільові носії для цих резервних копій

      - Використовуючи онлайн-посібник із сумісності NetWorker, перевірте, чи підтримуються всі компоненти (сервер NetWorker, версія файлової системи, проксі, вузли зберігання, клієнти, ціль).
      - Переконайтеся, що немає недоліків операційної системи або обладнання, які могли б спричинити збої процесів (збої диска, переповнення диска, помилки мережі тощо).

      Керівництво по плануванню оптимізації продуктивності NetWorker містить кілька запропонованих вимог до програмного та апаратного забезпечення і рекомендацій, які повинні бути реалізовані, щоб мати оптимально налаштоване середовище NetWorker. Це слід переглянути, щоб переконатися, що дотримуються найкращих практик для цієї зони даних. Це актуально в тому випадку, якщо процес, який не реагує, відбувається в моменти найбільшого навантаження.

       Те, як ми знайдемо основну причину того, що процес не реагує, залежить від поведінки, як визначено на кроці 1. Якщо тригер невідомий, можна провести тести, щоб спробувати встановити, що спричиняє збій:

    - Слідкуйте за продуктивністю системи при великому навантаженні
- Перевіряйте файли журналу операційної системи навколо часу збоїв на предмет спільності в поведінці
- Прочитайте розклад NetWorker, щоб визначити, чи існує кореляція між часом виникнення певної запланованої активності NetWorker.
    - З'ясуйте, які операції, не пов'язані з NetWorker, виконуються на цій машині, що може вплинути на її поведінку і чи корелює їх графік з часом збоїв.
    - Якщо збій відбувається постійно, змініть деякі параметри, щоб спробувати звузити причину.  Наприклад, резервне копіювання на інший цільовий носій або резервне копіювання різних типів даних з одного і того ж клієнта NetWorker

Ядро — це спеціальний файл, який представляє собою дамп робочої пам'яті процесу в певний час, зазвичай, коли програма завершила роботу ненормально.  Файли дампів ядра можна використовувати для діагностики причини того, що процес не реагує, аналізуючи, які функції процесу були запущені в момент збою та до яких даних було отримано доступ.

Більшість операційних систем не генерують файли дампів ядра автоматично.  Параметри операційної системи повинні бути змінені таким чином, щоб файл дампа ядра генерувався в момент збою процесу.  Ця модифікація повинна бути зроблена до аварії.

1) Перевірте каталог /nsr/cores на наявність останніх дампів ядра процесів NetWorker в Unix або Linux або перевірте каталог збоїв, як визначено в реєстрі Windows (див. крок 2).

2) Якщо такого немає, перевірте, чи операційна система налаштована на генерацію файлів дампа ядра, якщо відбувається збій процесу.  Дивіться Документацію операційної системи для отримання повної інформації, але коротко, це, швидше за все, включатиме зміну значень ulimit -c та -f у Linux або Unix та внесення змін до реєстру у Windows.

Для Windows 2008R2:  
- Оновіть реєстр за допомогою нового ключа, наданого за адресою http://msdn.microsoft.com/en-us/library/bb787181(VS.85).aspx.
- Використовуючи рекомендовані значення, файл дампа створюється в C:\Users\Administrator\AppData\Local\CrashDumps- Enable full crash dumps
.

3) Файл ядра може бути перевірений на самій хост-машині або може бути упакований для аналізу на іншій машині.  Детальна інформація про те, як упакувати ці основні файли, доступна тут:

UNIX та Linux core file packaging:
489272: Як збирати інформацію про ядро/аварійний дамп і пов'язані журнали

4) Проаналізуйте доступні дані:

- Файли
журналу операційної системи - файл журналу демонів NetWorker із сервера NetWorker та відповідного вузла зберігання.  
- Основний файл або Crash файл

Детальний аналіз основного файлу вимагає глибоких знань внутрішніх операцій NetWorker і повинен виконуватися службою підтримки EMC NetWorker.  Однак початкове читання основного файлу може бути виконано, щоб порівняти вміст основного файлу з відомими проблемами.

Linux і HP-UX
gdb [повний шлях до процесу] [основний файл]
(gdb) де

AIX
dbx [повний шлях до процесу] [основний файл]
(dbx) де

Solaris
pstack [ основний файл ]
dbx [повний шлях до процесу] [основний файл]
(dbx) де

Windows
- Запустіть програму
налагоджувача windbg windows- Натисніть на Файл і відкрийте файл дампа в windbg.
- Введіть analyze --v у нижньому вікні команд, щоб отримати повну інформацію.
    
5) Ґрунтуючись на наведеному вище аналізі та знаннях про поведінку системи, ви можете порівняти інцидент зі списком відомих проблем, детально описаним у примітках до випуску NetWorker для останньої версії.

Якщо ви підозрюєте, що в програмному забезпеченні NetWorker є збій, який відповідає за процес, який не відповідає, ви повинні упакувати файл збою (див. Крок 3) і надати йому повний опис спостережуваної поведінки в службу підтримки Dell Technologies NetWorker для детального аналізу проблеми.