Kernel exits silently when certain custom formatters run #4031
Description
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). UsingDebugger.Launchappears unsafe in this context.
- This instantly crashes
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
- What’s the recommended way to debug a .NET Interactive extension, especially formatter code, in the C# kernel?
- Is
System.Diagnostics.Debugger.Launch()known to be problematic in the host/kernel context? If so, what’s the recommended alternative? - 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 crashUnit 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?