1

I have an executable which calls a DLL. I can step through DLL code by attaching VS2008 project of DLL to process of executable. I debugged some errors/exceptions already. But now, exactly when main function of DLL returns, executable process crashes without any error/exception. To debug the crash, I tried to use crash-dump file, but based on this link, looks like they don't work with VS2008.

What possible tools can I use to debug the crash?

EDIT:

process calls this when dying: 

TerminateProcess(GetCurrentProcess(), STATUS_INVALID_CRUNTIME_PARAMETER);
Community
  • 1
  • 1
Megidd
  • 7,089
  • 6
  • 65
  • 142
  • 1
    Are you using managed 9.Net) code or native? The C++ tags suggests native, but you link to a question about managed code. Also, what exactly is a "crash"? That's not a technical term. If your process just calls `TerminateProcess` for whatever reason, it silently goes away but that's not a true crash. – MSalters Mar 19 '15 at 13:17
  • 1
    Crash dumps can be used with VS 2008. `when main function of DLL returns, executable process crashes without any error/exception`. When debugging, the "Output Window" in Visual Studio lets you know what the return value and/or unhandled exception is. VS doesn't leave you with no information. – PaulMcKenzie Mar 19 '15 at 13:19
  • @MSalters process calls this: `TerminateProcess(GetCurrentProcess(), STATUS_INVALID_CRUNTIME_PARAMETER);` Does it mean process goes away or is it a true crash? I'm not sure. – Megidd Mar 19 '15 at 13:37
  • @user3405291: That's the kind of details that you should have put in the question originally. – MSalters Mar 19 '15 at 13:39

1 Answers1

1

TerminateProcess(GetCurrentProcess(), STATUS_INVALID_CRUNTIME_PARAMETER); is a strong indication that the runtime library terminated your process because you passed a bad parameter to a library function. And "bad" was so bad that it couldn't reasonably continue. You're probably not looking at something as trivial as sqrt(-1.0), but perhaps strlen(NULL) or std::sort(... , &std::equal<int>)

[edit] To find the root cause, it can help to provide a invalid_parameter_handler)(. In it, call __debugbreak to invoke the debugger. The stack trace will now show the cause.

MSalters
  • 173,980
  • 10
  • 155
  • 350
  • I wonder why my bad parameter is not causing any error/exception message. – Megidd Mar 19 '15 at 14:23
  • Visual Studio Just-In-Time Debugger call-stack implies that a bad parameter is passed to `fscanf` and then consequently `vfscanf`. Considering crash happens exactly when DLL returns, I'm not sure if bad call to `fscanf` is inside DLL or executable. Is there any approach to realize that? – Megidd Mar 19 '15 at 15:53
  • 1
    Well, that's potentially a good reason for a library to call `TerminateProcess`. You pass a pointer to ` fscanf` and say "put the result here". Passing a bad pointer could very well cause random data to be overwritten, with unpredictable consequences. This kind of problem has lead to security bugs in the past, which justifies a quick exit. A dead process no longer is a security risk. – MSalters Mar 19 '15 at 16:39
  • I implemented `_set_invalid_parameter_handler` and `__debugbreak()` inside source code of DLL but it couldn't invoke debugger. I feel like bad parameter of `fscanf` happens in executable (which I don't have its source code). It makes sense to me because crash happens just after main function of DLL returns. – Megidd Mar 19 '15 at 19:12