VSCode is really frustrating lately, I debug all day long and the IDE just randomly shits a brick, or hangs, or just stalls, the vim plugin just loses its shit once in a while do ruining your undo's.
MSVC was (is) by far much better overall (I only pull it out now a days to analyze crash dumps though). Heck in vscode you can't really see variables in C++ or examine memory, or set memory change break points, but really 90% of developing doesn't require any of that, so vscode just keeps growing in use.
I do love me some GDB though, when I'm developing on *nix anyway.
> VS debugger can do none of the things I look to a debugger to do.
Such as? I'm genuinely curious here. I know of a bunch of things that VS can't do on Windows that requires resorting to windbg (which is a terrible experience compared to VS's debugger), but what are the things you look for in a debugger that it can't do at all? Are we talking user land debugging or kernel?
I use gdbserver to attach gdb to a process on the target machine, running gdb on my dev box where the sources are. In a previous life, I would use a similar capability to debug code in an embedded target through a serial port, with a tiny stub in the target program to manipulate target memory and execution. Nowadays you do that through a USB port.
When I set a breakpoint, I can make it conditional on an expression run against program data, and have it run a series of debugger commands at each stop, and then maybe continue.
Scrolling back through the transcript to see how values have changed at each stop, and running expressions on e.g. differences between such values.
You can definitely do most if not all of that with WinDBG (which is distinct from the Visual Studio builtin debugger). The problem is there doesn't seem to be as much resources around learning how to use it. There are a ton of old hats at MS who know how to perform all sorts of wizardry with WinDBG.
Dev experience is fixable in many ways, but wholesale lack of capability is not.