When I open a minidump I get some basic information about the crash:
I can't tell which thread crashed. Is there some indicator in the interface that shows which thread crashed or other way to determine for sure which thread generated the exception?
I suspect that the debugger will take me to the correct location of the crash when I start debugging (assuming that it was able to load all of the correct symbols, etc.), but it's difficult to know for sure without some kind of confirmation.
I can't tell for sure regarding the Express edition. Usually there's an actions box where you can start debugging.
If you do that, it will show you the call stack and threads including the thread ID:
However, it might not be available with the Express edition of Visual Studio (source), so I suggest you do the following:
Get a copy of WinDbg, Microsoft's free debugger. Most convenient way is to download from Codemachine.
Install it, then run WinDbg.
Enter the !analyze -v command. It should give you the exception code, call stack and thread ID.
Just for the sake of completeness, the yellow arrow shows the currently selected thread. It's the outline one that shows the thread where the debugger is currently stopped (or crashed in the case of a dump file):
Also, the last number in the dump file name appears to be the id of the thread that crashed.
I have a crashdump created by DrWatson, the exception code is 0x80000007 STATUS_WAKE_SYSTEM_DEBUGGER and the message is "{Kernel Debugger Awakened} The system debugger was awakened by an interrupt." (from here: 2.3.1 NTSTATUS values http://msdn.microsoft.com/en-us/library/cc704588(v=prot.10).aspx )
I cannot find any documentation about it. What is its meaning?
A quick trip to Google brought up this forum post. Basically some DLL crashed inside DllMain and thus the loader lock was abandoned. The injected thread that the debugger creates then gets stuck during its DllMain(THREAD_ATTACH) call. After some time, the operating system uses a "wake debugger" approach and that is what the debugger ends up seeing instead of the original exception. Sounds plausible.
I want to know the current state(SUSPENDED/READY/RUNNING/WAITING state ) of a thread which has been created by CreateThread() api.
How can I find it out?
My developement environment is Visual studio 2008 Expresss edition
also language is C/C++
/renjith g
As has been previously answered :-
Check if a Win32 thread is running or in a suspended state
APIs that provide this information are not provided because the information they return is stale before they return.
If you want to know if a thread is suspended - call SuspendThread. Now you know (a) the thread has a suspend count of at least 1, and, as SuspendThread returns the 'previous' suspend count, you can know that, at some point during the call to SuspendThread, the suspend count was 0, or some number.
The same logic holds for testing if a thread is "stuck" in WaitForXObject(s) :- until you've stopped the thread, you can't know the answer to that question safely.
You may find this Thread Status Monitor (free) useful for viewing the state of threads in your app.
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.
I keep wondering how does a debugger work? Particulary the one that can be 'attached' to already running executable. I understand that compiler translates code to machine language, but then how does debugger 'know' what it is being attached to?
The details of how a debugger works will depend on what you are debugging, and what the OS is. For native debugging on Windows you can find some details on MSDN: Win32 Debugging API.
The user tells the debugger which process to attach to, either by name or by process ID. If it is a name then the debugger will look up the process ID, and initiate the debug session via a system call; under Windows this would be DebugActiveProcess.
Once attached, the debugger will enter an event loop much like for any UI, but instead of events coming from the windowing system, the OS will generate events based on what happens in the process being debugged – for example an exception occurring. See WaitForDebugEvent.
The debugger is able to read and write the target process' virtual memory, and even adjust its register values through APIs provided by the OS. See the list of debugging functions for Windows.
The debugger is able to use information from symbol files to translate from addresses to variable names and locations in the source code. The symbol file information is a separate set of APIs and isn't a core part of the OS as such. On Windows this is through the Debug Interface Access SDK.
If you are debugging a managed environment (.NET, Java, etc.) the process will typically look similar, but the details are different, as the virtual machine environment provides the debug API rather than the underlying OS.
As I understand it:
For software breakpoints on x86, the debugger replaces the first byte of the instruction with CC (int3). This is done with WriteProcessMemory on Windows. When the CPU gets to that instruction, and executes the int3, this causes the CPU to generate a debug exception. The OS receives this interrupt, realizes the process is being debugged, and notifies the debugger process that the breakpoint was hit.
After the breakpoint is hit and the process is stopped, the debugger looks in its list of breakpoints, and replaces the CC with the byte that was there originally. The debugger sets TF, the Trap Flag in EFLAGS (by modifying the CONTEXT), and continues the process. The Trap Flag causes the CPU to automatically generate a single-step exception (INT 1) on the next instruction.
When the process being debugged stops the next time, the debugger again replaces the first byte of the breakpoint instruction with CC, and the process continues.
I'm not sure if this is exactly how it's implemented by all debuggers, but I've written a Win32 program that manages to debug itself using this mechanism. Completely useless, but educational.
In Linux, debugging a process begins with the ptrace(2) system call. This article has a great tutorial on how to use ptrace to implement some simple debugging constructs.
If you're on a Windows OS, a great resource for this would be "Debugging Applications for Microsoft .NET and Microsoft Windows" by John Robbins:
http://www.amazon.com/dp/0735615365
(or even the older edition: "Debugging Applications")
The book has has a chapter on how a debugger works that includes code for a couple of simple (but working) debuggers.
Since I'm not familiar with details of Unix/Linux debugging, this stuff may not apply at all to other OS's. But I'd guess that as an introduction to a very complex subject the concepts - if not the details and APIs - should 'port' to most any OS.
I think there are two main questions to answer here:
1. How the debugger knows that an exception occurred?
When an exception occurs in a process that’s being debugged, the debugger gets notified by the OS before any user exception handlers defined in the target process are given a chance to respond to the exception. If the debugger chooses not to handle this (first-chance) exception notification, the exception dispatching sequence proceeds further and the target thread is then given a chance to handle the exception if it wants to do so. If the SEH exception is not handled by the target process, the debugger is then sent another debug event, called a second-chance notification, to inform it that an unhandled exception occurred in the target process. Source
2. How the debugger knows how to stop on a breakpoint?
The simplified answer is: When you put a break-point into the program, the debugger replaces your code at that point with a int3 instruction which is a software interrupt. As an effect the program is suspended and the debugger is called.
Another valuable source to understand debugging is Intel CPU manual (Intel® 64 and IA-32 Architectures
Software Developer’s Manual). In the volume 3A, chapter 16, it introduced the hardware support of debugging, such as special exceptions and hardware debugging registers. Following is from that chapter:
T (trap) flag, TSS — Generates a debug exception (#DB) when an attempt is
made to switch to a task with the T flag set in its TSS.
I am not sure whether Window or Linux use this flag or not, but it is very interesting to read that chapter.
Hope this helps someone.
My understanding is that when you compile an application or DLL file, whatever it compiles to contains symbols representing the functions and the variables.
When you have a debug build, these symbols are far more detailed than when it's a release build, thus allowing the debugger to give you more information. When you attach the debugger to a process, it looks at which functions are currently being accessed and resolves all the available debugging symbols from here (since it knows what the internals of the compiled file looks like, it can acertain what might be in the memory, with contents of ints, floats, strings, etc.). Like the first poster said, this information and how these symbols work greatly depends on the environment and the language.