This action might not be possible to undo. Are you sure you want to continue?
point. When execution is suspended at a breakpoint, your program is said to be in break mode. MSVS debugger enables you to set properties that modify the behavior of a breakpoint: Hit Count enables you to determine how many times the breakpoint is hit before the debugger breaks execution. Condition is an expression that determines whether the breakpoint is hit or skipped. Action specifies something that should occur when the breakpoint is hit. Filter provides a way to specify a process or thread for the breakpoint. Practical Debugging Use dialog boxes or web pages to display the errors Use internal print redirectors Use event logs Use tracing Establish event hooks / memory profilers Use try-catch blocks
Setting the Execution Point
Start (F5) If you choose Start, your application starts up and runs until it reaches a breakpoint. You can break execution at any time to examine values, modify variables, and otherwise examine the state of your program. Step Into (F10)/Over (F11)/Step Out (Shift + F11) If you choose Step Into or Step Over, your application starts and executes then breaks on the first line. Run to Cursor If you choose Run to Cursor, your application starts and runs until it reaches a breakpoint or the cursor location, whichever comes first. You can set the cursor location in a source window. If you are debugging multiple programs, a breakpoint or Break All command affects all programs being debugged by default. If you want to terminate attached processes, you can terminate a single process from the Processes window or terminate all attached process with the Terminate All command Overview of Debuggers KD – Kernel debugger. You want to use this to remote
CDB – Command-line debugger. This is a console application. NTSD – NT debugger. This is a user-mode debugger that you can use to debug your user-mode applications. Effectively, this is Windows-style UI added to CDB. Windbg – wraps KD and NTSD with a decent UI. WinDbg can function both as a kernel-mode and user-mode debugger. Visual Studio, Visual Studio .NET – use the same debugging engine as KD and NTSD and offer richer UI than WinDbg for debugging purposes.
debug OS problems like blue screens. You want it if you develop device drivers.
Using Dump Files Dump files, previously called crash dumps, allow you to save program information for debugging at a later time.
On the Debug menu, click Save Dump As. In the Save Dump As dialog box, select Minidump or Minidump with Heap from the Save as type list box.
You can take snapshot information of a process using the dump facility. A mini-dump is usually small, unless you take a full-memory minidump (.dump /mf). It is useful to dump handle information also, as .dump/mfh. A mini-dump contains information about all threads including their stacks and list of loaded modules. A full dump contains more information, like that of the process heap. > Execution Control Starting (or Continuing) Execution Breaking Execution Stopping Execution Stepping Through Your Application Running to a Specified Location
is a debugger that wraps NTSD and KD with a better UI. It provides command-line options like starting minimized (-m), attach to a process by pid (-p) and auto-open crash files (-z). It supports three types of commands:
regular commands (e.g.: k). The regular commands are to debug processes. dot commands (e.g.: .sympath). The dot commands are to control the debugger. extension commands (e.g.: !handle) – these are custom commands that you can add to WinDbg; they are implemented as exported functions in extension DLLs.
Crash Dump Analysis
If your Windows OS crashes, it dumps the physical memory contents and all process information to a dump file, configured through System->Control Panel->Advanced>’Startup and Recovery’. It is also possible to take dumps
of any live process by breaking into it. You can also take a dump of any process (.dump) that terminates abnormally by configuring WinDbg as a JIT debugger. Note that figuring out bugs in the code from a crash dump could be an involved process.
To analyze a dump, follow these steps:
Step 1: In WinDbg, File->’Open Crash Dump’, and point to the dump file Step 2: WinDbg will show you the instruction your app was executing when it crashed. Step 3: Set your symbol path and source path properly.
The existence of multiple processes enables a computer to perform more than one task at a time. The existence of multiple threads enables a process to break down work to be performed in parallel. On a machine with multiprocessors, processes or threads can run on different processes, enabling true parallel processing.
Synchronization Processing & Deadlocks
Perfect parallel processing is not always possible. Threads sometimes need to be synchronized. One thread may need to wait for a result from another thread, or one thread may need exclusive access to a resource that another thread is using. Synchronization problems are a common cause of bugs in multithreaded applications. Sometimes threads may end up waiting for a resource that never becomes available, resulting in a condition called deadlock.
Using Breakpoints Breakpoints - A breakpoint is a signal that tells the debugger to temporarily suspend execution of your program at a certain point. When execution is suspended at a breakpoint, your program is said to be in break mode. MSVS debugger enables you to set properties that modify the behavior of a breakpoint: Hit Count enables you to determine how many times the breakpoint is hit before the debugger breaks execution. Condition is an expression that determines whether the breakpoint is hit or skipped. Action specifies something that should occur when the breakpoint is hit. Filter provides a way to specify a process or thread for the breakpoint. Exceptions Visual Studio debugger recognizes the following categories of exceptions:
C++ exceptions Common language runtime exceptions Managed debugging assistants Native run-time checks Win32 exceptions
The primary tools for working with threads and processes in Visual Studio are the Attach to Process dialog box, the Processes window, and the Threads window.
Attach to Process Dialog Box Available Processes you can attach to: Process name (.exe) Process ID number Menubar Title Type (managed, x86, x64, IA64) User Name (account name) Session number Attached Processes: Process Name Process ID number Path to process .exe Menubar Title State (Break. Running) Debugging (Native, Managed, and so on.) Transport type (default, native with no authentication , Smart Devices) Transport Qualifier (remote machine) Threads in current process: Thread ID Thread Name Location (such as wmain) Priority Suspend level Select a process to attach to. Select a remote machine. Change transport type for connecting to remote machines
Tools: Attach Detach Terminate Shortcut menu: Attach Detach Detach when debugging stopped Terminate
Most exceptions have handlers that are designed to respond to an exception when it occurs, giving the program a chance to recover from the abnormal situation. Native run-time checks do not have handlers.
THREADS & PROCESSES
Threads and processes are related concepts in computer science. Both represent sequences of instructions that must execute in a specific order. Instructions in separate threads or processes, however, can execute in parallel. Processes exist within the operating system and correspond to what users see as programs or applications. A thread, on the other hand, exists within a process. For this reason, threads are sometimes called light-weight processes. Threads Window
Shortcut menu: Switch to thread Freeze a running thread Thaw frozen thread
Without symbols, callstacks tend to be nothing more than a list of function pointers in memory. A developer has to load the un-stripped executable in memory using the same operating system and similar processor to jump to that memory address in order to determine the function name and parameters. This is very labor intensive and generally not a very fun job. Microsoft created a technology called a 'Symbol Store' to use with their debugger technology which allows Windows debuggers to locate and download compressed symbol files to diagnose problems and convert function pointers into human readable text. This greatly speeds up the process of diagnosing and fixing bugs.
Call Stack - A call stack is often used for several related purposes, but the main reason for having one is to keep track of the point to which each active subroutine should return control when it finishes executing. Using the Call Stack window, you can view the function or procedure calls that are currently on the stack.
The Call Stack window displays the name of each function and the programming language it is written in. The function or procedure name may be accompanied by optional information, such as module name, line number, byte offset, and parameter names, types, and values. The display of this o
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.