WinDbg remote debugging interface placement

[yossizap]

Is your feature request related to a problem? Please describe.

In 9ae170b I added WinDbg to the remote debug dialog box thinking that it will support all windbg debug modes over pipes with some fixes. After closer inspection, it turned out that R2's WinDbg implementation only supports kernel debugging and adding regular remote windbg won't be trivial. I'll try working on it but it's in a lower priority.

Since opening this type of remote debugging will just open a completely different binary(windows kernel), I was wondering whether there's a workflow in which people debug window kernel binaries after loading them through ida/r2. Otherwise, I would just move this debug interface to Cutter's launch dialog for people to directly open windbg for kernel debugging.

[yossizap]

I wasn't aware of this at the time of writing, but it turns out that the WinDbg implementation supports listing all of the processes currently running in the debugged kernel with dp and then attaching to one of them with dp=. We could use the launch dialog for direct kernel debugging while "remote connect" will search dpj for our exe's name(fail if's missing) and attach to the specific exe with dp=. A more advanced user could obviously jump between processes but this sort of dictates a more sane workflow that we could also add rebasing to.

[XVilka]

Also will need some changes/improvements after network KD support is merged https://github.com/radareorg/radare2/pull/17340

[XVilka]

With the merge of DbgEng support locally on Windows systems and renaming the URI schemes, please see the updated WinDbg chapter of Radare2 book for the user cases on how to use and how it should look:

• https://github.com/radareorg/radare2/pull/17340
• https://github.com/radareorg/radare2/pull/17491