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

     - Який процес 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
- Увімкнути повні аварійні дампи.

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

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

Для Windows дотримуйтесь інструкцій тут:
198564: Як зібрати ядро та дамп користувача для завислих процесів у Windows          

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

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

Детальний аналіз основного файлу вимагає глибоких знань внутрішніх операцій 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 для детального аналізу проблеми.