Visual Studio Insiders Python debugpy attach to remote process fails to get target process.

Open v-balabanov opened this issue 4 months ago • 1 comments

Describe the bug I can't get remote debugging to work while trying to attach to remote linux container python process via debugpy. Only record shown in Attach to process window is "dummy" one with PID = 54321.

Steps to Reproduce

Have linux docker container with running python process launched with debugpy CLI
Try to attach to process from VS insiders using Python remote, specifying tcp://localhost:5678/.
Refresh list of processes, target doesn't appear.

Expected behavior At least target process is being shown in list. At most, threads are shown and breakpoints are working after attach.

Additional context and screenshots I have VS insiders, Django app running in docker linux contaner, launched with python3 /tmp/debugpy --listen 0.0.0.0:5678 manage.py runserver 0.0.0.0:8000. When I'm trying to attach to process using Python remote (debugpy) and providing tcp://localhost:5678/ as target, I do not see target process. The only record there is what I believe dummy one with PID=54321. When I'm attaching to that one, I don't get threads list (obviously) but no exceptions/messages have been raised.

VSCode can attach just fine, so the port is open and ready to accept connections.

I believe I do have proper mappings because Containers tab content is synced with local workspace. I do have the very same version of debugpy (1.8.17) -- on remote target, in C:\Program Files\Microsoft Visual Studio\18\Insiders\Common7\IDE\Extensions\Microsoft\Python\Core\debugpy (have updated it), in local and global python envs. I have checked connection to this port from Dev PS inside VS Insiders and it works (apparently no firewall issues).

What steps could I do next to resolve this issue?

Configuration information VS Version: Insiders [11111.16] PTVS version: 17.0.25266.3 Python version: 3.12 Debugger Type (if applicable): New -- debugpy

Diagnostics file No PythonToolsDiagnostics_*.log file in temp.

Oct 16 '25 16:10 v-balabanov

here are some copilot suggests.. i'd try the --wait-for-client and add some prints.

Here are some troubleshooting ideas and investigative steps for your issue with Visual Studio Insiders failing to show the correct remote Python process when attaching via debugpy, while VSCode works fine:

1. Ensure Debugpy Configuration

Double-check the debugpy command line:
You used:
```
python3 /tmp/debugpy --listen 0.0.0.0:5678 manage.py runserver 0.0.0.0:8000
```
The typical approach is:
```
python3 -m debugpy --listen 0.0.0.0:5678 manage.py runserver 0.0.0.0:8000
```
Using /tmp/debugpy as a script can cause odd behavior unless that's a valid entry point. Try using -m debugpy.

2. Check Remote Attach Protocol/Compatibility

VS and VSCode use slightly different protocols for listing processes. VSCode may only require a socket connection, while VS Insiders might expect a process enumeration response from debugpy.
Make sure you're running the exact same debugpy version everywhere (which you say you are: 1.8.17).
Try updating debugpy on all environments to the absolute latest release, in case there's a bug fix for this behavior.

3. Container Networking

Ensure that VS can reach the container and that port mapping is correct.
- From your host, run:
```
telnet localhost 5678
```
  or
```
nc -zv localhost 5678
```
  to confirm connectivity.

4. VS/Extension Logs

Look for additional logs in Visual Studio:
- "Help" → "Send Feedback" → "Open Log File" (if available).
- Check %TEMP% for VS logs (even if PythonToolsDiagnostics_*.log is missing, there may be other logs).
Enable diagnostic logging for the Python extension if possible.

5. Dummy Process PID = 54321

This usually means the client (VS) isn't receiving a valid process list from debugpy.
VS may expect debugpy to respond to a "list processes" request, but debugpy only supports this on Windows out-of-process scenarios (see debugpy docs).
On Linux, debugpy attaches directly; process enumeration may not be supported, so VS falls back to a dummy entry.

6. Manual Attach Workflow

Instead of using "Attach to process," try "Attach by PID" or "Attach by port" if VS offers that option.
If you know the PID inside the container, try to attach to it directly.

7. Compare VSCode and VS Attach

Capture network traffic (e.g., with Wireshark or tcpdump) for VSCode and VS attach attempts. See if VS sends different requests.

8. Debugpy "Adapter" Mode

Try launching debugpy in "adapter" mode:
```
python3 -m debugpy --listen 0.0.0.0:5678 --wait-for-client manage.py runserver 0.0.0.0:8000
```
This ensures debugpy waits for the IDE to connect before running code.

9. Known Issues or GitHub Discussions

Check the debugpy and PTVS GitHub issues for related bugs:
- debugpy issues
- PTVS issues

10. VS Version/Insiders Bugs

Try a regular (non-Insiders) version of Visual Studio if possible.
Check for updates to Python/Debugging extensions.

Summary:
This appears to be a protocol or feature mismatch between VS and debugpy on Linux. VS Insiders may expect features that debugpy only supports on Windows, or the attach workflow may require a different approach. Using debugpy as a module (-m debugpy), checking for more logs, and manually specifying the PID/port for attach are good next steps.

If possible, share any additional logs or the exact steps/screenshots for the attach workflow in VS. This will help pinpoint where the process list enumeration is breaking down.

Oct 16 '25 17:10 bschnurr