I've run into a memory leak in NI-DAQmx and wanted to report it in case it's useful.
Setup
- NI-DAQmx version: 26.3.1
- OS: Windows 11 (64-bit)
- Hardware: reproduces on several multifunction USB devices (e.g. USB-6008, USB-6000, USB-6421, USB-6423)
What I'm doing
I'm working on a small data-logging project where I continuously acquire analog input, and my app repeatedly starts and stops acquisition over a long session. To narrow it down I reduced it to a minimal
loop:
1. Create a task
2. Add an analog input voltage channel
3. Configure sample clock timing (continuous samples)
4. Register an EveryNSamplesEvent callback (DAQmxRegisterEveryNSamplesEvent, Acquired Into Buffer)
5. Start the task
6. Let it run briefly
7. Stop the task
8. Deregister the callback (register with NULL)
9. Clear the task
Repeating this loop, the process memory grows by a small, fixed amount on every iteration — a steady linear climb, not a one-time bump. Over a long-running session this adds up.
Where it seems to come from
Profiling the allocations, the leaked blocks trace back into the driver during task teardown — specifically the destruction of the every-N-samples event handling (an internal
EveryNSamplesEventSupervisor-type object). The allocation originates inside the driver DLLs (nidmxfu.dll / nipalu.dll) on the path from DAQmxClearTask → event supervisor destructor. It looks like the
teardown allocates a small block (~80 bytes) that's never freed.
Notes
- The growth is perfectly linear with iteration count, which is what made me confident it's a genuine leak rather than caching or noise.
- It only occurs when an EveryNSamplesEvent callback has been registered; loops without the callback don't show it.
- Each leaked block is small, but for an app that starts/stops acquisition continuously it accumulates over time.
