What does Windows error code 159 (ERROR_BAD_THREADID_ADDR) mean?

 
Could be also:
ConstantTypeOS
DRIVER_POWER_STATE_FAILUREBugCheck CodeWindows
Previous Next
ERROR_NOT_LOCKED ERROR_BAD_ARGUMENTS

ERROR_BAD_THREADID_ADDR

What ERROR_BAD_THREADID_ADDR means

The address supplied for receiving or referencing a thread identifier is invalid. The status points to a bad memory contract around a thread-ID parameter. In legacy APIs the caller may provide a pointer where the runtime writes an identifier; an invalid, misaligned, read-only, or incorrectly sized address causes this result.

Common causes

  • A null or dangling pointer is passed for the thread ID
  • The buffer is read-only or belongs to an unloaded module
  • 32-bit and 64-bit code disagree on field size
  • The address is valid initially but another thread frees it too early

How to investigate

  1. Log the pointer value, buffer size, and owning allocation
  2. Enable page heap or memory diagnostics on the producing process
  3. Check ABI declarations and calling convention
  4. Reduce asynchronous lifetime so the output buffer remains valid through completion

Developer guidance

Use the exact declared type for thread identifiers and keep output storage alive for the entire call. Do not cast integer storage or packed network fields into pointer parameters.

Administrator and support guidance

This is generally an application defect. Preserve a crash dump or verifier report rather than attempting system-wide thread configuration changes.

How this code differs from related results

The code concerns the address of the thread-ID storage, not whether the referenced thread itself exists.

Evidence worth collecting

For ERROR_BAD_THREADID_ADDR, begin the trace at the operation where a null or dangling pointer is passed for the thread ID. Preserve the exact API boundary, numeric result, process and thread identifiers, relevant object state, and the component version. The first verification point should be to log the pointer value, buffer size, and owning allocation. This evidence distinguishes the specific this result contract from a later secondary failure.

Recovery and verification

Recovery for it should address the observed condition rather than merely retrying the same call. After the change, reproduce the scenario in which a null or dangling pointer is passed for the thread ID, then confirm that the intended operation completes and that cleanup returns all associated resources. Also verify that the next repeated operation follows the same successful path without increasing the resource class implicated by this result.

When to escalate

Escalate this result with a minimal reproduction focused on the failing synchronization boundary. Include the operating-system build, binary architecture, runtime or compatibility-layer version, the exact input values, and a timestamped trace showing a null or dangling pointer is passed for the thread ID. For the result escalation record, note whether changing concurrency, object lifetime, target process, module set, or endpoint location alters the result.

References


Looking for a different code? Search another status or error code.