[Zhipeng Wang (timenick)]

Summary

winml perf on a .gguf file finishes every request and writes its report, then the process exits with 0xC0000409 when Windows ML puts the Task's GPU target on an Intel iGPU. On an RTX 5090 D desktop with Intel Graphics this happened on every run with windowsml 2.8.183.dev0, and also with 2.7.2021a0. A caller that checks the exit code sees a failed benchmark.

WinMLLlamaSession.close() and WinMLCGCSession.close() now run the cycle collector after closing their handles, so the Windows ML interfaces are released while COM is still initialized.

Cause

• windowsml wraps each COM interface with ctypes.cast(out, POINTER(interface)), which records the pointer in its own _objects. The pointer stays in that reference cycle after its wrapper closes, so the interface is released only when the cycle collector runs. After a run, gc.garbage holds the IWinMLRuntime, IWinMLExecutionTarget, IWinMLPipeline, IWinMLStage, IWinMLTokenizer and IWinMLTextGenerationConfiguration pointers.
• At exit comtypes uninitializes COM and then no longer releases interfaces, so the native objects live on until the process unloads its DLLs.
• WinMLRuntimeCore.dll then destroys its D3D12 transfer pools from DllMain (dllmain_crt_process_detach → CD3D12TransferPool::~CD3D12TransferPool) and releases command lists and queues in a GPU driver that has already unloaded. In igd12um64xeh.dll that is an access violation, which the driver turns into __fastfail (0xC0000409). With the target on the NVIDIA GPU the same use-after-free happens in nvwgf2umx.dll, but it crashes only under a debugger.
• The llama.cpp route's target lands on the iGPU because _create_target asks for ExecutionTargetKind.GPU with ExecutionTargetPreference.DEFAULT; llama.cpp itself runs on CUDA device 0.

The teardown order is a Windows ML bug. This change keeps winml-cli from leaving its objects to it.

Change

• session/task_generation.py: _release_closed_interfaces() runs gc.collect() and documents why.
• WinMLLlamaSession.close() and WinMLCGCSession.close() call it after closing their handles.
• Tests: hold_cyclic_interface gives a fake handle an interface in a reference cycle, as ctypes.cast leaves one. With automatic collection disabled, both sessions' close() now free it; both tests fail without the change.

Results on an RTX 5090 D with Intel Graphics (windowsml 2.8.183.dev0)

winml perf -m Qwen3-0.6B-Q4_0.gguf --device gpu --max-new-tokens 16 --warmup 1 --iterations 1:

winml-cli	Exit code
main before this change (8e2dfb8)	0xC0000409 on every run
This change	0 on 3 of 3 runs

Follow-ups (not in this PR)

• The llama.cpp route could ask for ExecutionTargetPreference.PERFORMANCE, as the CGC route already picks the high-performance GPU, so Windows ML does not create a D3D12 device on an iGPU that llama.cpp does not use.

🤖 Generated with Claude Code

[Qiong Wu (qiowu) (DingmaomaoBJTU)]

Reviewed the teardown change and both session close paths. Collection runs after wrapper handles are closed and cleared, outside generation timing; the shared helper adds no native import dependency. No blocking findings. Local validation: 137 tests passed across CGC session, llama session, and shared Task generation. Also disabled the new helper in-memory and confirmed both new regression tests fail, demonstrating that they exercise the intended cleanup behavior. The reported Intel/NVIDIA native shutdown crash was not reproduced locally. CI lint and completed test jobs pass; some remaining tests/CodeQL were still running at review time and should finish successfully before merging.