-1

I am throwing an exception throw std::exception("dummy") (as a test) which is not being caught anywhere.
Without ProcDump attached this immediately crashes the process as it should.

When I attach ProcDump with -e to a debug build, ProcDump properly detects the unhandled exception, creates a crash dump, and exits. But the program continues executing as if the exception has never been thrown.

I could manually crash the process after ProcDump exits but I really don't like the idea that code continues to run after a crash that is supposed to be fatal even if it is just for a few ms.

What causes this? How can I make sure that my program crashes (and the crash dump properly represents the point of the crash)? Is this an issue with ProcDump or with how I am using it?

Here is a minimal example to reproduce this:

#include <iostream>

int main() {
    char c;
    std::cin >> c;
    if (c == 'e')
        throw std::exception("dummy");
    std::cout << "clean exit" << std::endl;
    return 0;
}

I've tried it with m$ clang-cl and msvc. I've tried every single ProcDump switch even vaguely relevant to my issue in all possible combinations with multiple binaries.

E_net4
  • 27,810
  • 13
  • 101
  • 139
Ramon
  • 424
  • 2
  • 9
  • 24
  • According to the docs `-k` kills the process when it dumps. – stark Jul 23 '21 at 12:26
  • I should've mentioned this in the question. `Kill after dump is only valid with AeDebug Just-in-Time support (-i).` I really don't want to mess with post-mortem debugging. – Ramon Jul 23 '21 at 12:50

2 Answers2

1

I don't have a good answer, unfortunately. It looks that there is a bug in procdump. You may report it on the Sysinternals forum or contact Mark Russinovich (@markrussinovich) or Andrew Richards (@arichardmsft). I can confirm that it happens when you attach to the process, for example, procdump -e prog. It behaves as expected when you run the app under procdump (procdump.exe -e -x . prog.exe). Procdump runs as a debugger attached to a process, so it might 'swallow' exceptions. Of course, it should not, but the API allows it to do so.

As an alternative, before procdump gets fixed, you may consider using minidumper (I contributed to it in the past). It does not have as many command-line options as procdump, but the -e option works as expected, for example, MiniDumper.exe -ma -e2 12824.

Internally, minidumper has a very similar design to procdump and also implements a debugger engine. Here is the line handling the exception event: https://github.com/goldshtn/minidumper/blob/master/MiniDumper/Debugger.cs#L106.

Sebastian
  • 3,764
  • 21
  • 28
0

Try using the -k option on ProcDump.

Ollie
  • 428
  • 2
  • 9
  • 26
c016Y
  • 1
  • 1
    I recommend against rhetoric questions in answers. They risk being misunderstood as not an answer at all. You are trying to answer the question at the top of this page, aren't you? Otherwise please delete this post. – Yunnosch Oct 06 '22 at 14:37
  • 1
    I've submitted an edit to avoid possible misunderstanding, but please edit your answer to explain exactly how that would help – Ollie Oct 06 '22 at 15:42
  • Furthermore, just skimming over the help print of procdump without actually properly reading it and giving a sarcastic question answer is not only factually wrong but just impertinent and rude and doesn't belong on this platform to begin with. As the accepted answer already confirmed the problem I described is a bug in the software (which still exists to this day btw) and not a user error. – Ramon Oct 10 '22 at 12:05