Support WinDbg as debugengine for windows?

[TurkeyMan]

Please support WinDBG as Windows debug engine. Using GDB to debug local windows apps is pretty awkward.

[jhasse]

Using GDB to debug local windows apps is pretty awkward.

Why?

[delmyers]

@TurkeyMan Is there a particular reason that you would like to use WinDBG? I understand that GDB is awkward, but would you be willing to just have native Windows debugging (non GDB), or are there specific WinDBG features that you would like?

[TurkeyMan]

@jhasse For one, you need to populate the binary with DWARF. Various annoyances exist, for instance, you can't place a new breakpoint without pausing execution first. There are lots of reasons that make GDB awkward for windows dev.

@delmyers What do you mean by 'native windows debugging'? When you say that, I suspect you mean WinDbg, which is exactly what I'm talking about(?).
It's an excellent windows debugger, and available as an independent distribution, ie, no VS dependency. I'm pretty sure we're talking about the same thing.

[TurkeyMan]

Sorry, I think I might have understood the confusion; where I say WinDbg, I didn't mean that vscode should spawn the WinDbg UI (if that's what you took me to mean), I meant the debugengine it uses (CDB/KD right?) which are all bundled together in the same package.

[jhasse]

@jhasse For one, you need to populate the binary with DWARF. Various annoyances exist, for instance, you can't place a new breakpoint without pausing execution first.

Ah didn't know that, thanks :)

There are lots of reasons that make GDB awkward for windows dev.

Don't these two disadvantages also affect Linux / Mac users?

[delmyers]

@TurkeyMan my question was more around whether or not there were specific windbg features that you like. You also filed an issue asking for Concord support. I was just wondering if supplying that would also satisfy this issue. Both Concord and Windbg are native non-gdb debuggers for windows.

[TurkeyMan]

@delmyers Well, the key feature is that WinDbg is bundled independently, ie, useful to users who don't have visual studio (ie, users in our Chinese office). Of course, WinDbg is also the windows kernel debugger, and it's an excellent debugger which has unique features that low-level devs might find useful, including a comprehensive plugin interface. I've required this in the past, but it's not relevant to me now.

Concord support is probably the more popular request; I'm sure it's familiar to the most users. It would suit me, but not those in my office who don't have visual studio.

I think there's good reason to support both, which is why I logged both issues. For me, Concord is preferable (.natvis files and all that), for the others in my team, WinDbg is the only option... you see the problem ;)

Situation would change if MS released Concord as an independent (and free) distribution...

@jhasse No, those disadvantages don't affect linux/osx; DWARF is the standard on those platforms, so that's not a problem, and the pausing problem is apparently a windows-specific 'bug' (which has existed for a long time, and doesn't seem to be getting fixed). There are other ecosystem related issues which only affect windows too.

[delmyers]

@TurkeyMan, OK, I think I am going to close this as a duplicate of the Concord request for now, as it will make the discussions/planning more focused on our side. If there are more specific requests for WinDBG, then we can start discussions with the Windows team about that. Thanks.