Добрый день!

Ряд программ, тот же Google Chrome, как я понимаю, для снятия аварийных дампов используют сторонний вспомогательный процесс. Какие от этого профиты? И есть ли какие рекомендации, как наиболее правильно снимать креш-дамп (имеется ввиду MiniDumpWriteDump) в своем приложении: в аварийном потоке, в потоке, порожденном для снятия отдельно, или вообще в отдельном процессе. Спасибо.

Здравствуйте, Timonn24, Вы писали:

T>Добрый день!

T>Ряд программ, тот же Google Chrome, как я понимаю, для снятия аварийных дампов используют сторонний вспомогательный процесс. Какие от этого профиты? И есть ли какие рекомендации, как наиболее правильно снимать креш-дамп (имеется ввиду MiniDumpWriteDump) в своем приложении: в аварийном потоке, в потоке, порожденном для снятия отдельно, или вообще в отдельном процессе. Спасибо.

ну если конкретно про "снятия аварийных дампов используют сторонний вспомогательный процесс", то на это есть рекомендация в MSDN-e в статье про ф-ю MiniDumpWriteDump:

MiniDumpWriteDump should be called from a separate process if at all possible, rather than from within the target process being dumped. This is especially true when the target process is already not stable. For example, if it just crashed. A loader deadlock is one of many potential side effects of calling MiniDumpWriteDump from within the target process.

Да, спасибо. Как говорится, слона-то я и не заметил.

Здравствуйте, Timonn24, Вы писали:

T>Ряд программ, тот же Google Chrome, как я понимаю, для снятия аварийных дампов используют сторонний вспомогательный процесс. Какие от этого профиты?

Если произошел Stack Overflow, то может просто не хватить стека на MiniDumpWriteDump.

Могут быть ещё другие проблемы, касающиеся контекста всего процесса, вроде порчи кучи (порчи лока кучи), или исчерпание хендлов, которые не дадут записать дамп.

Просигналить другому процессу, чтобы он писал дамп, можно через какой-нибудь SetEvent, который не будет интенсивно использовать стек, и без обращений к куче тоже обойдётся.
Разумеется, Event должен быть открыт заранее.

Здравствуйте, rumit7, Вы писали:

R>Здравствуйте, Timonn24, Вы писали:

R>ну если конкретно про "снятия аварийных дампов используют сторонний вспомогательный процесс", то на это есть рекомендация в MSDN-e в статье про ф-ю MiniDumpWriteDump:

А каким образом сторонний процесс узнает про падение в соседнем процессе?

Здравствуйте, kgrach, Вы писали:

K>Здравствуйте, rumit7, Вы писали:

R>>Здравствуйте, Timonn24, Вы писали:

R>>ну если конкретно про "снятия аварийных дампов используют сторонний вспомогательный процесс", то на это есть рекомендация в MSDN-e в статье про ф-ю MiniDumpWriteDump:

K>А каким образом сторонний процесс узнает про падение в соседнем процессе?

один из возможных вариантов

Здравствуйте, rumit7, Вы писали:

R>Здравствуйте, kgrach, Вы писали:

K>>А каким образом сторонний процесс узнает про падение в соседнем процессе?

R>один из возможных вариантов

Спасибо этот способ понятен.

А вот как это делает procdump? Не ли там какого-то чита со стороны OC?

Здравствуйте, kgrach, Вы писали:

K>Здравствуйте, rumit7, Вы писали:

R>>Здравствуйте, kgrach, Вы писали:

K>>>А каким образом сторонний процесс узнает про падение в соседнем процессе?

R>>один из возможных вариантов

K>Спасибо этот способ понятен.

K>А вот как это делает procdump? Не ли там какого-то чита со стороны OC?

какая именно возможность procdump-a Вас интересует?

Здравствуйте, rumit7, Вы писали:

R>Здравствуйте, kgrach, Вы писали:

R>какая именно возможность procdump-a Вас интересует?

В способе, который описан по ссылке, предполагается, что программа, которую мониторят и процесс, который формирует дамп, знают друг о друге.
В случае, если аварийный дамп создается через procdump, то аварийная программа ничего ему не передает.
И в идеале, при снятии дампа хотелось бы обойтись без передачи идентификатора потока и указателя на контекст исключения.

Здравствуйте, kgrach, Вы писали:

K>Здравствуйте, rumit7, Вы писали:

R>>Здравствуйте, kgrach, Вы писали:

R>>какая именно возможность procdump-a Вас интересует?

K>В способе, который описан по ссылке, предполагается, что программа, которую мониторят и процесс, который формирует дамп, знают друг о друге.
K>В случае, если аварийный дамп создается через procdump, то аварийная программа ничего ему не передает.
K>И в идеале, при снятии дампа хотелось бы обойтись без передачи идентификатора потока и указателя на контекст исключения.

если коротко, то как-то так:
DebugActiveProcess — для "Write a dump when the process encounters an unhandled exception"
SendMessageTimeout — для "Write dump if process has a hung window (does not respond to window messages for at least 5 seconds)"

возможно еще можно найти исходники procdump-a, думаю на wasm-e или здесь у кого есть, но ничего сверх естественного там не будет

UPD. вот есть пример для hung window

UPD2. вот и пример для process encounters an unhandled exception

Здравствуйте, rumit7, Вы писали:

R>Здравствуйте, kgrach, Вы писали:

R>UPD2. вот и пример для process encounters an unhandled exception

Вот это я и искал. Еще раз спасибо.

int debuggerLoop(DWORD pid, HANDLE eventHandle)
{
  // attach to debuggee
  if (!DebugActiveProcess(pid)) {
    fprintf(stderr, "Could not attach to process %d\n", pid);
    return 1;
  }

  HANDLE processHandle = 0;
  while (1) {
    DEBUG_EVENT de;
    if (WaitForDebugEvent(&de, INFINITE)) {
      switch(de.dwDebugEventCode)
      {
      case CREATE_PROCESS_DEBUG_EVENT:
        processHandle = de.u.CreateProcessInfo.hProcess;
        printf("Attaching to process %x...\n", processHandle);
        break;

      case EXCEPTION_DEBUG_EVENT:
        printf("Exception reported: code=%x, dwFirstChance=%d\n",
          de.u.Exception.ExceptionRecord.ExceptionCode, de.u.Exception.dwFirstChance);

        if (de.u.Exception.ExceptionRecord.ExceptionCode == EXCEPTION_BREAKPOINT) {
          SetEvent(eventHandle);
        } else {
          createMinidump(processHandle, de.dwProcessId, de.dwThreadId,
            &de.u.Exception.ExceptionRecord);
          ContinueDebugEvent(de.dwProcessId, de.dwThreadId,
            DBG_EXCEPTION_NOT_HANDLED); // required?
          DebugActiveProcessStop(pid);
          printf("Detached from process, terminating debugger...\n");
          return 0;
        }
        break;

      default:
        // printf("debug event code = %d\n", de.dwDebugEventCode);
        break;
      }

      ContinueDebugEvent(de.dwProcessId, de.dwThreadId, DBG_CONTINUE);
    }
  } // while (1)

  return 1;
}

Интересная тема.

у меня есть связанный вопрос. Что делать с дампом, снятым другим процессом без использования _EXCEPTION_POINTERS?
Пример: при вваливании в глобальный перехватчик просто запускаем процесс procdump и указываем свой PID. Далее по тексту стоит Sleep(INFINITE);

Если отлаживать такой минидамп VS-дебаггером, то мы увидим точку внутри глобального перехватчика. Стек точки в глобальном перехватчике не имеет смысла. Конечно можно посмотреть свойства переменной _EXCEPTION_POINTERS прямо в процессе отладки и увидеть адрес падения, но это не то. Как указать VS-дебаггеру подцепить _EXCEPTION_POINTERS и показать нормальный стек вызовов и переменные??

Объясню почему этот вопрос так интересен. Во первых такой дамп проще создать. Во вторых в составе Steam идёт программа WriteMinidump.exe, которая делает дамп любого процесса по его PID, в полном или сокращённом режиме. Что-то мне подсказывает что в Valve не дураки сидят и явно от такого дампа можно добиться многого.