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.

[TurkeyMan]

It's definitely not a duplicate of the Concord request though, unless there is some way Concord is available without VisualStudio? We have users in my office who are very keen to start using code (currently using QtCreator), what will they do without VS installs?

[segevfiner]

WinDbg still has it's strengths in comparision to the Visual Studio debugger for native code. It would be quite nice if this exension supported it.

[sean-mcmanus]

@segevfiner Yeah, I'm re-activating this -- it isn't a duplicate of the existing Windows debugging that was implemented. I suspect the debugger team may not have the capacity to implement it though, but most of the debugger code is open source so maybe we could take a pull request?

[fungos]

what about https://github.com/reedz/windbg-debug ?

[ymn1k]

WinDbg has extremely useful feature which is Time Travel Debugging.

[rtbo]

I have tested the windbg-debug extension.
It seems to work well, and CDB is much faster than GDB.
It just need very little manual configuration as indicated here.

[ci70]

Why hasn't this been implemented? WinDBG is more flexible than MSVC debugger.

[surya-prakash-susarla]

Is there any updates on this ? I would really love it if we could use WinDbg in VSCode since it would (maybe) help in child process debugging. Currently I'm bound to use Visual Studio because of the child process debugging extension and if there was full support for WinDbg then might be I can move all of my dev tasks over here. Thanks!

[jxy-s]

I want to share some thoughts here in hopes of shedding some clarity on the request.

The equivalent command line interface debugger to gdb on windows is cdb, documented here: https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/debugging-a-user-mode-process-using-cdb

This gives you the "windbg" experience in a terminal on Windows. And I think is what is being asked for here.

The mechanics of using this extension to launch as "cppdbg" using gdb gives the "Debug Console" interactivity, for example -exec bt will display the stack backtrace using gbg in the "Debug Console". This seriously empowers the developer to dig deep into the process being debugged if they need to.

The existing "cppvsdbg" console (which uses the visual studio debugger) gives zero power to the user in the console.

I would love to see an integration that enables you to use cbd instead. I'd suggest "cppwindbg" which integrates cbd with the "Debug Console" such that you may execute "windbg" commands seamlessly instead. For example, -exec k will display the stack backtrace using cdb in the debug console. Then, cdb empowers developers to dig deep into the process being debugged, just like gdb does, if they need to.

Some Windows engineers are not accustomed to gdb and also cdb (or really dbgeng.dll, explained in a moment) has a plethora of features which are extremely useful (and arguably necessary) for debugging a process on Windows. Under the hood it's all dbgeng.dll doing the lifting - windbg.exe, windbgx, and cdb.exe all leverage this library to do the work. Integration with cdb (or dbgeng.dll) in vscode will make it a first-choice IDE for me, hands down, bar none.

I'm not familiar enough with this code base. But from a high level if there is facility to use gdb CLI I'd imagine it is possible to use cdb CLI instead. The alternative is using dbgeng.dll directly.