search

microsoft / Windows-Dev-Performance

A repo for developers on Windows to file issues that impede their productivity, efficiency, and efficacy
MIT License
434 stars 20 forks source link

WinDbg's `dU` command is painfully slow #103

Closed AzAgarampur closed 2 years ago

AzAgarampur commented 2 years ago

Windows Build Number

10.0.19044.0

Processor Architecture

AMD64

Memory

8GB

Storage Type, free / capacity

C: SSD 256 GB

Relevant apps installed

WinDbg Preview (Window Store Version)

Traces collected via Feedback Hub

n/a

Isssue description

Using the dU command is very slow. It sometimes takes up to a full minute to display a Unicode string. For example, if you set a breakpoint on LoadLibrary, and use dU rcx, the command only returns after a full minute to display the resulting string. Obviously, this is not normal behavior, and I remember this did not used to happen in the past, so some newer change in WinDbg caused this.

Steps to reproduce

Launch notepad with WinDbg, and set a breakpoint on LoadLibrary or something else that takes in a PWSTR as a parameter. Then, use the dU command at the breakpoint - for example: dU rcx @ LoadLibraryW breakpoint.

Expected Behavior

The dU command returns a result instantly (normally)

Actual Behavior

Takes a full minute or two to simply display a unicode string of any length.

justanotheranonymoususer commented 2 years ago

Have you tried dU @rcx? dU <address> directly?

AzAgarampur commented 2 years ago

Tested it; those commands work quickly.

justanotheranonymoususer commented 2 years ago

There's your problem. WinDbg treats rcx as a symbol and tries to resolve it, which takes a while. Always prepend with @ when referring to registers.

AzAgarampur commented 2 years ago

Sounds like a good explanation; thanks