Debugging Tools for Windows https://docs.microsoft.com/archive/blogs/windbg/feed.xml Updates, tips, and tricks for Debugging Tools for Windows Thu, 20 Jun 2019 04:56:15 GMT en-US hourly 1 Best places to learn more about WinDbg https://docs.microsoft.com/archive/blogs/windbg/best-places-to-learn-more-about-windbg Wed, 19 Jun 2019 21:56:14 GMT https://blogs.msdn.microsoft.com/windbg/?p=945  blogs, so we’re going to be moving around where to find the latest information on WinDbg and our debugging tools. Going forward you’ll be able to find more information about WinDbg at the following places: Thanks, Andy]]> New C++ library for extending the debugger data model https://docs.microsoft.com/archive/blogs/windbg/new-c-library-for-extending-the-debugger-data-model Fri, 22 Mar 2019 14:34:01 GMT https://blogs.msdn.microsoft.com/windbg/?p=925 dbgmodel.h to enable consuming and extending the debugger data model from non-JavaScript extensions. Those COM APIs are fairly verbose so we're publishing a C++ library to enable simplified use of the data model. You can get it through Nuget or GitHub: The readme on GitHub has an overview of the functionality and the basics of how to use it,  and we'll have a hello world sample available on the WinDbg-Sample repo shortly! -Andy]]> WinDbg Preview 1.0.1812.12001 and new extensibility interfaces https://docs.microsoft.com/archive/blogs/windbg/windbg-preview-1-0-1812-12001-and-new-extensibility-interfaces Wed, 19 Dec 2018 11:43:44 GMT https://blogs.msdn.microsoft.com/windbg/?p=905 @aluhrs13. If you have feedback on our samples feel free to open a GitHub issue, or a PR if you want to contribute a fix or change.

Debugger data model C++ header

Last month we released a C++ header, DbgModel.h, as part of the Windows SDK for extending the debugger data model via C++. You can find more information in our official docs - https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/data-model-cpp-overview The main page includes a great overview of how the debugger data model works and how extensions built on the new C++ header, JavaScript, NatVis, and the 'dx' command all inter-op and is work a read for anyone interested on ther internals of the debugger.

New Data Model API Extension

This release includes a new extension that adds some more "API style" features to the debugger data model that can be accessed through the 'dx' command, JavaScript, and the new DbgModel.h header. This extension extensions the data model to include knowledge about assembly and code execution through the Debugger.Utility.Code namespace, and the local file system through the Debugger.Utility.FileSystem namespace. You can find the full docs for these new namespaces and the objects associated with them at: Code File System The main goal of this extension is to improve the API surface available to JavaScript extensions, but all the functionality can be used via 'dx' and LINQ queries, for example: 0:000> dx Debugger.Utility.FileSystem.FileExists("C:\\Users\\aluhrs\\Desktop\\HelloWorld.txt") Debugger.Utility.FileSystem.FileExists("C:\\Users\\aluhrs\\Desktop\\HelloWorld.txt") : false Or 0:000> dx Debugger.Utility.FileSystem.TempDirectory.Files.Count(),d Debugger.Utility.FileSystem.TempDirectory.Files.Count(),d : 110 This can be useful when writing scripts to quickly validate what a method might return in a REPL-like fashion. These extensions are also available in WinDbg and our command-line client in the latest Windows Insider SDK Preview - https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewSDK

Known issues

There are a couple known issues in this release that will be fixed in our next release:
  • Many of the iterable objects returned from properties on the disassembler can only safely be iterated once. It is perfectly fine to, in JavaScript, do: `var operandCount = instr.Operands.Count(); for (var operand of instr.Operands) { … }`. The following will have undefined results: `var operands = instr.Operands; var operandCount = operands.Count(); for (var operand of operands) { … }`.
  • There can be an incorrect flow graph produced from DisassembleFunction for some functions (overlapping basic blocks with incorrect flow links).

Synthetic types extension

With this new API extension, we have a new sample up on our GitHub repo here - https://github.com/Microsoft/WinDbg-Samples/tree/master/SyntheticTypes. This JavaScript extension reads basic C header files and defines synthetic type information for the structures and unions defined in the header. Through the dx command, memory can then be viewed structured as if you had a PDB with type information for those types.

Other change and bug fixes

    • WinDbg Preview will now more intelligently handle bringing source windows or the disassembly window to the foreground when stepping.
    • Re-arranged WinDbgNext's window title to have more important information at the start when kernel debugging.
    • The alternating background contrast in the command window should be slightly more noticeable.
 ]]> New Extensions and Samples GitHub Repo https://docs.microsoft.com/archive/blogs/windbg/new-extensions-and-samples-github-repo Tue, 06 Nov 2018 15:42:45 GMT https://blogs.msdn.microsoft.com/windbg/?p=885 https://github.com/Microsoft/WinDbg-Samples Feel free to leave comments, questions, and suggestions in the comments or open a GitHub issue! -Andy]]> WinDbg Preview 1.0.1810.2001 Release Notes https://docs.microsoft.com/archive/blogs/windbg/windbg-preview-1-0-1810-2001-release-notes Thu, 04 Oct 2018 14:34:02 GMT https://blogs.msdn.microsoft.com/windbg/?p=875 Settings dialog We’ve moved settings to a dialog that can now be accessed from the File menu or the Home ribbon. Right now it just has some basic settings, but we’ll be adding more in the future.

Events and exceptions settings dialog

We've also added a new page to the settings dialog to control how WinDbg Preview handles events and exceptions, the equivalent of the 'sx' commands or WinDbg's event filters dialog. Just hit Settings on the home ribbon, then hit "Events and Exceptions" on the left to manage those.

Improved TTD indexer

Dramatically increased the performance of indexing TTD trace files, making the indexing process much faster (between 2x-10x) while making index files much smaller (~50% smaller). The perf improvements are most noticeable for traces over 4GB in size, or when using a machine with many CPU cores (8+). The new indexer makes it more feasible to debug very large traces (50GB+).

New launch flag for specifying architecture

WinDbg Preview attempts to launch the debugger engine with the correct bitness to the target to better support debugging managed code. There are circumstances where it can't determine the right bitness or you may want to override what it decides. We've added the -debugArch command-line option to do this. Just add -debugArch x86|amd64 to control the architecture of debugger engine.

Other changes and bug fixes

• Fixed a bug that would cause black bars to appear on a fullscreen debugger with a floating window open. • Fixed a bug that would cause symbol options to be cleared unintentionally. • Command history is now preserved when launching from recent targets. • In the data model window, you can now edit values. • Unindexed TTD traces will now be more clear that they're unindexed. • Improved performance of the locals window • Added a ribbon button to save the command window logs to a file. • Added . SelectMany(<projection>) to the default set of LINQ methods.

Known issues

Running WinDbg Preview in a VMWare environment may cause it to attempt to load the incorrect version of DbgHelp. We’re aware of the issue and investigating a fix.]]> WinDbg Preview 1.0.1807.11002 Release Notes https://docs.microsoft.com/archive/blogs/windbg/windbg-preview-1-0-1807-11002-release-notes Thu, 19 Jul 2018 10:41:48 GMT https://blogs.msdn.microsoft.com/windbg/?p=845 Automatic saving and loading of breakpoints One of the biggest feature requests we’ve had for WinDbg Preview is to replace workspaces. We’re starting down that route by enabling the saving and loading of breakpoints. Launching something you’ve debugged previously from the “Recents” tab in the file menu will now load the breakpoints from that session. We’re going to grow this functionality over the next few months to preserve more information across sessions, so tell us what you’d like to see added in the Feedback Hub and the comments below! We currently aren’t saving hardware breakpoints (ba) and other various properties on breakpoints like thread and process specific contexts as well as conditions. We’ll be looking adding those in a future release.

Minor changes and bug fixes

* Added command-line options -x, -xe, -xd, -xn, and -xi for controlling the handling of exceptions and events. These command-line options behave just like their command counter-parts. * The notes window now supports bold, underline, and italics formatting. * Fixed some zoom and scrolling issues. * Selecting text in the command, memory, sources, or disassembly windows will now show a light highlight over other instances of the selected text. * Fixed a bug where interrupting symbol loading would cause symbol loading to fail for the rest of the session. * NatVis will now reload properly on restarting a session. ]]> WinDbg Preview 1.1805.17002.0 Release Notes https://docs.microsoft.com/archive/blogs/windbg/windbg-preview-1-1805-17002-0-release-notes Mon, 21 May 2018 15:53:58 GMT https://blogs.msdn.microsoft.com/windbg/?p=675 New disassembly window We’re starting to revamp some of the more barebones windows that are lacking compared to WinDbg. The first one we’re diving into is the disassembly window! [caption id="attachment_685" align="alignnone" width="728"]New disassembly window New disassembly window[/caption] We’ve added:
  • Scrolling up or down will continuously load more disassembly whenever possible.
  • Syntax highlighting for numbers, code addresses, and opcodes.
  • Clicking a code symbol will jump the disassembly window to that location.
  • Hovering over numbers will show a tooltip that converts that number to other bases.
  • Headers signifying the start of a function.
Let us know what you think in the comments or Feedback Hub!

Fast source window default

We’ve had a lot of feedback around the performance of WinDbgNext being a bit slower and more resource-intensive than WinDbg Classic. One of the key contributors is the source window control we’ve been using. We’ve updated our source window to be faster and more resource efficient.

Minor changes and bug fixes

  • Fixed some issues around symbol caching
  • Fixed some cases where toggle initial break wasn’t usable when the target isn't broken in
  • If you hit tab in the command window with nothing available, the cursor will now stay in the input field
  • WinDbgNext will now auto-detect bitness when opening CAB files
EDIT - A previous version of this post had an update listed that isn't in this release.]]> WinDbg Preview 1.1804.18003.0 Release Notes https://docs.microsoft.com/archive/blogs/windbg/windbg-preview-1-1804-18003-0-release-notes Tue, 24 Apr 2018 16:35:56 GMT https://blogs.msdn.microsoft.com/windbg/?p=665 Symbol status and cancellation Every once in a while WinDbg will sit saying it’s *BUSY* loading symbols and it’s difficult to determine what it’s doing and why without !sym noisy enabled. We’ve updated WinDbg Preview to have some better communication around what it’s doing when loading symbols to help troubleshoot any issues. In addition to easily seeing exactly what’s happening, we’ve made some changes that should make cancelling symbols more reliable and the Logs window will contain some of the details that’s normally output when !sym noisy is enabled. If you hit View -> Logs you’ll get the full noisy symbol loading output without having to turn it on and attempt to reload the symbols.

Experimental notes window

WinDbg Preview now has a window for taking notes. Just hit View -> “Notes” to open it. Right now it’s pretty barebones, but if you copy/paste into it, DML links will be preserved and still work as if it was the command window. You can also save and load notes files from the “Notes” ribbon when the window is open. Try it out and let us know what you think!

Experimental faster source window

We’ve had a lot of feedback around the performance of WinDbg Preview being a bit slower and more resource-intensive than WinDbg. One of the key contributors is the source window control we’ve been using. We’ve added an experimental new source window that is quite a bit more efficient. There’s still a few gaps around context menus and syntax highlighting, but we want to give everyone the option of trying it out before it’s finished to give us early feedback. Just run $UseFastSourceWindow to use it. If you want to go back to the old one, run $UseMonacoSourceWindow. The setting will preserve across sessions, you will need to close and re-open source windows to get the new version.

JSProvider API version 1.2

For JavaScript extensions that declare support for API version 1.2:
  • Any object with a .compareTo method which exits the script will have a custom comparator on it (comparison operators will work in the DX evaluator and elsewhere: e.g.: IModelObject::Compare)
  • Any object with a .equals method which exits the script will have a custom equality operator on it (== and != will work in the DX evaluator and elsewhere: e.g.: IModelObject::IsEqualTo)
  • Native or data model objects which enter the script will have .compareTo and .equals on them which allow access to any custom comparator or custom equality implementations

Minor changes and bug fixes

  • .server will now list fully qualified domain name for easier use when there’s domain issues around short names.
  • Ctrl+G now works in the source window.
  • Added address bar to the disassembly window.
  • WinDbg Preview will now handle _NT_SYMBOL_PATH in a more expected way.
  • Added -server command-line option.
  • TTD data model queries can now be displayed progressively, so if you interrupt it you’ll still see some results. This is still experimental, so you can run “dx @$cursession.TTD.AsyncQueryEnabled = 1” to enable it.
  • The ‘dps’ command now has links to the source files it refers to.
There's quite a few other changes and fixes under the hood that I might've missed here given it's been a while since our last release. As always, feel free to comment or send feedback to the Feedback Hub if you have any issues! -Andy]]> Time Travel Debugging queries https://docs.microsoft.com/archive/blogs/windbg/time-travel-debugging-queries Thu, 01 Feb 2018 10:01:53 GMT https://blogs.msdn.microsoft.com/windbg/?p=625 Overview Do you need to debug something but hate stepping through 100s-1000s lines of code? Do you wish there was a faster way to answer "What is the problem?" If you answered Yes to either, then read on to learn more about using Time Travel Debugging (TTD) queries to streamline debugging. Software is a complex interaction of code and data. TTD records code and data interactions of a running app or process into a trace file which can be replayed in a debugger. To use SQL terms, the trace file is a database and the debugger offers a cursor (one row of data at a time) to step through individual lines of code. Even greater value and versatility is realized by executing a query to search across multiple rows of data and provide results in a single view. Using a query enables powerful debugging experiences to find a problem faster by searching the entire code execution instead of stepping through individual lines of code. You can use a LINQ query to search a trace file by function calls, time positions, memory addresses, register contents, etc. See the Writing LINQ queries in WinDbg blog post for more details on writing queries. Debugging using a query is great because:
  1. Faster than conditional breakpoints
  2. Control results using LINQ
  3. Visualize patterns in grid view

Query Scenario

The best way to show why debugging using a query is great is to walk through a simple scenario.  This scenario records the code execution of the File Open dialog in 64-bit Notepad and replays the trace file in the debugger to identify all the places where GetLastError returns a non-zero error code. Here is the hardware and software configuration used to measure results of this scenario.
Hardware Software Trace file
SurfaceBook 2 i7-8650, 2GHz, 4 cores + hyperthreading 16GB RAM PCIe SSD Windows 10 build 16299 WinDbg Preview from Store Size on disk: 469,762,048 bytes represents about 446 million instructions
 

Faster than conditional breakpoints

In traditional debugging, a conditional breakpoint would be used as follows to identify all the places where GetLastError returns a non-zero error code.
Debugger command Description Result
bp kernelbase!GetLastError+c "j @rax==0 'gc';'?@rax;gc'" Looks at the value of register rax at the ret instruction and prints the value if it is non-zero. "+c" comes from disassembling kernelbase!GetLastError and locating the 'ret' instruction relative to the start of GetLastError. The rax register holds the return value of GetLastError for 64-bit software on Windows.   Click here to learn more about conditional breakpoints This takes a long time using trace file. The command was stopped after 30 minutes and was only a little over halfway through the trace file. This approach works okay when debugging a live process but often is not practical in TTD traces.
  Now let's try the same thing with a query.
Debugger command Description Result
dx @$e = @$cursession.TTD.Calls("kernelbase!GetLastError").Where(c => c.ReturnValue != 0) The dx command displays information from the debugger data model and provides an extensible query engine using LINQ syntax. TTD provides extensions to the query engine which enables fast access to the call and memory activity in a trace file. This query completes in about 20 seconds which is roughly 100x faster than using conditional breakpoints. In fact, collecting the query results from a trace file is faster than using conditional breakpoints in a live process (which takes about 26 seconds for a similar workload)!
  Let's review the query in more detail by breaking the command into parts.
Debugger command Description
dx @$var = <expression> Assign the result of a query to a variable
dx @$cursession.TTD.Calls("kernelbase!GetLastError").First() Get the first item to see the available fields. Click here to learn more about available fields. In this scenario, we only want the ReturnValue and TimeEnd fields.   kernelbase!GetLastError" is the module and function name we want to query. The module name is not required but improves query speed and avoids ambiguities between modules.
.Where(c => c.ReturnValue != 0) Where clause to restrict the results to non-zero return values. This is accomplished through a lambda expression
  So why is executing a query so much faster than a conditional breakpoint?
  • TTD uses a fully multi-threaded replay engine and indexing to quickly locate information when executing a query; whereas the debugger uses a single thread to evaluate a conditional breakpoint
  • Arcane conditional breakpoint syntax is replaced with more familiar LINQ commands and field names
  • No need to disassemble functions to locate 'ret' statements
  • No need to know which register contains the return value (which varies by processor architecture and calling convention)
 

Control results using LINQ

Conditional breakpoints are generally used to break into the debugger or log information when a condition is met; but there is no mechanism to further filter, sort or group the information. A query supports filter, sort and group of result data using familiar LINQ syntax against the data model. See MSDN for more examples of using LINQ with debugger data model.  

Filter

Debugger command Description Result
dx @$cursession.TTD.Calls("kernelbase!GetLastError").Where(c => c.ReturnValue != 0) Use the Where() method to filter the number of rows returned from the query. This example returns rows where ReturnValue is not zero.
dx -r2 @$s = @$cursession.TTD.Calls("kernelbase!GetLastError").Where(c => c.ReturnValue != 0).Select(c => new { Time = c.TimeStart, Error = c.ReturnValue }) Use the Select() method to choose which columns to see and modify the column display name. This example returns rows where ReturnValue is not zero and selects to display the TimeStart and ReturnValue columns with custom display names of Time and Error. [0x26] Time            : 412F:275 [Time Travel] Error           : 0x57 [0x27] Time            : 4021:275 [Time Travel] Error           : 0x57
 

Sort

Debugger command Description
dx -r2 @$cursession.TTD.Calls("kernelbase!GetLastError").OrderBy(c => c.TimeStart) dx -r2 @$cursession.TTD.Calls("kernelbase!GetLastError").OrderByDescending(c => c.TimeStart) Use the OrderBy() method to sort the rows returned from the query by one or more columns. This example sorts by TimeStart in ascending and descending order.
dx -r2 @$cursession.TTD.Calls("kernelbase!GetLastError").OrderBy(c => c.TimeStart, @$cursession.TTD.Utility.compareTime) Older versions of the debugger sort using this format.
 

Group

Debugger command Description Result
dx @$s.GroupBy(x => x.Error) Use the GroupBy() method to group data returned by the query to do more powerful analysis since the results are structured. This example groups the time locations by error number.   Note: @$s is the result of the previous query. You can assign query execution results to a variable and use that variable in future expressions. @$s.GroupBy(x => x.Error) [0x57] [0x3f0] [0xea]
 

Visualize patterns in grid view

By default, the results of a query are shown in detail view. You can also see the results in a grid view to help you visualize the results better to identify patterns and find problems faster. Just add -g to any dx command to see the results in a grid view. See the Writing LINQ queries in WinDbg blog post for more grid view details and examples. Example of what a grid view looks like in the debugger ]]> Text highlighting in WinDbg Preview https://docs.microsoft.com/archive/blogs/windbg/text-highlighting-in-windbg-preview Tue, 30 Jan 2018 10:25:26 GMT https://blogs.msdn.microsoft.com/windbg/?p=635 1.1801.19001.0) with some minor bug fixes and one highly requested feature! We know that sharing the output of your debugger is pretty important for passing along bugs and investigations. Often people spend a big chunk of time forming mails by highlighting important output, addresses, and values. You can now easily highlight all instances of selected text directly in the debugger! To use it, just select some text in the command window and then click “Highlight” in the command ribbon or hit Ctrl+Alt+H. Using one of those on already highlighted text will remove the highlighting. If you prefer using commands, you can use the “$hl” command:
  • $hl ["someValueHere"] - Highlight give text (or un-highlight if already highlighted)
  • $hl clearAll – Clear all highlighted entries
  • $hl caseSensitive [1|0] - Set highlight matching to case sensitive or case insensitive (default is case insensitive)
Let us know what you think in the comments below, or in the Feedback Hub! -Andy]]>