AL AL Debugger Bug Report: Call Stack and Variables Empty When Paused on Exception (Linux)

1. Describe the bug

The AL Language Extension debugger successfully connects to Business Central cloud sandbox and pauses when an exception occurs, but the Call Stack and Variables panels remain completely empty. This prevents debugging as the source location of the exception cannot be determined.

Key symptoms:

Debugger status shows "Paused on Exception" ✅
SignalR connection to Business Central is established ✅
Call Stack panel is empty ❌
Variables panel is empty ❌
Source file does not open at exception location ❌
Breakpoints also do not show call stack when hit ❌

Environment specifics:

This issue occurs on Arch Linux with both Wayland (Hyprland) and XWayland modes
An identical setup (same VS Code version, same AL extension version) works correctly on Arch Linux with X11/i3 window manager
All software versions are identical between working and broken systems

2. To Reproduce

Steps to reproduce the behavior:

Set up debugging configuration for Business Central cloud sandbox (see launch.json below)
Start debugging session (F5)
Trigger any AL code that throws an exception
Observe that debugger pauses with "Paused on Exception" status
Observe that Call Stack panel shows no entries
Observe that Variables panel shows no variables

launch.json:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Publish: Microsoft cloud sandbox",
      "type": "al",
      "request": "launch",
      "environmentType": "Sandbox",
      "tenant": "4fec10aa-e544-4364-b0fd-d453521bc81c",
      "environmentName": "Test1",
      "startupObjectId": 22,
      "breakOnError": "All",
      "breakOnRecordWrite": "None",
      "launchBrowser": true,
      "enableSqlInformationDebugger": true,
      "enableLongRunningSqlStatements": true,
      "longRunningSqlStatementsThreshold": 500,
      "numberOfSqlStatements": 10
    }
  ]
}

Any AL code that throws an exception will reproduce this, for example:

trigger OnAction()
begin
    Error('Test error to trigger debugger');
end;

3. Expected behavior

When the debugger pauses on an exception or breakpoint:

Call Stack panel should show the complete call hierarchy
Variables panel should show local and global variables
The source file should open at the line where the exception occurred
User should be able to inspect the execution state

This is the behavior observed on the working Arch Linux + X11 + i3 system with identical software versions.

4. Actual behavior

When the debugger pauses:

Status bar correctly shows "Paused on Exception"
Call Stack panel remains empty (shows no entries)
Variables panel remains empty (shows no variables)
No source file opens
Debug console shows connection messages but no stack trace

Screenshots/Evidence:

Debugger status: Shows "Paused"
Call Stack: Empty panel
Variables: Empty panel
DebuggerServices.log shows successful SignalR connection to Business Central

Diagnostic Information:

The debugger process is correctly configured:

# File descriptors show correct socket-based IPC (identical to working system)
fd 0 -> socket:[40343]  (stdin)
fd 1 -> socket:[40345]  (stdout)
fd 2 -> socket:[40347]  (stderr)

DebuggerServices.log confirms:

SignalR hub connection established with debugger context [...]
SignalR connection send with Query parameters: "Authentication"

However, in some previous sessions, the log shows:

System.IO.EndOfStreamException: MessageReader's input stream ended unexpectedly, terminating.
   at Microsoft.Dynamics.Nav.EditorServices.Protocol.MessageProtocol.MessageReader.ReadNextChunk()

This suggests the Debug Adapter Protocol communication between VS Code and the AL Language Server may be failing to transmit call stack data.

5. Versions

AL Language: 16.0.1826476 (also tested with 17.0.1869541 pre-release - same issue)

Visual Studio Code: 1.104.1 (commit 0f0d87fa9e96c856c5212fc86db137ac0d783365, x64)

Business Central: Cloud Sandbox (SaaS), Version 27.1

.NET Runtime:

Microsoft.AspNetCore.App 8.0.20
Microsoft.NETCore.App 8.0.20
Microsoft.NETCore.App 9.0.9

Operating System:

[x] Linux (Arch Linux, Kernel 6.17.5)
- Display Server: Wayland (Hyprland 0.51.1)
- Also tested with XWayland using --ozone-platform=x11
[ ] Windows
[ ] MacOS

List of Visual Studio Code extensions installed:

Note: Issue has been reproduced with all extensions disabled except ms-dynamics-smb.al.

When testing, only the following extension was enabled:

[email protected] ⭐ (REQUIRED)

Other installed AL-related extensions (all disabled during reproduction):

Many other development tools are installed (GitHub Copilot, GitLens, Docker, Python, C#, Azure tools, etc.) but were all disabled during bug reproduction.

Additional Context

Comparison with Working System

I have documented a fully working AL debugger setup on another Arch Linux system with the following differences:

Working System (i3 + X11):

Display Server: X11
Window Manager: i3
Session Type: x11
Same VS Code version (1.104.1)
Same AL extension version (16.0.1826476)
Same .NET runtimes (8.0.20, 9.0.9)
Identical socket-based stdio for debugger process
Call stack and variables work perfectly ✅

Broken System (Hyprland + Wayland/XWayland):

Display Server: Wayland (Hyprland) or XWayland
Session Type: wayland
Same VS Code version (1.104.1)
Same AL extension version (16.0.1826476)
Same .NET runtimes (8.0.20, 9.0.9)
Identical socket-based stdio for debugger process
Call stack and variables empty ❌

The process architecture, file descriptors, and SignalR connections are identical between the two systems, yet the broken system fails to display debug information.

Troubleshooting Attempted

✅ Downgraded AL extension from v17 pre-release to v16 stable
✅ Verified .NET 8.0.20 runtime installed
✅ Forced XWayland mode using ~/.config/code-flags.conf with --ozone-platform=x11
✅ Removed Wayland-specific environment variables
✅ Verified socket-based IPC is working correctly
✅ Confirmed SignalR connection to Business Central succeeds
✅ Checked extension host logs (no errors found)
✅ Verified file descriptors match working system exactly

None of these steps resolved the issue.

Hypothesis

The issue appears to be in the Debug Adapter Protocol (DAP) message handling between VS Code and the AL Language Server on Linux systems running Wayland or certain display configurations. The debugger successfully:

Connects to Business Central (SignalR works)
Detects exceptions and pauses execution
Sends "paused" notification to VS Code

However, it fails to:

Return call stack data when VS Code requests it via DAP
Return variables data when VS Code requests it via DAP

This suggests a protocol-level communication failure specific to certain Linux display server configurations.

Final Checklist

[x] Searched the issue repository - no existing reports match this specific issue
[x] Reproduced the issue with only AL Language extension enabled (disabled all other extensions except dependencies)
[x] Code is simplified - any AL code that throws an exception reproduces this
[x] Compared with working system to identify environment-specific factors

Request

This issue makes debugging completely non-functional on modern Linux systems using Wayland display servers (including XWayland compatibility mode). Given that Wayland is becoming the default on most Linux distributions, this is a critical issue for Linux-based AL developers.

Please investigate the Debug Adapter Protocol communication on Linux systems, particularly:

How call stack and variables data is transmitted from the AL Language Server to VS Code
Whether there are any Wayland/Electron-specific issues with the MessageReader/MessageWriter protocol
Why identical socket-based IPC works on X11 but fails on Wayland/XWayland

Thank you for your attention to this issue.

Oct 31 '25 07:10 StefanMaron

Using devcontainers is a workaround for this:

https://stefanmaron.com/posts/fixing-al-debugger-linux-wayland/

Oct 31 '25 10:10 StefanMaron

Hi @StefanMaron, great to see another BC dev using linux, thanks for this as it has helped me resolve my issue with debugging.

Side note, have you also had issues with deploying due to lack of dependencies? https://github.com/microsoft/AL/issues/8178

Dec 21 '25 21:12 Brad-Fullwood