Development/Tutorials/Debugging/Debugging on MS Windows: Difference between revisions

    From KDE TechBase
    No edit summary
    Line 16: Line 16:
    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 [http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx windbg debugger].  The latter could be set as jit-debugger by running 'windbg -I' command.
    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 [http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx windbg debugger].  The latter could be set as jit-debugger by running 'windbg -I' command.


    {{Note|For example, you can set 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.}}
    '''Note:''' For example, you can set 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.
    {{Note|'''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]). Either start applications and klauncher without administration permissions or attach the debugger manually before the debugger will catch unhandled exceptions or user break points (__debugbreak). '''The second solution will be possible as soon as we add a way to allow the user to manually attach (perhaps by displaying a message box)...'''}}
    '''Note (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]). Either start applications and klauncher without administration permissions or attach the debugger manually before the debugger will catch unhandled exceptions or user break points (__debugbreak). '''The second solution will be possible as soon as we add a way to allow the user to manually attach (perhaps by displaying a message box)...'''


    You may inspect kioslave sources [http://lxr.kde.org/source/KDE/kdelibs/kinit/kioslave.cpp] for more informations.
    You may inspect kioslave sources [http://lxr.kde.org/source/KDE/kdelibs/kinit/kioslave.cpp] for more informations.

    Revision as of 14:55, 31 January 2008

    General Hints

    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). The tool offers searching in logs, filtering and saving them to file.

    More informations

    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.

    To debug kioslaves:

    1. 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.
      set KDE_SLAVE_DEBUG_WAIT=file
    2. Terminate klauncher process so it can be restarted.
    3. 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 taht in the environment as well, e.g. for MSVC Express, by typing vcepress.

    If the kioslave is requested the next time, a debugger will be started and attached to the kioslave process immediatly before the kioslave's kdemain() function.

    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 windbg debugger. The latter could be set as jit-debugger by running 'windbg -I' command.

    Note: For example, you can set 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. Note (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 (msdn link). Either start applications and klauncher without administration permissions or attach the debugger manually before the debugger will catch unhandled exceptions or user break points (__debugbreak). The second solution will be possible as soon as we add a way to allow the user to manually attach (perhaps by displaying a message box)...

    You may inspect kioslave sources [1] for more informations.

    MS Visual Studio hints

    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.

    • compile and working executable version of your appliation (compiled in debug mode)
    • run msvc environment
    • execute File->Open project
    • pick your exe file in the file window
    • you can set command line arguments as usual, by pick Project->...Properties command and enter all of them it in Command Arguments field
    • if you have libraries placed in other directories than your application's .exe file, and you want to step into these libraries' source code while debugging, pick Project->...Properties command and enter paths to these directories in Symbol Path field
    • hit F5 to run the application start the application or F10 to start step by step
    • all debugging functions like setting breakpoints will be available, so you can open source code in the integrated editor and press F9 where needed
    • you can even edit your source code but to compile it, do it with your external, command line tools. You cannot compile the application in the msvc environment because you have not defined a project file
    • before compiling your application, stop debugging session to unlock binaries; no need to close msvc window
    • after compilation you can start debugging again
    • on exit you will be asked to save .sln file (so-called solution file) with your debugging session -- do it and you will be able just to click the .sln file to start your debugging again
    • it's recommended to save the .sln file in the .exe file directory
    • 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

    Attaching to running application

    If you have your application is already running, you can attach to it and then start debugging.

    • run msvc environment
    • execute Debug->processes
    • 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
    • your program will stop on any breakpoint you have set

    One-step attaching to running application

    You can create a macro that automates the task. See [2].

    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
    • 0xDDDDDDDD - Released heap memory.
    • 0xFDFDFDFD - "NoMansLand" fences automatically placed at boundary of heap memory. Should never be overwritten. If you do overwrite one, you're probably walking off the end of an array.
    • 0xCCCCCCCC - Allocated on stack, but not initialized

    See also: [3]

    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) instruction for various msvc versions.

    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." (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 definitions after [AutoExpand] line.

    MinGW hints

    • Dr. Mingw - Just in Time Debugger [4]
    • Debugging Qt programs on Windows [5]