From 47dd75a7e7afd8708a5df3b9b3c7f93da4d2f4b7 Mon Sep 17 00:00:00 2001 From: "SND\\strangedev_cp" Date: Tue, 18 Feb 2014 00:30:50 +0000 Subject: [PATCH] [0.2.x] docs: add documentation chapter 3.2, 3.3 and 3.4 git-svn-id: https://pykd.svn.codeplex.com/svn@87302 9b283d60-5439-405e-af05-b73fd8c4d996 --- docs/en/documentation.txt | 42 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/docs/en/documentation.txt b/docs/en/documentation.txt index 8c0f850..81a687d 100644 --- a/docs/en/documentation.txt +++ b/docs/en/documentation.txt @@ -12,6 +12,9 @@ ** [2.3 Console mode|#windbgcommands-consolemode] * [3. Manage debugging|#managedebugging] ** [3.1 Stopping and restarting debugged processed|#managedebugging-stoppingrestarting] +** [3.2 Stepping|#managedebugging-stepping] +** [3.3 Working with Python debugging applications|#managedebugging-debuggingapplications] +** [3.4 Printing debug information|#managedebugging-printingdebuginformation] {anchor:introduction} ! 1. Introduction {anchor:introduction-generalinformation} @@ -197,3 +200,42 @@ Using *breakin()* is hardly needed during normal operation due to the fact that *Attention!* Do not attempt to use breakin() or go() inside debug events such as conditional breakpoints. [←Table of contents|#tableofcontents] +{anchor:managedebugging-stepping} +!! 3.2 Stepping +Stepping (tracing) is served by the two functions +*step()* +*trace()* +These actions are similar to the debugger commands _trace into_ and _trace over_. Both functions can result in a DbgException if the debugged process has already ended. +[←Table of contents|#tableofcontents] +{anchor:managedebugging-debuggingapplications} +!! 3.3 Working with Python debugging applications +If you want to run scripts outside of WinDbg, the first step is to create a debug session. More detailed session management will be discussed in the relevant section. As long as your application does not use multiple debugging sessions, it's not needed to take care of them - the first session will be created automatically with the following calls: +*loadDump(dumpName)* - loads the crash dump +*id=startProcess(imageName)* - runs a new process in debug mode +*id=attachProcess(processId)* - attaches the debugger to an existing process +*attachKernel(parameterStr)* - attaches the debugger to the kernel debugging system + +To detach the debugger from the debugged process call *detachProcess(id)*. +To stop debugging and terminate the debugged process call *killProcess(id)*. + +To find out what you are debugging, use +*isDumpAnalyzing()* +*isKernelDebugging()* +The first function determines whether the debugger is doing live debugging or analysing a memory dump. The second function distinguishes between user mode debugging and kernel mode debugging. If the script is specific to one of those debugging methods, it will be useful to insert such a test at the beginning of the script. Please inform the user that he is trying to run the script in the wrong context. +[←Table of contents|#tableofcontents] +{anchor:managedebugging-printingdebuginformation} +!! 3.4 Printing debug information +To display information on the screen you can use the default Python print method, but it is recommended to use the special functions +*dprint(message, dml = False)* +*dprintln(message, dml = False)* +The second function differs from the first in that it automatically adds a newline. The optional parameter _dml_ includes output of DML. DML is specific to WinDbg and can be considered as very simple HTML. You can turn DML support on or off in WinDbg using _.prefer_dml_. Text formatting can be done using the following tags: +* ... - emphasize +* ... - italics +* ... - underline +* ... - execute a command (similar to in HTML) +Example: +{{ +dprintln("The following command reloads all symbols", True) +dprintln("reload", True) +}} +[←Table of contents|#tableofcontents] \ No newline at end of file