RunActivity: "Could not connect Jdwp ... Process Not Found" leaves the app suspended after `am start -D` — debugger never attaches (net10 Mono, slow Windows emulator)

[rmarinho]

Android framework version

net10.0-android

Affected platform version

.NET SDK 10.0.302 / runtime 10.0.10, Microsoft.Android.Sdk.Windows 36.1.69, JDK 21.0.8, emulator 37.1.11, platform-tools 37.0.1

Description

When launching with the debugger attached (dotnet build -t:Run -p:AndroidAttachDebugger=true), the RunActivity task issues am start -D -S …, which starts the activity suspended waiting for a JDWP debugger. ConnectJdwpAsync is then supposed to find the app process and attach, releasing it so the Mono runtime can open the soft-debugger socket.

On a slow emulator that step fails and is only reported as a warning:

warning: Could not connect Jdwp. System.Exception: Process Not Found.
   at Xamarin.AndroidTools.Debugging.DebuggingExtensions.ConnectJdwpAsync(AndroidDevice androidDevice, ExecutionConfiguration config, CancellationToken token)
   at Xamarin.AndroidTools.Debugging.DebuggingExtensions.StartWithDebuggingAsync(IAndroidDevice device, ExecutionConfiguration configuration, CancellationToken token)

Because it is a warning, the build succeeds with exit code 0 and zero errors, so every layer above it believes the launch worked. In reality the app is never resumed, nothing ever listens on the sdb port, and the debug session dies a few seconds after the debug adapter attaches:

The program 'MyApp.dll' has exited with code 0 (0x0).

The breakpoint is never bound or hit, and the user is given no actionable error — just a session that ends on its own.

We hit this on our .NET MAUI VS Code extension CI. It reproduces on the majority of runs on Windows agents whose emulator is accelerated with WHPX, where a cold build + deploy takes ~10 minutes. The identical project, SDK, AVD definition, and launch command on a Linux agent with KVM (build + deploy ~2.5 minutes) has never reproduced it.

Two things look wrong independently of the environment:

1. ConnectJdwpAsync appears to make a single attempt with no retry/backoff. "Process Not Found" is exactly the transient state you would expect right after am start on a loaded machine — the process exists but has not yet published itself to adb jdwp. A bounded retry loop would likely close this entirely.
2. The failure is downgraded to a warning. Since -D was passed, failing to connect JDWP means the requested operation (launch under a debugger) did not happen. Reporting success here converts a clear, diagnosable error into a silent hang followed by an unexplained session exit.

Note the ordering in the task output: Starting Debugger on 127.0.0.1:<port> is printed before am start, so the message is aspirational — nothing verifies the debugger actually got attached.

Steps to Reproduce

1. dotnet new maui (or dotnet new android), target net10.0-android.
2. Boot an x86_64 API 36 emulator on a Windows host using WHPX acceleration on a machine under load (we use a 1ES CI agent):

   emulator -avd test_emulator -no-window -no-audio -no-boot-anim \
            -gpu swiftshader_indirect -no-snapshot -no-metrics -memory 4096
   

3. Set a breakpoint in MainPage's constructor (InitializeComponent).
4. Launch with the debugger attached:

   dotnet build -t:Run -p:Configuration=Debug -f net10.0-android \
     -p:AdbTarget=-s%20emulator-5554 \
     -p:AndroidAttachDebugger=true \
     -p:AndroidSdbTargetPort=55335 -p:AndroidSdbHostPort=55335 \
     -p:AndroidSdkDirectory=C:\Android\android-sdk \
     '-p:JavaSdkDirectory=C:\Program Files\Android\openjdk\jdk-21.0.8' \
     -v:normal -bl
   

5. Attach a managed debugger to 127.0.0.1:55335.

Expected: the app resumes, the Mono soft-debugger connects, the breakpoint binds and is hit.

Actual: RunActivity logs Could not connect Jdwp … Process Not Found as a warning and returns success. The app is never resumed. The debug adapter attaches, then ~6.5 s later reports The program 'MyApp.dll' has exited with code 0 (0x0). The breakpoint is never hit.

Reproduction is timing-dependent, so it may need a deliberately slow/loaded emulator host. In our CI it is far from rare: 3 of the last 4 full runs of this leg failed this way, all with the identical warning in the binlog.

Did you find any workaround?

Nothing reliable.

Relaunching helps sometimes — the same commit, same agent image and same emulator flags passed once and failed three times. Our test harness now retries the whole launch up to 6 times over ~38 minutes; even that exhausts all 6 attempts on bad days, and each retry fails the same way (RunActivity emits the same warning every time), so it is a very expensive coin flip rather than a workaround.

Because the build reports success, there is also nothing to key a retry off other than observing that the debug session died on its own.

Relevant log output

# MSBuild binlog: _Run target -> RunActivity task
# (Xamarin.Android.Build.Debugging.Tasks.dll, Microsoft.Android.Sdk.Windows/36.1.69), duration 12.2s

Found device: emulator-5554
  ActivityName: crc649d0a788248bac1c1.MainActivity
  Starting Debugger on 127.0.0.1:52429
Start sdb then run the following command
  connect 127.0.0.1 52429

am start -D -S --user "0" -a "android.intent.action.MAIN" -c "android.intent.category.LAUNCHER" -n "com.companyname.myapp/crc649d0a788248bac1c1.MainActivity"

warning: Could not connect Jdwp. System.Exception: Process Not Found.
   at Xamarin.AndroidTools.Debugging.DebuggingExtensions.ConnectJdwpAsync(AndroidDevice androidDevice, ExecutionConfiguration config, CancellationToken token)
   at Xamarin.AndroidTools.Debugging.DebuggingExtensions.StartWithDebuggingAsync(IAndroidDevice device, ExecutionConfiguration configuration, CancellationToken token)

# ... build completes: exit code 0, 0 errors

# Debug adapter output, three consecutive launches on the same agent:
[16:34:33.005Z] (vsdbg licence banner)
[16:34:39.525Z] The program 'MyApp.dll' has exited with code 0 (0x0).   # 6.52s

[16:44:02.637Z] (vsdbg licence banner)
[16:44:09.494Z] The program 'MyApp.dll' has exited with code 0 (0x0).   # 6.86s

[16:53:24.226Z] (vsdbg licence banner)
[16:53:30.580Z] The program 'MyApp.dll' has exited with code 0 (0x0).   # 6.35s

I have the full MSBuild binlogs from several failing runs. They are from internal CI so I would rather not attach them publicly, but I am happy to share them with the team directly — just say where to send them.