std::thread::spawn aborts when thread::current() is called during DLL_THREAD_ATTACH on Windows

[pengjiaxusz]

std::thread::spawn aborts after thread::current() is called during DLL_THREAD_ATTACH on Windows — is this intentional?

I'm not sure if this is considered a bug or intentional behavior. The crash is rtabort! in set_current(), which means the Rust runtime explicitly chose to abort in this case. However, the trigger is extremely easy to hit accidentally (even a println! during DLL_THREAD_ATTACH), and there's no documentation warning about this, so I wanted to bring it to your attention.

I tried this code

// cdylib loaded via LoadLibrary on Windows
use std::sync::OnceLock;
use windows_sys::Win32::System::SystemServices::{DLL_PROCESS_ATTACH, DLL_THREAD_ATTACH};

static INIT: OnceLock<()> = OnceLock::new();

#[unsafe(no_mangle)]
extern "system" fn DllMain(
    _hinst: *mut core::ffi::c_void,
    reason: u32,
    _reserved: *mut core::ffi::c_void,
) -> i32 {
    match reason {
        DLL_PROCESS_ATTACH => {
            INIT.set(()).ok();
            std::thread::spawn(|| {
                println!("worker thread running");
            });
        }
        DLL_THREAD_ATTACH => {
            // even println! here calls thread::current() and pollutes TLS
            println!(
                "DLL_THREAD_ATTACH on thread {:?}",
                std::thread::current().id()
            );
        }
        _ => {}
    }
    1
}

I expected to see this happen

The worker thread spawned during DLL_PROCESS_ATTACH should run successfully regardless of what happens during DLL_THREAD_ATTACH.

Instead, this happened

The process aborts with:

fatal runtime error: current thread handle already set during thread spawn, aborting

Exit code: 0xC0000409 (STATUS_STACK_BUFFER_OVERRUN)

Root cause analysis

The call chain is:

DLL_THREAD_ATTACH:
  println!("...")
    → std::io::stdout()
      → ReentrantLock::try_lock()
        → std::thread::current()
          → init_current()              // src/std/thread/current.rs
            → CURRENT = Some(handle)    // ← TLS POLLUTED

... later, on the main thread ...

std::thread::spawn(|| { ... })
  → CreateThread → thread_start
    → init.init()
      → set_current(self.handle)
        → if CURRENT.get().is_some() {  // ← DETECTS POLLUTION
            rtabort!(
                "current thread handle already set during thread spawn, aborting"
            )
          }

The issue is in std::sys::thread::current() (specifically init_current()) — it unconditionally sets CURRENT on the calling thread's TLS, regardless of whether that thread is owned by the Rust runtime. When DLL_THREAD_ATTACH fires on a foreign thread (e.g., Vulkan Loader's internal thread), Rust's std pollutes CURRENT on that thread's TLS. Later, when std::thread::spawn creates a new thread, set_current() in the new thread (not the foreign thread) detects CURRENT is already Some and aborts.

Key observation: println!, format!, eprintln!, dbg!, and tracing all eventually call std::io::stdout() / stderr() → ReentrantLock::try_lock() → std::thread::current(). So even seemingly harmless debug output triggers this crash.

Real-world trigger

This reliably occurs when a Rust cdylib is loaded as a Vulkan Layer, because the Vulkan Loader creates internal threads and sends DLL_THREAD_ATTACH notifications to all loaded layers.

Minimal reproduction repository

Complete MRE with 7 test scenarios:

https://github.com/pengjiaxusz/rust-dll-thread-attach-tls-pollution

git clone https://github.com/pengjiaxusz/rust-dll-thread-attach-tls-pollution.git
cd rust-dll-thread-attach-tls-pollution
.\run-all-tests.ps1

The repo includes isolated child-process testing (crashes don't affect the runner) and covers these scenarios:

#	Scenario	Result
1	println! in DLL_THREAD_ATTACH	crash
2	format! + println!	crash
3	eprintln! + dbg!	crash
4	OutputDebugStringW (no Rust std)	safe
5	CreateThread bypasses check	safe
6	Early return guard (zero Rust code)	safe
7	tracing::non_blocking internal spawn	crash

Possible approaches

1. Make init_current() detect foreign threads — check if the current thread is already known to the Rust runtime before setting CURRENT. If it's a foreign thread, don't pollute TLS.
2. Document the hazard prominently — add a warning to Windows-specific platform docs and the DllMain documentation that any Rust std code during DLL_THREAD_ATTACH causes undefined behavior.

Workaround

Add an early return guard at the very top of DllMain:

if reason == DLL_THREAD_ATTACH {
    return 1; // no Rust code executes on this path
}

Meta

rustc --version --verbose:

rustc 1.97.0-nightly (365c0e1d7 2026-05-06)
binary: rustc
commit-hash: 365c0e1d7a614ca94cb48431dcd2bc6d3b645db1
commit-date: 2026-05-06
host: x86_64-pc-windows-msvc
release: 1.97.0-nightly
LLVM version: 22.1.4

Tested on Windows 11 only. This is a Windows-specific issue since DllMain / DLL_THREAD_ATTACH is a Windows concept.

---

Note to reviewers: This issue was drafted with the help of an AI assistant. While I've done my best to verify the core problem myself (the crash is reproducible and the test cases in the linked repo all produce consistent results), the root cause analysis and technical explanations in this post may contain inaccuracies or oversights that I'm not qualified to catch. Please take the diagnosis with a grain of salt, and I'd greatly appreciate any corrections where my understanding falls short.

[joboet]

The issue is in std::sys::thread::current() (specifically init_current()) — it unconditionally sets CURRENT on the calling thread's TLS, regardless of whether that thread is owned by the Rust runtime. When DLL_THREAD_ATTACH fires on a foreign thread (e.g., Vulkan Loader's internal thread), Rust's std pollutes CURRENT on that thread's TLS. Later, when std::thread::spawn creates a new thread, set_current() in the new thread (not the foreign thread) detects CURRENT is already Some and aborts.

That's not quite correct. CURRENT is thread-local, so there can be no cross-thread pollution. The issue is that the thread initialisation logic run on new threads spawned by thread::spawn assumes that it is the first thing run on the thread, and thus CURRENT cannot be initialised. As you correctly point out, a lot of things in std can initialise CURRENT, calling any of them in response to DLL_THREAD_ATTACH will lead to the crash you encountered.

To me, this falls under the category of using std before main; we provide support for that on a best-effort basis. In this case however, fixing the issue seems exceedingly difficult – we need CURRENT to be set to the handle created by spawn (otherwise thread names wouldn't get set), but it's not a good idea to change an existing handle, as thread handles (and especially thread IDs) aren't supposed to change during the lifetime of a thread.

Let's keep this open, perhaps there's a solution I haven't thought of...

[RalfJung]

@pengjiaxusz have you confirmed this "Root cause analysis" yourself, with your own expertise? Or are you just copy-pasting output you got from a tool? These kinds of tools are frequently unreliable, so it is good manners to indicate which part of the issue you confirmed yourself and which part is guesswork by an unreliable 3rd-party source.

[pengjiaxusz]

@pengjiaxusz have you confirmed this "Root cause analysis" yourself, with your own expertise? Or are you just copy-pasting output you got from a tool? These kinds of tools are frequently unreliable, so it is good manners to indicate which part of the issue you confirmed yourself and which part is guesswork by an unreliable 3rd-party source.

@RalfJung I apologize — I should have been upfront about this. Yes, the issue body was drafted with the help of an AI coding assistant. The core problem, however, is real and I confirmed it myself: the crash consistently reproduces, and the reproduction repo I linked contains 7 minimal test DLLs with a one-click script to verify.

To be honest, I am not an experienced programmer and my skill level is quite limited. I spent over 10 hours debugging this crash, searching for answers, but found nothing online — no documentation, no forum discussions, no existing issues covering this scenario. It was a really frustrating and isolating experience. After much hesitation and repeatedly going back and forth, I ultimately decided to use an AI tool to help draft and submit this issue, because on my own I simply didn't have the expertise to properly explain the mechanism or present it in an acceptable format.

The reason I pushed myself to file this despite everything is that I kept thinking: if I struggled this much, someone else out there might hit the exact same wall someday. I don't want the next person who runs into a println! crash in their DllMain to spend 10 hours wondering if they're going crazy. Even if this issue just sits here as a searchable record that says "this happens, here's why, here's the workaround" — that alone would have saved me so much pain, and I hope it can do the same for others.

I realize using AI to draft the issue without disclosure was not the right approach. I'll be more careful about this going forward. Thanks for your understanding.

[RalfJung]

It's entirely okay to file an issue saying "this crashes and it shouldn't but I don't know why". There'll be people here who can help figure out the details. :)

[pengjiaxusz]

@RalfJung Thank you, that's really kind of you to say. I was a bit nervous about how this would be received, so that means a lot.
I really appreciate the welcoming attitude, and I'll keep your advice in mind next time. :)