Kernel exits silently when certain custom formatters run

[profix898]

Summary

I’m developing a .NET Interactive extension with multiple custom formatters. Most work fine, but a few cause the C# kernel process to terminate silently. In Process Explorer I can see the kernel process disappear with no obvious exception or post-mortem dump. I’m looking for guidance on best practices to debug formatter/extension code and whether this silent exit indicates a bug or a known limitation.

Version: microsoft.dotnet-interactive 1.0.632301 (latest as of 2025/09/05)

What happens

• When specific formatter code is exercised, the Interactive C# kernel (child process) exits abruptly.
• No error is surfaced in the notebook UI at the moment of the crash.
• After the crash, executing any subsequent cell fails until I restart the kernel (confirming the kernel has died).
• In Process Explorer, the kernel process vanishes without an obvious exception or post-mortem.

What I tried

• Placing System.Diagnostics.Debugger.Launch(); immediately before the suspected lines inside a notebook cell.
  • This instantly crashes Microsoft.DotNet.Interactive.App.dll (I do get a post-mortem for the host app). Using Debugger.Launch appears unsafe in this context.

Expected behavior

A reliable way to attach a debugger to the kernel process to step through extension/formatter code, or diagnostics surfaced (exception/log) instead of a silent kernel exit.

Questions

1. What’s the recommended way to debug a .NET Interactive extension, especially formatter code, in the C# kernel?
2. Is System.Diagnostics.Debugger.Launch() known to be problematic in the host/kernel context? If so, what’s the recommended alternative?
3. Any recommended logging hooks (enabling verbose logging, capturing kernel logs) for extensions to diagnose formatter failures?

Bonus / additional observation

I wrote a simple unit test that initializes a kernel and calls the formatter directly, and it works fine:

// xUnit/NUnit style test running inside VS
var kernel = new CompositeKernel { new CSharpKernel() };
MyKernelExtension.Load(kernel);

var obj = new CustomObject();
var html = a.ToDisplayString(HtmlFormatter.MimeType); // formatted output, no crash

Unit test via CompositeKernel + (direct) formatter invocation succeeds, which points to a difference between test and notebook hosting. This suggests the issue might depend on the interactive host/runtime environment (e.g., hosting model, process boundaries, pipes/stdio, or how results are projected back to the notebook) rather than the formatter implementation itself? Is this even the correct way of 'testing' a formatter in a unit test?

[homeoffice2028rjx-gif]

名称: Lingma - Alibaba Cloud AI Coding Assistant
ID: Alibaba-Cloud.tongyi-lingma
说明: Type Less, Code More
版本: 2.5.17
发布者: Alibaba-Cloud
VS Marketplace 链接: https://marketplace.visualstudio.com/items?itemName=Alibaba-Cloud.tongyi-lingma

[jonsequitur]

Debugger.Launch() is typically how I debug the kernel and I've never seen it crash. Also, I usually just unit test formatters.

The most significant differences between running a kernel in a unit test versus in the host environment is that the notebook is out of process from the kernel. I don't think this would cause a crash either though. As an alternative that could potentially isolate this problem, you might try running your extension using dotnet-repl and see if it repros there.

There are instructions here for turning on verbose logging: https://github.com/dotnet/interactive/blob/main/DEVELOPER-GUIDE.md#use-a-local-build-of-the-dotnet-interactive-tool