Windows `launch` arguments are corrupted (double backslashes)

[Eugenij-W]

debugee:

static void Main(string[] args) {
    using (System.IO.StreamWriter sw = new System.IO.StreamWriter(@"C:\tmp\cs.log", true, System.Text.Encoding.UTF8)) {
        for (int i = 0; i < args.Length; i++) {
            sw.WriteLine($"args[{i}]: [{args[i]}]");
        }
    }

dap log:

{"adapter": "netcoredbg", "configuration": {"type": "coreclr", "request": "launch", "program": "dotnet.exe", "args": ["bin\\Debug\\net8.0-windows\\test.dll", "D:\\path\\to\\dir\\"], "cwd": "K:\\PROJECTS\\test", "stopAtEntry": true, "console": "internalConsole"}}

cs.log:

args[0]: [D:\\path\\to\\dir\]

Please note the missing slash at the end and the duplication of other slashes.

It seems that this function does not take into account Windows specifics:

netcoredbg/src/debugger/manageddebugger.cpp

Lines 600 to 617 in 8b8b222

	static std::string EscapeShellArg(const std::string &arg)
	{
	std::string s(arg);
	for (std::string::size_type i = 0; i < s.size(); ++i)
	{
	std::string::size_type count = 0;
	char c = s.at(i);
	switch (c)
	{
	case '\"': count = 1; s.insert(i, count, '\\'); s[i + count] = '\"'; break;
	case '\\': count = 1; s.insert(i, count, '\\'); s[i + count] = '\\'; break;
	}
	i += count;
	}
	return s;
	}

[viewizard]

As I can see, the same issue occurs on other OSes; specifically, I can reproduce it on Linux and macOS when an argument ends with \\. It looks like EscapeShellArg works correctly, but we have Windows-specific argument building logic that dbgshim also reproduces when " is escaped with \ on other OSes.
See the code here: https://github.com/dotnet/diagnostics/blob/3a9d1f8a7ba2a6cae33f6953af77086bfbe02906/src/shared/pal/src/thread/process.cpp#L3898-L3902

                    if('\\' != lpCommandLine[-1])
                    {
                        /* dquote is not escaped, dquoted sequence is over*/
                        break;
                    }

As a solution, we could avoid wrapping the argument in double quotes (") if it doesn't contain spaces. This seems to be the only viable workaround.

[viewizard]

I'm not sure why EscapeShellArg was initially added, but it seems we don't actually need it at all.

[viewizard]

A possible solution could be something like this: viewizard/dncdbg@818c92a

It works on Windows and has limited support on Linux/macOS (limited by dbgshim code logic).

I need to do some more testing before porting this into netcoredbg.

[Eugenij-W]

Thank you very much, please pay special attention to doubling the \ characters under Windows.
expected: args[0]: [D:\path\to\dir\]
given: args[0]: [D:\\path\\to\\dir\]

[viewizard]

Please note that DAP (Debug Adapter Protocol) uses JSON, which is a text-based format where a single backslash \ is a reserved escape character. According to the JSON Specification (RFC 8259), any literal backslash inside a string must be escaped as \\. Therefore, during evaluations, the multiple backslashes you see are syntactically required to form a valid JSON payload. This behavior is standard and cannot be disabled.
In other words, after the fixes, passing D:\\path\\to\\dir\\ will result in D:\path\to\dir\ within the application logic, but expression evaluation will show D:\\path\\to\\dir\\ due to JSON requirements.

[Eugenij-W]

Please note that DAP (Debug Adapter Protocol) uses JSON, which is a text-based format where a single backslash \ is a reserved escape character. According to the JSON Specification (RFC 8259), any literal backslash inside a string must be escaped as \\. Therefore, during evaluations, the multiple backslashes you see are syntactically required to form a valid JSON payload. This behavior is standard and cannot be disabled. In other words, after the fixes, passing D:\\path\\to\\dir\\ will result in D:\path\to\dir\ within the application logic, but expression evaluation will show D:\\path\\to\\dir\\ due to JSON requirements.

in my C# utility, I get D:\\\\path\\\\to\\\\dir\\ literally. The DAP json message is crystal clear at the same time, the argument is most likely corrupted in 2 places - that function and the win execution subsystem (I suspect the last slash is her fault): {"adapter": "netcoredbg", "configuration": {"type": "coreclr", "request": "launch", "program": "dotnet.exe", "args": ["bin\\Debug\\net8.0-windows\\test.dll", "D:\\path\\to\\dir\\"], "cwd": "K:\\PROJECTS\\test", "stopAtEntry": true, "console": "internalConsole"}}

A slash for the shell is added here, but in win it leads to duplication because slashes are not processed by the shell there.

ps. although considering that it is possible that the argument also comes with double quotes in this function, everything may be corrupted there.

[viewizard]

In case of evaluation result the path d:\\\\path\\\\to\\\\... is correct in the raw JSON text. The IDE should receive it from the debugger in the JSON payload with four backslashes (\\\\).

Here is why:

1. Debugger Behavior: The debugger forms an escaped string during evaluation. This matches how MS vsdbg and MSVS C# debuggers handle strings and characters.
2. DAP Behavior: The Debug Adapter Protocol (DAP) adds another layer of escaping for all transmitted data when sending JSON (which is also consistent with how MS vsdbg handles JSON).

As mentioned previously, after the fix, you will see the proper path D:\\path\\to\\dir\\ (which is D:\\\\path\\\\to\\\\dir\\\\ in the raw JSON text). Please note that according to the JSON standard, any backslash used as an escape character must be unescaped during parsing, but it looks like you are using the strings "as is".

[viewizard]

If you are already unescaping strings during parsing, please just wait for the fix.

[Eugenij-W]

I think something like this should be:

static std::string EscapeShellArg(const std::string &arg)
{
    std::string result;
    for (char c : arg) {
#ifdef _WIN32
        if (c == '"')
#else
        if (c == '"' || c == '\\')
#endif
        {
            result += '\\';
        }
        result += c;
    }
    return result;
}

ps. although, if you think carefully, then this whole function needs to be replaced with pure validation, it is the user's concern to make the correct command and attempts to fix it on the fly, especially in this way, without taking into account existing escape sequences... they won't lead to anything good, it seems to me.