I have a problem where during a call to a 3rd party library routine my process terminates. I am completely unable to catch this in my debugger. This may be related to this question: How can I debug a win32 process that unexpectedly terminates silently?.
When I step over a call into this library, the process being debugged simply terminates. If this termination was due to an unhandled exception or memory access violation, the debugger would have caught it. So my best guess is that the process somehow terminates normally.
What I have tried:
Setting breakpoints on ExitThread and ExitProcess
Setting handlers for unhandled exceptions and invalid paramters ( set_terminate and _set_invalid_parameter_handler)
Changing _set_abort_behavior and _set_error_mode.
Instructing the debugger to stop execution on all thrown exceptions.
But to no avail, none of the handlers are called and none of the breakpoint are triggered.
What I have observed:
When the process crashes, I see two things in the debug output window:
Not related (see update below) I see EEFileLoadException being thrown. A quick google of this exception doesn't give me a clear answer to whar this exception means.
First-chance exception at 0x7656b9bc (KernelBase.dll) in Program.exe: Microsoft C++ exception: EEFileLoadException at memory location 0x0030b5ac..
First-chance exception at 0x7656b9bc (KernelBase.dll) in Program.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000..
First-chance exception at 0x7656b9bc (KernelBase.dll) in Program.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000..
First-chance exception at 0x7656b9bc (KernelBase.dll) in Program.exe: 0xE0434352: 0xe0434352.
When terminating, all threads return the same error code (STATUS_INVALID_CRUNTIME_PARAMETER).
This error code means, as far as I can tell, that one of the c runtime functions has received an invalid parameter and the application is terminated for security reasons.
The thread 'Win32 Thread' (0x12c0) has exited with code -1073740777 (0xc0000417).
The thread 'Win32 Thread' (0xe04) has exited with code -1073740777 (0xc0000417).
The thread 'Win32 Thread' (0x53c) has exited with code -1073740777 (0xc0000417).
The thread 'Win32 Thread' (0x116c) has exited with code -1073740777 (0xc0000417).
The thread 'Win32 Thread' (0x16e0) has exited with code -1073740777 (0xc0000417).
The thread 'Win32 Thread' (0x1420) has exited with code -1073740777 (0xc0000417).
The thread 'Win32 Thread' (0x13c4) has exited with code -1073740777 (0xc0000417).
The thread 'Win32 Thread' (0x40c) has exited with code -1073740777 (0xc0000417).
The thread 'Win32 Thread' (0xc78) has exited with code -1073740777 (0xc0000417).
The thread 'Win32 Thread' (0xd88) has exited with code -1073740777 (0xc0000417).
The thread 'Win32 Thread' (0x16c8) has exited with code -1073740777 (0xc0000417).
The thread 'Win32 Thread' (0xcb8) has exited with code -1073740777 (0xc0000417).
The thread 'Win32 Thread' (0x584) has exited with code -1073740777 (0xc0000417).
The thread 'Win32 Thread' (0x1164) has exited with code -1073740777 (0xc0000417).
The thread 'Win32 Thread' (0x1550) has exited with code -1073740777 (0xc0000417).
The thread 'Win32 Thread' (0x474) has exited with code -1073740777 (0xc0000417).
The program '[5140] Program.exe: Native' has exited with code -1073740777 (0xc0000417).
What I really want to know is what causes this, and optionally; how can I catch this in the debugger?
Update
Regarding the EEFileLoadException, it is in fact thrown before the program makes the call which causes it to terminate, so it is not related to the termination of the process.
Update
I just read that set_terminate does not work in the debugger so that's out of the question. And as noted in my comment, the handlers are managed on a per-thread basis so I don't have access to the relevant handler.
Also, the program most likely crashes in a worker thread which I have no access to so it is difficult to set any breakpoints/handlers at all.
Is there a better way to figure out what goes wrong?
Configure procdump to generate a dump of your process at process termination time. Not sure if VS2010 can open dump files but windbg can. Then dump all the thread stacks and you should see the one causing termination. You will then be able to inspect the stack to find the offending argument.
If your app is foo.exe then run procdump from a command prompt like this:
procdump -ma -t -w foo.exe
-ma indicates full memory dump
-t indicates write dump at process termination
-w indicates to wait for the process to be launched if not already running
Then run you app outside of any debugger. Once it terminates you should see output from procdump indicating that the process has terminates and that it is writing a dump file.
Here's the link to procdump:
http://technet.microsoft.com/en-us/sysinternals/dd996900
Run your application nuder debugger (or attach to a running process), press Ctrl+Alt+E and check the boxes to have debugger stop execution on exception for you.
Every time an exception takes place, debugger will break. You will be able to check thread states/call stack to possibly identify the problem.
Typical reasons for an app to unexpectedly terminate are:
something really posts WM_QUIT message and this instructs the app to close
an exception takes place, and it is not handled (esp. on background thread); the exception traverses call stack up to OS and it does not know what to do with all the stuff and just kills the process
As EEFileLoadException exception takes place and you don't knnow what it is about, you perhaps would want the first thing understand if it is handled or not, if it is actually a fatal thing for your application.
I faced with the same problem before. I just deleted obj file in C# project. And rebuild again and it project worked. Hope this will solve your problem.
Related
I am writing a little tracer using the Win32 Debug Api (not dbgeng). The general flow is:
DEBUG_EVENT event;
WaitForDebugEvent(&event);
...
ContinueDebugEvent(event.pid, event.tid,...)
My question is: How can I switch the debugger to a different thread than the one that reported the current debugging event (event.tid)?
IE Thread A reports an event in WaitForDebugEvent, but I want to continue stepping Thread B.
ContinueDebugEvent documentation on the second parameter says:
The thread identifier of the thread to continue. The combination of process identifier and thread identifier must identify a thread that has previously reported a debugging event.
So I cant pass the id of a different thread.
I know this is possible because you can do it in Visual Studio GUI as well as windbg:
https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/-s--set-current-thread-
When I'm debugging multi thread process in gdb, I meet "[Switching to Thread ~~ (LWP ~~)]". When the thread is changing to other thread, and why? I guess switching can be occurred by interrupt such as breakpoints. Am I right?
Yes, this is gdb notifying you that gdb's notion of the selected thread has changed. This happens if there is some debugging event, like a signal or a breakpoint stop, in a thread other than the one you had last selected.
I have a thread that runs in a dll that I dynamic link with in my main app. Is there a way to wait for all threads in an .exe (including it's loaded dll's) without knowing the thread handle? Windows 7 x64, vc++
The thread is a function that does some processing on a certain file, it is not expected to return anything, it works upon a global class that is modified in certain stages of the thread completion. The thread function calls upon other functions .
I want to wait until the last line of the function is executed.
I never did this myself, but you could probably
create a snapshot using CreateToolhelp32Snapshot
then enumerate the threads using Thread32First and Thread32Next
for each thread ID, use OpenThread to aquire a handle. Make sure that you open the thread with the SYNCHRONIZE privilege so that you can, at last
pass all thread handles to WaitForMultipleObjects to wait for all of them to terminate.
Another solution, assuming that all you want is to stop the main() function from running but not exit the process until any other threads are complete, is to call
ExitThread(GetCurrentThread());
from within main(). If you don't call ExitProcess, either explicitly or by returning from main(), Windows will not exit until the last thread exits.
Note that there is a major problem with doing this, no matter how you approach it: if one of the Windows APIs you use has launched a thread that isn't going to exit, your application won't exit either.
The proper solution is for the DLL itself to contain a shutdown function that waits for its own threads to exit if necessary.
How to detect the process that caused a GPF?
I'm not sure I understand your question. GPF - is the situation where a processor issues an interrupt.
If this happens in the user-mode - it's translated into a SEH exception, which in turn may be handled by the process. If it's not handled - the process "crashes". Means - an ugly message box is displayed and the process is terminated (depending on the settings the process may also be debugged, debug dump generated and etc.)
IF this happens in the kernel-mode - there're two possibilities. If this happened in a context of where exceptions are allowed - SEH exception is raised and handled (similarly to user-mode). If however the exception is not handled, or the context in which GPF happened doesn't allow exceptions - the OS shuts down, displaying the so-called BSOD (blue screen of death).
Now about your question, I see several possibilities:
OS dies, and you want to know which process made the system call which caused the GPF in the kernel mode.
This is possible to discover with kernel debugger attached. You'll also see the driver that caused the error.
The GPF happens in the user-mode inside a process, and it's not handled.
This process will crash, and you'll definitely know which process was that.
The GPS happens inside the process, handled, and the process continues to run. And you want to be notified about this.
For this you can attach to the process with a debugger. Whenever a SEH exception occurs inside a process - the debugger is notified by the OS.
Using ADPlus (in crash dump mode) to generate .dmp files. The final sequence of unhandled exceptions (that produce full memory dump files) is...
1st chance DLL unload: contains thread id's but doesn't contain the StackOverflowException (I wouldn't expect it to since at this point the exception hasn't been thrown yet).
1st chance Stackoverflow: contains thread id's but doesn't contain the StackOverflowException.
1st chance Process Shut Down (shutdown): contains the StackOverflowException but doesn't contain the thread id's.
???
Is there some way, either by configuring ADPlus or by running commands in Windbg, to capture the exception and have access to the thread id's?
In response to Magnus, is there some useful information if the thread id isn't available? Running !threads returns some info, but without both the thread id and the exception, there doesn't seem to be anywhere else to go from there. Running !clrstack seems more useful than running !threads, in this case.
The following post has a little more information on capturing a StackOverflowException, however it was never fully resolved
Help catching StackOverflowException with WinDbg and ADPlus
Have you tried the !thread command in WinDbg during post mortem debugging of your dump file?
Open the second dump and enter the command .ecxr[enter]
Now dds esp[enter]
To continue viewing the callstack just write dds[enter]
[enter]....[enter]....
You will probaby find this thread was in the middle of calling the unloaded DLL.