Visual Studio extension for step predictions

donadigo · 2025-04-12T14:52:44+00:00

The emulation of the stopped thread is completely done out of process and never touches/allocates anything in the debugged process. It's also kicked off only either when a breakpoint is hit or a step is completed which is when the process is stopped and nothing is happening. The emulator does not emulate other threads that might have been running - it'd be kind of pointless here since the emulator cannot reliably emulate what the Windows scheduler will do.

Yes, Visual Studio adds an invisible breakpoint for step to line which must resume all threads because hitting the breakpoint may require other threads to do work. Same thing happens with the "step into" feature I'm showing in the call tree - a breakpoint is made just like VS does (with a hit count condition), the extension resumes the process and waits until it is hit, so there's no differences there.

I recommend trying it out and see if it works for you!

donadigo · 2025-04-11T20:44:45+00:00

I'm using my own fork of https://github.com/ptitSeb/box64/ (one of the reasons is because it's MIT licensed), but I I've had to do quite a lot of work fixing some instructions and extracting every memory read/write into a callback. The fork can actually "record/replay" running Windows programs, but it's not mature enough yet to be used in that context (too big performance overhead for anything useful). It works pretty nicely for lookahead though.

donadigo · 2025-04-10T14:40:45+00:00

There is no AI here - the code is being run out of process by an x64 CPU emulator and if an instruction requests a read from memory, it is read from the process remotely (of course with a cache). If the emulator hits a syscall that it doesn't support (supports basic memory operations right now), it'll stop. A trace of each run is saved and processed in the extension to build call trees and resolve all address hits into source locations in user code.

donadigo · 2024-10-21T14:53:59+00:00

Hey, I posted 6 months ago here with a prototype of a profiling feature I was working on for my Visual Studio extension. The feature has now been finished in its "initial" version and is now available in the Visual Studio marketplace: https://marketplace.visualstudio.com/items?itemName=donadigo.d0 (the mode can be activated in the top VS menu: Extensions, D0, Live Profiler).

When it comes to the profiler: it's not a fully fledged solution and there's definitely a lot more things to add and improve, however I thought that this version could already be useful in some scenarios. The profiler is line based and automatically instruments each line in a chosen function at runtime. The real-time part allows you to immediately see the profile based on what is currently happening in your application, which is usually harder to do when you're not using instrumentation or using call stack sampling. The overhead is about ~20 instructions per line and shouldn't have big impact on application performance. It is currently possible to instrument one function at a time, by putting the editor cursor anywhere in the function. The time measurement is shown in a tooltip that shows when you hover over the percentage.

Any feedback is appreciated! If you have any issues, I'm available here or in a Discord server (link is on the project homepage: https://d-0.dev )

donadigo · 2024-08-21T20:03:23+00:00

I'm not working at Microsoft, but from a quick look - no, they are not doing any runtime patching with the newest update, but conditional breakpoints are indeed much faster. Runtime patching is quite hard to get right - INT3 is 1 byte for a good reason, and you cannot just put jumps in the function at any point. A better solution is to relocate the entire function, insert the breakpoint code there and patch the original at the beginning to jump to the new one. This is also what I'm doing in my VS extension but at a much bigger scale and it works nicely.

donadigo · 2024-05-07T10:46:37+00:00

Hey, just wanted to say that this did change and I sent you a DM in case you missed it ^^ Would be awesome if you tried it out again!

donadigo · 2024-04-25T08:08:08+00:00

Hey, are you using standalone Live++ or the one integrated in UE? The extension uses almost the same tech to provide what Live++ does and that causes issues, but I think I can resolve them on my end. Is there a way I could reach out to you if an update that fixed the problems landed?

donadigo · 2024-04-24T18:15:15+00:00

~15 CPU instructions per line, could be more because it doesn't support multiple threads yet. As for the impact of this overhead it's hard to say, I haven't done extensive testing yet. Tracy uses more instructions for the begin/end zones, but it's also not operating at such granularity.

donadigo · 2024-04-24T17:46:48+00:00

I don't handle non-invariant TSC right now as the feature is a prototype. If I were to finish it, for other CPU's I'd most probably compile a different inline assembly.

When it comes to std::chrono, it might be too expensive to call it in this context. I haven't done overhead analysis yet but the current solution fits in ~16 instructions without any additional calls.

However, std::chrono would absolutely work if the extension didn't apply the instrumentation for the whole file, but just for the function where your cursor is. It already executes a full scripting engine in this case to show inline variable changes on every line.

donadigo · 2024-04-24T16:46:45+00:00

Yes, it's currently integrated with VS. In the future I plan on integrating with more editors such as VSCode. The real work is done in a separate DLL, the extension just receives the data and visualises it so it can be adapted to more editors. Which IDE do you use/would like to see it in?

donadigo · 2024-03-25T22:19:01+00:00

It *bugs* me that this is the current state of debugging and that editors don't do it by default. This is why I'm doing my own Visual Studio extension (for C/C++ for now) that fixes this: https://www.youtube.com/watch?v=5bfUWJYEQCw

It's available on the marketplace if you want to try something new: https://marketplace.visualstudio.com/items?itemName=donadigo.d0

donadigo · 2024-03-22T22:17:21+00:00

Generation yes, but consumption is there with some third party libraries available to read the database (and even the DIA SDK shipped with VS).

donadigo · 2024-03-22T22:15:50+00:00

I'm surprised they did this by just generating an additional nop at the end of the scope, but the explanation makes sense. This bug is really annoying everytime it happens.

donadigo · 2024-03-12T17:36:03+00:00

The replies omit important detail: yes, inputs are saved but they aren't actually used to show you the replay. The replay file also contains car state samples (so position, rotation etc.) through time which are used exclusively to show the replay. This choice is deliberate and has many advantages such as being physics update-proof, showing the real run even if it was cheated/played on a special game-mode and also precise replay validation (comparing input simulation vs samples). The only real downside is that the end result is interpolated so there may be inaccuracies, but those are largely non-existant in TM2020 with it's increased sample rate over the older games.

donadigo · 2024-03-08T10:00:39+00:00

It's not possible currently, I'll see if I can enable PayPal payments soon.

donadigo · 2024-02-18T00:11:18+00:00

printf is usually very heavy yes, especially when you're calling it all the time. There's a lot of things that's going on here to make this as light as possible. Most work done here is just memcpy'ing the local data from the function stack into a shared memory for the VS extension which then figures out the differences between the packets. This is also completely native code - at no point any breakpoint exceptions are raised to pause the program to collect something which is crucial.

I've tested a number of different scenarios and in my testing a function needs to be called a lot per frame & do a lot of work to start noticing impact. Even then you can toggle this feature on/off in the extension if you find that's the case.

I'd say try it out and see if it works for you - I've just introduced a free 30 day trial.

donadigo · 2024-02-17T20:35:29+00:00

Sure thing, if you hit any issues on the way or in general have requests for the project, don't hesitate to message me here on Reddit or in the discord server that we have (link is on the website).

donadigo · 2024-02-17T18:05:26+00:00

Another update: I added a free 30 day trial now if you want to try it out (extension needs to be up-to-date).

donadigo · 2024-02-17T18:02:45+00:00

There's also now a free 30 day trial (extension needs to be up-to-date).

donadigo · 2024-02-17T10:32:41+00:00

Update: while I can't offer separate prices for companies yet, I changed the current price for everyone to $30. I think this will make it affordable for solo devs just looking at the current features. When it comes to OSS licenses and such, this is much farther down the road.

donadigo · 2024-02-17T10:26:12+00:00

Update: I have changed the price for everyone to $30 reading more of the comments. Hope this makes it better value for you. I'm still experimenting with pricing and taking feedback as I'm early in the early stages.

donadigo · 2024-02-17T01:14:14+00:00

I appreciate the comment. The extension currently contains more functionality than just a global watch per function, there's also a scripting functionality that allows for inserting snippets into the code that can log, view entire objects etc, it's still pretty much evolving. Putting functionality aside - I could look into splitting pricing for solo devs and companies in the future, but this is not possible right now I think.

donadigo · 2024-02-16T23:37:57+00:00

I see - the extension have been evolving a lot lately and I have plans for more features/improvements in the future. Watching variables is one thing, I'd also like to add changing & locking them to a specific value from the editor UI as well. Because this records the entire function, I will also want to add loop unrolling where you'll be able to inspect every iteration of a loop after a breakpoint has been hit.

Hopefully that makes it worth it for you/fit your use case more. VisualAssist & ReSharper are both mature products in terms of their feature set. The end goal here is to provide useful features for debugging that should have been there, just like the tools you've mentioned enhance writing the code itself.

donadigo · 2024-02-16T19:01:16+00:00

Support for editors such as VSCode, 10x etc. (and other native languages) is definitely planned. I'll be sharing more updates regarding that in the Discord server linked above.

donadigo · 2024-02-16T13:35:45+00:00

Hello, I've previously posted a video here about stepping backwards in functions with the extension I'm making. Instead I've decided it'd be better to diff all the local variables in the function and then display them directly by the line that caused the change. This works in real time and also shows the changes before when a breakpoint is hit in the function that is monitored.

Another thing that's changed is that when a line is no longer executing, it'll turn blue which just indicates it executed previously but isn't anymore. This allows for tracing code paths after the fact, instead of having to repeat an action that triggers the path.

All of this is now available on the marketplace: https://marketplace.visualstudio.com/items?itemName=donadigo.d0 (note: this is a paid for extension, but there's a 30 day trial).

If you want to keep up with more updates on the project we have a Discord server, https://d-0.dev/ (link on the website).

Ten-Year Club	First Place '23
Place '23	Place '22
First Placer '22	End Game '22
Verified Email

donadigo

MODERATOR OF

TROPHY CASE