Getting Access Denied when trying to debug Azure Functions project in VS Code

[konrad-kolodziejak-at-cg]

I am struggling with running a debugger on Azure Functions project in VS Code on my laptop.

I am getting a following error message when debugger tries to attach itself to azure function process upon the start of the function host:

Environment details:

I have following tools installed Azure Functions VS Code extension: v1.15.4 Azure Functions Core Tools: azure-functions-core-tools@4.0.6280 Azurite: v3.32.0

Func host start launches correctly. I am getting a list of functions in the terminal as well as Host lock lease acquired by instance ID '00000000000000000000000079F46AA2'. message. When I trigger any of the functions from the project, all works perfectly fine. The problem is only with attaching the debugger.

• I have been using the same setup on other machines (Win 10 mostly) and never had a problem with debugger failing to attach
• I have reinstalled VS Code, Azurite, Core Tools and the extension to verify, whether this solves the issue. It doesn't.
• Function project is runs on .net 8.0 isolated.
• A colleague of mine (from the same company) has exactly the same problem, so it seems to be pointing towards computer configuration or software installed being the cause.
• I have tried adding args: ["--verbose"] to launch.json configuration, but it didn't provide me with any meaningful info,

launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Attach to .NET Functions",
            "type": "coreclr",
            "request": "attach",
            "processId": "${command:azureFunctions.pickProcess}"
        }
    ]
}

tasks.json:

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "clean (functions)",
            "command": "dotnet",
            "args": [
                "clean",
                "/property:GenerateFullPaths=true",
                "/consoleloggerparameters:NoSummary"
            ],
            "type": "process",
            "problemMatcher": "$msCompile"
        },
        {
            "label": "build (functions)",
            "command": "dotnet",
            "args": [
                "build",
                "/property:GenerateFullPaths=true",
                "/consoleloggerparameters:NoSummary"
            ],
            "type": "process",
            "dependsOn": "clean (functions)",
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "problemMatcher": "$msCompile"
        },
        {
            "label": "clean release (functions)",
            "command": "dotnet",
            "args": [
                "clean",
                "--configuration",
                "Release",
                "/property:GenerateFullPaths=true",
                "/consoleloggerparameters:NoSummary"
            ],
            "type": "process",
            "problemMatcher": "$msCompile"
        },
        {
            "label": "publish (functions)",
            "command": "dotnet",
            "args": [
                "publish",
                "--configuration",
                "Release",
                "/property:GenerateFullPaths=true",
                "/consoleloggerparameters:NoSummary"
            ],
            "type": "process",
            "dependsOn": "clean release (functions)",
            "problemMatcher": "$msCompile"
        },
        {
            "type": "func",
            "dependsOn": "build (functions)",
            "options": {
                "cwd": "${workspaceFolder}/bin/Debug/net8.0"
            },
            "command": "host start",
            "isBackground": true,
            "problemMatcher": "$func-dotnet-watch"
        }
    ]
}

Has anyone had a similar problem? Is there a way to get some more information on the issue (more verbose logging) so I could address this with my admins?

[nturinski]

Sorry that you're having this issue. I can't seem to reproduce it, but I have a couple of ideas.

Has this configuration ever worked on this particular machine? Is this also a Windows 10 machine?

Based on the fact that you said your colleague is struggling with the same issue, I wonder if it has something to do with your corporation's proxy/fire wall settings. The debugger has to connect to localhost:7071, so maybe it's being blocked?

[AzCode-Bot]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!