Development/Tutorials/Debugging/Debugging on MS Windows - Revision history

SaroEngels: /* General Hints */

2011-09-09T08:50:03Z

‎General Hints

Icwiener: Fix syntax highlighting.

2011-06-27T16:09:02Z

Fix syntax highlighting.

Aheinecke: Update link to mingw gdb

2011-04-04T08:46:00Z

Update link to mingw gdb

SommerLuk: Correct level of titles

2010-08-30T08:56:17Z

Correct level of titles

Jstaniek: /* One-step attaching to running application */

2009-08-22T11:37:49Z

‎One-step attaching to running application

Jstaniek: /* Attaching to running application */

2009-08-22T11:34:44Z

‎Attaching to running application

Jstaniek: /* Enable automatic expanding of Qt data structures */

2009-08-22T11:04:35Z

‎Enable automatic expanding of Qt data structures

Jstaniek: /* One-step attaching to running application */

2009-08-22T11:02:34Z

‎One-step attaching to running application

Jstaniek: /* Using MS Visual Studio environment for just debugging */

2009-08-22T11:00:24Z

‎Using MS Visual Studio environment for just debugging

Jstaniek: /* One-step attaching to running application */

2009-08-22T10:59:57Z

‎One-step attaching to running application

@@ Line 5: / Line 5: @@
 ===Debugging with DebugView===
 Debug messages (logs) generated by kDebug() and kWarning() are not visible on MS Windows unless application is compiled in so-called CONSOLE subsystem. To show these messages also in WINDOWS subsystem, you can use DebugView tool, coming from SysInternals (currently acquired by Microsoft). [[Projects/KDE_on_Windows/Tools#DebugView|more...]]
 ===Debugging kioslaves===

@@ Line 11: / Line 11: @@
 ==== Using KDE_SLAVE_DEBUG_WAIT variable ====
 To debug kioslaves:
-#Set the KDE_SLAVE_DEBUG_WAIT environment variable in a current cmd.exe shell to the name of the kioslave's protocol (the first parameter of KIO::SlaveBase() constructor), e.g.<pre>set KDE_SLAVE_DEBUG_WAIT=file</pre>
+#Set the KDE_SLAVE_DEBUG_WAIT environment variable in a current cmd.exe shell to the name of the kioslave's protocol (the first parameter of KIO::SlaveBase() constructor), e.g. <tt>set KDE_SLAVE_DEBUG_WAIT=file</tt>
 #Terminate <tt>klauncher</tt> process so it can be restarted.
 #Any application you want to debug at kioslave level have to be executed within the scope of the current environment (cmd.exe), what also means that if you want to use development environment, you have to do that in the environment as well, e.g. for MSVC Express, by typing <tt>vcexpress</tt>.
@@ Line 84: / Line 84: @@
 From the msvc docs: "While debugging, Data Tips and items in the Watch and Variable windows are automatically expanded to show their most important elements. The expansion follows the format given by the rules in this file. You can add rules for your types or change the predefined rules." ([http://www.thedatafarm.com/blog/content/binary/datatips2.jpg example screen])
-MSVC 2005: To add support for expanding Qt data structures like QString of QRect, edit {msvc_installation_directory}\Common7\Packages\Debugger\autoexp.dat file and paste [[/Automatic expanding of Qt data structures|definitions]] after [AutoExpand] line.
+MSVC 2005: To add support for expanding Qt data structures like QString of QRect, edit <tt>{msvc_installation_directory}\Common7\Packages\Debugger\autoexp.dat</tt> file and paste [[/Automatic expanding of Qt data structures|definitions]] after [AutoExpand] line.
 MSVC 2008: You can improve:
@@ Line 93: / Line 93: @@
 ===WINDOWS and CONSOLE subsystems===
 CONSOLE subsystem is the one that displays console window (used for standard output and error streams) in addition to application's windows. WINDOWS subsystem redirects standard output and error streams to system debugging subsystem that can be displayed if needed in [[Projects/KDE_on_Windows/Tools#DebugView|DebugView]] or debuggers like msvc or [[Projects/KDE_on_Windows/Tools#WinDbg|WinDbg]].
-Hint: To remove CONSOLE subsystem from already built .exe file, type <code>editbin /subsystem:windows file.exe</code>
+Hint: To remove CONSOLE subsystem from already built .exe file, type <tt>editbin /subsystem:windows file.exe</tt>
 Note: Qt's qmake syntax supports ''console'' and ''windows'' parameters of the ''CONFIG'' variable, so CONSOLE subsystem can be enabled by specifying <tt>CONFIG += console</tt> in the .pro file, windows subsystem can be enabled with <tt>CONFIG += windows</tt>.
@@ Line 108: / Line 108: @@
 To get a backtrace for a crash you can reproduce: Start the gdb binary with the full path to the executable on the command line, for example like
-<code>..\gdb\gdb.exe c:\programme\kontact\bin\kontact.exe</code>. When getting
+<tt>..\gdb\gdb.exe c:\programme\kontact\bin\kontact.exe</tt>. When getting
-the command prompt use the run command with the arguments for your application, e.g <code>run --nofork</code>. Now wait until your applications starts and go on reproducing the crash. Once you encounter the crash, gdb will be in control
+the command prompt use the run command with the arguments for your application, e.g. <tt>run --nofork</tt>. Now wait until your applications starts and go on reproducing the crash. Once you encounter the crash, gdb will be in control
-in the command line again. <code>bt</code> will get you the backtrace.
+in the command line again. <tt>bt</tt> will get you the backtrace.
-Instead of running gdb from the beginning, you can also attach to a running process. Use the regular "task-manager" to see which process. Enable the process id columns so you can see the number. Now you can start gdb (still give it the path to the application executable if you can) and use the <code>attach</code> command with the process id you want to attach to from the
+Instead of running gdb from the beginning, you can also attach to a running process. Use the regular "task-manager" to see which process. Enable the process id columns so you can see the number. Now you can start gdb (still give it the path to the application executable if you can) and use the <tt>attach</tt> command with the process id you want to attach to from the
-gdb prompt. Gdb will stop the process it attached to, so you can say <code>continue</code> and then try to produce the crash.
+gdb prompt. Gdb will stop the process it attached to, so you can say <t>continue</tt> and then try to produce the crash.
 * Dr. Mingw - Just in Time Debugger [http://jrfonseca.planetaclix.pt/projects/gnu-win32/software/drmingw/]
 * Debugging Qt programs on Windows [http://lists.trolltech.com/qt-interest/2005-08/thread01124-0.html]
-'''''WARNING''''': If you are having crashes when starting applications via gdb beware of certain applications (mostly anti-virus software) that could cause problems like "Embassy Trust Suite", for example. See this [http://www.cygwin.com/ml/cygwin/2007-06/msg00405.html post].
+'''''WARNING''''': If you are having crashes when starting applications via GDB beware of certain applications (mostly anti-virus software) that could cause problems like "Embassy Trust Suite", for example. See this [http://www.cygwin.com/ml/cygwin/2007-06/msg00405.html post].
 [[Category:MS Windows]]

@@ Line 105: / Line 105: @@
 There are gdb binaries you can directly run after unpacking them, e.g. from
-[http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=20507 mingw's gdb downloads on sourceforge].
+[http://sourceforge.net/projects/mingw/files/MinGW/BaseSystem/GDB/ mingw's gdb downloads on sourceforge].
 To get a backtrace for a crash you can reproduce: Start the gdb binary with the full path to the executable on the command line, for example like

@@ Line 1: / Line 1: @@
-=General Hints=
+==General Hints==
-==Debugging with WinDbg==
+===Debugging with WinDbg===
 WinDbg, distributed as a part of ''Debugging Tools for Windows'', is a user-mode and kernel-mode debugger with a graphical interface. It can also be used to debug user-mode crash dumps.  It uses the Microsoft Visual Studio debug symbol formats for source-level debugging. [[Projects/KDE_on_Windows/Tools#WinDbg|more...]]
-==Debugging with DebugView==
+===Debugging with DebugView===
 Debug messages (logs) generated by kDebug() and kWarning() are not visible on MS Windows unless application is compiled in so-called CONSOLE subsystem. To show these messages also in WINDOWS subsystem, you can use DebugView tool, coming from SysInternals (currently acquired by Microsoft). [[Projects/KDE_on_Windows/Tools#DebugView|more...]]
-==Debugging kioslaves==
+===Debugging kioslaves===
 kioslaves on windows are started by klauncher (or kio) as separate kioslave processes. The kioslave executable then loads the related kioslave dll dynamically.
-=== Using KDE_SLAVE_DEBUG_WAIT variable ===
+==== Using KDE_SLAVE_DEBUG_WAIT variable ====
 To debug kioslaves:
 #Set the KDE_SLAVE_DEBUG_WAIT environment variable in a current cmd.exe shell to the name of the kioslave's protocol (the first parameter of KIO::SlaveBase() constructor), e.g.<pre>set KDE_SLAVE_DEBUG_WAIT=file</pre>
@@ Line 19: / Line 19: @@
 On mingw platform gdb is launched and connected to the kioslave process. On msvc platforms the currently installed just-in-time debugger is used. This may be msvc's IDE or the [[Projects/KDE_on_Windows/Tools#WinDbg|WinDbg debugger]].  The latter could be set as jit-debugger by running 'windbg -I' command (capital -I like ICE, see [http://msdn2.microsoft.com/en-us/library/cc266343.aspx]).
-=== Using KDE_SLAVE_DEBUG_POPUP variable ===
+==== Using KDE_SLAVE_DEBUG_POPUP variable ====
 Alternatively, you can set <tt>KDE_SLAVE_DEBUG_POPUP</tt> variable instead of <tt>KDE_SLAVE_DEBUG_WAIT</tt>. This will display a native message box so developer you can attach the debugger to the KIO slave process and click OK. No DebugBreak() is invoked. Just click OK without attaching to continue using the KIO slave without debugging.
-=== Notes ===
+==== Notes ====
 *You can set, say, the variable to 'file' for the kio_file slave, '''but''' set it to 'smtps' for the kio_smtp is you want to debug smtp protocol secured with SSL.
 *(Vista only): ''kioslave.exe has stopped working'' message dialog can appear instead of offer for starting the debugger. Reason: Just-In-Time (JIT) Debugging of an elevated process will fail ([http://msdn2.microsoft.com/en-us/vstudio/aa964140.aspx#question20a msdn link]) apparently for security reasons. Either:
@@ Line 29: / Line 29: @@
 *You may want to inspect kioslave sources [http://lxr.kde.org/source/KDE/kdelibs/kinit/kioslave.cpp] for more informations.
-== Checking dependency of shared libraries ==
+=== Checking dependency of shared libraries ===
 Dependency Walker is a free utility that scans any 32-bit or 64-bit Windows module (exe, dll, ocx, sys, etc.) and builds a hierarchical tree diagram of all dependent modules. [[Projects/KDE_on_Windows/Tools#Dependency_Walker|more...]]
-= MS Visual Studio hints =
+== MS Visual Studio hints ==
-== Using MS Visual Studio environment for just debugging ==
+=== Using MS Visual Studio environment for just debugging ===
 Let's assume you're using command line tools (typically CMake) and want to use MS Visual Studio environment for just debugging. You don't need to create msvc project for your KDE application to be able to start debugging.
@@ Line 56: / Line 56: @@
 **You can also use "vcexpress /debugexe <myapplication> <args>".
-== Attaching to running application ==
+=== Attaching to running application ===
 If you have your application is already running, you can attach to it and then start debugging.
@@ Line 66: / Line 66: @@
 * your program will stop on any breakpoint you have set
-== One-step attaching to running application ==
+=== One-step attaching to running application ===
 *You can create a macro that automates the task. See [http://blogs.msdn.com/jimgries/archive/2005/11/30/498264.aspx].
 *MSVC 2008 or later can always attach to the running process when you execute "Start Debugging" command (F5). Just set the "Attach" option to "Yes" in the "Project->[yourapp] Properties" window. <br/>Note that in this case if the process is not present, you will experience "Unable to attach error" message, so you need to start the process intependently of the development environment first. The advantage of this is faster startup of your application.
-== Memory Values ==
+=== Memory Values ===
 If you are using the debug heap, memory is initialized and cleared with special values. Most interesting values are:
 * 0xCDCDCDCD - Allocated in heap, but not initialized
@@ Line 78: / Line 78: @@
 See also: [http://www.samblackburn.com/wfc/technotes/WTN006.htm]
-==How to Not Step Into Functions in the Debugger==
+===How to Not Step Into Functions in the Debugger===
 You'll probably want to avoind stepping into lower-level functions like QString constructors or operators while debugging step-by-step. Here's the detailed (unofficial) [http://blogs.msdn.com/andypennell/archive/2004/02/06/69004.aspx instruction] for various msvc versions.
-==Enable automatic expanding of Qt data structures==
+===Enable automatic expanding of Qt data structures===
 From the msvc docs: "While debugging, Data Tips and items in the Watch and Variable windows are automatically expanded to show their most important elements. The expansion follows the format given by the rules in this file. You can add rules for your types or change the predefined rules." ([http://www.thedatafarm.com/blog/content/binary/datatips2.jpg example screen])
@@ Line 91: / Line 91: @@
 For details read http://eecs.vanderbilt.edu/research/hmtl/wiki/pmwiki.php?n=Knowledge.Qt
-==WINDOWS and CONSOLE subsystems==
+===WINDOWS and CONSOLE subsystems===
 CONSOLE subsystem is the one that displays console window (used for standard output and error streams) in addition to application's windows. WINDOWS subsystem redirects standard output and error streams to system debugging subsystem that can be displayed if needed in [[Projects/KDE_on_Windows/Tools#DebugView|DebugView]] or debuggers like msvc or [[Projects/KDE_on_Windows/Tools#WinDbg|WinDbg]].
 Hint: To remove CONSOLE subsystem from already built .exe file, type <code>editbin /subsystem:windows file.exe</code>
 Note: Qt's qmake syntax supports ''console'' and ''windows'' parameters of the ''CONFIG'' variable, so CONSOLE subsystem can be enabled by specifying <tt>CONFIG += console</tt> in the .pro file, windows subsystem can be enabled with <tt>CONFIG += windows</tt>.
-==Deployment==
+===Deployment===
 Running a VC++2005 SP1 app on another computer: manifest files are needed. See [http://www.codeproject.com/KB/cpp/vcredists_x86.aspx] and [http://blogs.msdn.com/nikolad/archive/2005/09/02/460368.aspx].
-===Note on debug builds===
+====Note on debug builds====
 The hints above are for release builds (or ReleaseWithDebugInfo). Moving Debug versions of binaries to other computers is only allowed (and technicallu possible) if you have Express Edition installed there, as there is no redistributable package for Debug versions provided and even the license disallows distribution of any debug binaries (even your own).
-= MinGW debugging hints =
+== MinGW debugging hints ==
 There are gdb binaries you can directly run after unpacking them, e.g. from

@@ Line 68: / Line 68: @@
 == One-step attaching to running application ==
 *You can create a macro that automates the task. See [http://blogs.msdn.com/jimgries/archive/2005/11/30/498264.aspx].
-*MSVC 2008 or later can always attach to the running process (if exists) when you execute "Start Debugging" command (F5). Just set the "Attach" option to "Yes" in the "Project->[yourapp] Properties" window.
+*MSVC 2008 or later can always attach to the running process when you execute "Start Debugging" command (F5). Just set the "Attach" option to "Yes" in the "Project->[yourapp] Properties" window. <br/>Note that in this case if the process is not present, you will experience "Unable to attach error" message, so you need to start the process intependently of the development environment first. The advantage of this is faster startup of your application.
 == Memory Values ==

@@ Line 60: / Line 60: @@
 If you have your application is already running, you can attach to it and then start debugging.
-* run msvc environment
+* run the msvc development environment
-* execute ''Debug->processes''
+* execute ''Debug->Atach to Process''
 * select your from the processes list and click "Attach..."
 * msvc environment will load your .sln file if it exists in the same directory as the .exe file, so your breakpoints set in previous session will be active again

@@ Line 53: / Line 53: @@
 *hints on reopening the debugging session:
 **Next time you will run msvc environment, you can see name of your application's .sln file in ''File->Recent Projects'' submenu - you can click it to load your debugging session.
-**On command line you can type "cd path-to-your-sln-file; <yourfilename>.sln" to execute.
+**On command line you can type "cd path-to-your-sln-file; <yourfilename>.sln".
 **You can also use "vcexpress /debugexe <myapplication> <args>".