1

I would like to replace any standard error-dialog with throw or debug-break (with standard I mean anything which is not explicitly written by me) since like in the reason-section described, it would cause debugging of a Windows-Service sometimes to be impossible.

to accomplish this I did try defining something like:

-D "_HAS_ITERATOR_DEBUGGING=0"

but above did just disable the error-dialogs and is really not enough to track down the issues, so I would like it to throw-exception or to debug-break instead of showing the error-dialog.

is there anything else you would suggest me to define or do?

Reason:

While developing a Windows-Service, I had some hard times to find a bug which was causing the server to crash:

  • there was an Off-by-one error in std::unordered_map usage
  • the App's crash-dump feature was prevented by std::unordered_map which tried to show an error message-box (since compiled in debug-mode)
  • but the program did crash without giving any feedback, basically because a windows-service is not allowed to show any error-dialog (except by using "WTSSendMessage(...)")
  • even when the debugger was attached, still nothing...
  • Only using git history and rechecking all recent changes was it possible to find the issue

Reproduce:

by running below in a service (compiled in debug-mode) you can reproduce this issue:

#include <unordered_map>

// will cause crash by trying to increment iterator pointing to end
inline static void simulateCrash() {
    typedef std::unordered_map<quint32, quint32> Hash;
    Hash list;
    list[0xC001] = 0xDEAD;
    Hash::iterator it = list.begin();
    it = list.erase(it);
    ++it; // should crash here
}
Top-Master
  • 7,611
  • 5
  • 39
  • 71
  • 1
    Do you compile in release or debug ? `_HAS_ITERATOR_DEBUGGING` is compiler specific BTW, you would have `NDEBUG` which is standard (for `assert`)... – Jarod42 Feb 27 '19 at 10:25
  • _"the App's crash-dump feature was prevented by std::unordered_map which tried to show a message-box"_ <-- this is suspicious. – YSC Feb 27 '19 at 10:30
  • 2
    BTW, UB would not necessary crash (or crash the way expected by your crash-dump). – Jarod42 Feb 27 '19 at 10:30
  • your guess is right I was compiling in debug mode while trying to fix the issue, but I want to disable any error-dialog even when compiling in debug mode since that is not allowed in Windows-Service anyway... – Top-Master Feb 27 '19 at 10:58
  • @Jarod42, I have edited the question, since indeed disabling the error-dialog did just hide the issue from our view (since it did not cause any crash or exception-throw) – Top-Master Feb 28 '19 at 04:14
  • So you might customize error handler as I suggest in my answer. if you throw from the handler (which is a C-function, you probably need to change also some build option (`/EH`)). – Jarod42 Feb 28 '19 at 09:18

1 Answers1

2

You probably want to use _set_invalid_parameter_handler to overwrite default handler which terminates the program and displays a runtime error message.

_CrtSetReportMode is also useful to avoid dialog from _CrtDbgReport (used in several checks).

Jarod42
  • 203,559
  • 14
  • 181
  • 302
  • thanks, by using `_set_invalid_parameter_handler` (with a custom-handler which throws an exception) and undoing my changes to `_HAS_ITERATOR_DEBUGGING` macro, at last the crash-dump does work !!! – Top-Master Feb 28 '19 at 11:28
  • at the time that the issue happened we were unable to attach any debugger anyway (so crash-dump was our only option) – Top-Master Feb 28 '19 at 11:31