[Windows] Breakpoint information not provided once hit

[Namey5]

I'm working on integration with Zed and I've managed to get the debugger connecting to a running Unity session just fine - however, whilst the Unity session correctly hits a given breakpoint and stops playback, Zed recognizes that the debugger has stopped but never receives enough info to know what breakpoint has actually been hit.

Looking through the DAP communications, it would appear that the stopped event does come through:

// Receive
{
  "seq": 958,
  "type": "event",
  "event": "stopped",
  "body": {
    "threadId": 1,
    "reason": "breakpoint",
    "text": null,
    "allThreadsStopped": true
  }
}

It does not provide the hitBreakpointIds field in the body, although I am not familiar enough with the history of DAP to know if debugging clients strictly require this to function (or if Zed even uses this).

Afterwards, Zed sends a stackTrace request which would in theory provide the missing information:

// Send
{
  "type": "request",
  "seq": 8,
  "command": "stackTrace",
  "arguments": {
    "threadId": 1
  }
}

However this request never receives a response from the DAP - in fact it looks like the DAP stops sending any response messages altogether (event messages do continue to arrive as normal though).

This causes Unity to hang indefinitely and the Mono process executing unity-debug-adapter.exe to slowly leak memory (consuming ~60GB on my machine) until it is manually killed.

---

I'm guessing there might be a deadlock when trying to fetch the stack trace after the debugger has already been stopped, but the only place I can see where such a deadlock would occur is in WaitForSuspend() while handling StackTrace():

unity-dap/unity-debug-adapter/UnityDebugSession.cs

Lines 560 to 566 in bbe5993

	public override void StackTrace(Response response, dynamic arguments)
	{
	int maxLevels = GetInt(arguments, "levels", 10);
	int startFrame = GetInt(arguments, "startFrame", 0);
	int threadReference = GetInt(arguments, "threadId", 0);
	WaitForSuspend();

m_ResumeEvent should have been signalled immediately after sending the stopped event however, so I'm not sure what exactly is happening here (maybe an unhandled exception in SendEvent()?):

unity-dap/unity-debug-adapter/UnityDebugSession.cs

Lines 98 to 104 in bbe5993

	m_Session.TargetHitBreakpoint += (sender, e) =>
	{
	Frame = e.Backtrace.GetFrame(0);
	Stopped();
	SendEvent(CreateStoppedEvent("breakpoint", e.Thread));
	m_ResumeEvent.Set();
	};

---

Additional Info:

Operating System: Windows 11 24H2 (26100.7462)
Unity: 6.2.6f2
Mono: 6.12.0
unity-dap: v0.0.1

[Namey5]

Ok so it's even weirder than I was thinking (and almost certainly a compiler/runtime bug):

public override void StackTrace(Response response, dynamic arguments)
{
  Logger.LogDebug("about to fetch stack trace...");
  int threadReference = 0;
  int maxLevels = 10;
  int startFrame = 0;
  try
  {
    threadReference = GetInt(arguments, "threadId", 0);
    maxLevels = GetInt(arguments, "levels", 10);
    startFrame = GetInt(arguments, "startFrame", 0);
  }
  catch (Exception e)
  {
    Logger.LogDebug($"failed to parse arguments: {e}");
  }
  Logger.LogDebug($"fetching stack trace (thread: {threadReference}, maxLevels: {maxLevels}, startFrame: {startFrame}");
  WaitForSuspend();

// ...

static int GetInt(dynamic args, string property, int dflt = 0)
{
  Logger.LogDebug($"about to fetch request arg: {property}");
  try
  {
    return (int)args[property];
  }
  catch
  {
    // this happens so often that it fills up the log fast => hence the LogDebug and not LogWarn
    Logger.LogDebug($"could not GetInt from dynamic container at property: {property}");
    // ignore and return default value
  }
  return dflt;
}

Produces the following logs:

22/12/2025 19:52:58 [T] received data: {"type":"request","seq":8,"command":"stackTrace","arguments":{"threadId":1}}
22/12/2025 19:52:58 [D] about to fetch stack trace...
22/12/2025 19:52:58 [D] about to fetch request arg: threadId
22/12/2025 19:52:58 [D] about to fetch request arg: levels
22/12/2025 19:52:58 [D] could not GetInt from dynamic container at property: about to fetch request arg: levels

It looks like we get some pretty bad memory corruption when trying to access a dynamic field that doesn't exist (in this case levels or startFrame). If I had to guess, this is just down to a difference in implementation of dynamic/compiler shenanigans between dotnet and mono (I don't believe building with dotnet but swapping out the mono runtime has ever technically been supported).

It shouldn't be too difficult to replace usage of dynamic with concrete types:

• Use enum for all known event/message types (these can be automatically parsed as strings in json)
• Define struct for all known message bodies
• Use nullable for optional fields
• Use Newtonsoft.Json partial deserialization for unions/composite types

Temporarily replacing those missing arguments with defaults is enough to get the request to complete and now I can see Zed is receiving the stack frame - and after some weirdness with assemblies caching old file paths, it works!

[walcht]

Thanks for the detailed issue description :).

I probably have to do a major rewrite of this since this project has largely been forked from a deprecated VSCode plugin.

I agree with your suggested approach and I also agree that the problem is probably due to some Mono/dotnet compiler differences that I absolutely don't want to get into.

I will take a detailed look into this in the Christmas break :-)

Edit: I am currently working on a Unity probe program that automatically detects the listening debugging port of your running Unity Editor instance - that might also be relevant for your Zen plugin

[Namey5]

I took a look around to see if there were some good open-source C# bindings for DAP, but it looks like the closed-source VSCode SDK binaries are about it. I did find Zed actually have their own bindings generator for Rust and, well...I may have gotten a bit carried away and ported it to C# 😅:
https://github.com/Namey5/csharp-dap-types

Haven't tested it (no idea if it even compiles) but it might be handy :)

Edit: got it compiling and properly handling json parsing on latest dotnet - not sure if the nullable reference-types might cause issues for older framework versions though.

[walcht]

As far as I remember I also could not find any DAP bindings for C# except from the closed source C# unity extension.

Nice work on that, but I am afraid I can't understand Rust (yet - planning to learn it in January).
I will re-write this repository since the project it was forked from is honestly just not well written (dynamic all over the place, unnecessary runtime re-alocation, etc).

I am currently trying to figure out the listening debugging port for the Unity Editor and Player instances - I think when I upload this in this repository, you might find it interesting: https://github.com/walcht/unity-listening-debug-port

Edit: see this updated section on how to determine the listening debugger IP & PORT: https://github.com/walcht/neovim-unity#unity-debugger-support

[Namey5]

Looking forward to it :)

I've put a little bit more effort in and actually published a release of the C# DAP bindings + made sure it compiles for .NET Standard 2.0 so hopefully you shouldn't have to touch the Rust bits to use it as a library/submodule.

Either way, thanks for looking into this.

[walcht]

@Namey5 - after a very long time I did the re-write, it is still yet in draft mode but you can see it here (and give feedback if you want/can :)): #7

[walcht]

oops, closed by mistake.