[Windows] Drop the torch/lib DLL preload glob - #202206

* Add pathfinder support for cupti64_2026.1.2.dll (CTK 13.2.2)

nvidia-cuda-cupti 13.2.86 (CUDA 13.2.2) ships cupti64_2026.1.2.dll on
Windows, which the cupti descriptor does not list, so
load_nvidia_dynamic_lib("cupti") fails on a machine that only has the
13.2 wheels installed.

Found via the PyTorch cu132 Windows nightly, which loads the CUDA wheel
libraries through cuda-pathfinder at import time
(pytorch/pytorch#202206).

Signed-off-by: Klaus Zimmermann <[email protected]>

* docs(pathfinder): prepare 1.8.5 release notes

Signed-off-by: Ralf W. Grosse-Kunstleve <[email protected]>

---------

Signed-off-by: Klaus Zimmermann <[email protected]>
Signed-off-by: Ralf W. Grosse-Kunstleve <[email protected]>
Co-authored-by: Ralf W. Grosse-Kunstleve <[email protected]>

## Linked issue or supporting maintainer

Part of pytorch#199894. Supersedes pytorch#200856 and pytorch#199925: without the preload there is no list of test-only DLLs to maintain.

## BC-breaking?

No for the supported configurations. `import torch` no longer preloads every DLL in `torch/lib`; libraries that are loaded on demand are now loaded only on demand, and the `PATH` fallback for systems without `AddDllDirectory` (pre Windows 8 without KB2533623) is gone.

## Summary (human written only)

On Windows we are preloading all libraries in torch/lib. This is somewhat costly and leads to occasional problems. Furthermore, it is likely no longer necessary because the loading code has become smarter and is now able to load dependencies on demand. This PR is here to test that hypothesis in CI.

## Agent details (if applicable)

Analysis and change prepared with Claude Code, reviewed by me. The commit message carries the full reasoning. Agent notes:

The Windows loader has preloaded every DLL in `torch/lib` since pytorch#35362, because `caffe2_nvrtc.dll` was loaded by name from `CUDAHooks.cpp` and plain `LoadLibraryW` did not search directories registered with `AddDllDirectory`. Two later changes made that moot: pytorch#45674 (2020-10) switched CUDA builds to the in-tree LazyNVRTC, so `caffe2_nvrtc.dll` is only loaded by name on ROCm, and pytorch#49781 (2021-01) moved `at::DynamicLibrary` to `LoadLibraryExW` with `LOAD_LIBRARY_SEARCH_DEFAULT_DIRS`, which searches what `os.add_dll_directory` registers. Meanwhile the preload keeps turning on-demand libraries into import-time failures (pytorch#199894, pytorch#179024, pytorch#182123). The glob only ever preloaded torch's own DLLs with the default search flags; the NVIDIA wheel directories come from the cuda-pathfinder loop (and, on CI, from the toolkit bin dir fallback), which this PR does not touch.

Tested on hardware, since trunk has had no Windows CUDA test shards since pytorch#139336: Windows 11 VM with an RTX 2060 (driver 610.88), 2026-10-26 cu132 nightly wheel, `torch/__init__.py` replaced by this PR's version (hash-checked against the base commit). Results:

- With the stock cuda-pathfinder 1.8.4 the import fails on a clean machine with and without this change, for a reason outside this PR (below). The failure point moves from a `WinError 126` on `shm.dll` in the glob to "DLL load failed while importing _C".
- With a per-library `try` in the pathfinder loop (not part of this PR), import, `torch.cuda.is_available()`, cuDNN conv2d, cuBLAS matmul, cuFFT, cuRAND, cuSOLVER and a jiterator kernel (NVRTC) all pass with the glob removed. 8 of 13 `torch/lib` DLLs are resident afterwards; `caffe2_nvrtc`, `torch_global_deps`, `nvToolsExt64_1`, `libiompstubs5md` and `torch.dll` were never needed.
- The pytorch#199894 mechanism reproduces: a broken stray `zz_broken_test.dll` in `torch/lib` aborts `import torch` with the glob (WinError 193) and is ignored without it.

Found on the way, independent of this PR: the stock cu132 Windows nightly does not import on a clean machine. `nvidia-cuda-cupti` 13.2.86 ships `cupti64_2026.1.2.dll`, which cuda-pathfinder 1.8.4 does not know; the pathfinder loop in `torch/__init__.py` is one `try` around all eleven libraries, so the CUPTI miss also skips cuDNN, `nvidia\cudnn\bin` is never registered, and `cudnn64_9.dll` (a static import of `torch_python.dll` and `torch_cuda.dll`) cannot be found. CUPTI itself still resolves, because a later library in the loop registers the shared `nvidia\cu13\bin` directory. CI does not see this: the Windows CUDA wheel smoke test runs on a T4 with the CUDA toolkit and cuDNN installed under Program Files, and `torch/__init__.py` adds that directory to the search path. A per-library `try` fixes the import with a warning; a pathfinder release that knows the name fixes it silently.

CI on this PR: the full CPU suite on the 12 `win-vs2022-cpu-py3` shards, the `win-vs2022-cuda13.2-py3` build, and the `binaries_wheel` smoke tests for every Python version (CUDA wheels on a T4: import, CUDA tensor, magma, cuDNN, RNN and CNN smoke; XPU wheels import on CPU runners). Not covered: the full CUDA test suite on Windows.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Pull Request resolved: pytorch#202206
Approved by: https://github.com/atalman

#38)

cuDNN tests on the WoA shards crash at import/first use with
"Invalid handle. Cannot load symbol cudnnGetVersion" (exit 0xC0000409).

Root cause: the torch wheel bundles cudnn64_9.dll plus its sub-libraries
(cudnn_graph64_9.dll, cudnn_ops64_9.dll, ...) in torch\lib. cudnn64_9.dll
loads the sub-libraries lazily by bare name. pytorch/pytorch#202206 removed
the Windows preload of torch\lib\*.dll that used to make them resident, so
the lookup now searches PATH only. With no cuDNN on PATH the load fails
(the CI failure); with another cuDNN on PATH the wrong version is picked
(reproduced locally: front DLL 9.27 from torch\lib, cudnn_graph64_9.dll
9.25 from PATH -> "compiled against 9.27 but found runtime 9.25").
Preloading torch\lib\cudnn*.dll by full path fixed both cases locally.

Fix: after the venv is activated, resolve torch's package directory from
the active interpreter (find_spec, no import) and prepend its lib dir to
PATH before run_test.py starts. This works for any venv or conda env, not
only C:\ci\woa\scratch\venv. A PATH prepend is the smallest change; the
alternatives (SetDllDirectory, a lazy C++ preload, cuDNN pip wheels) need
changes in torch itself and are better done upstream.

Test Plan:
  Parsed both scripts with the PowerShell AST parser (0 errors).
  Exercised Add-TorchLibToPath against a stub torch package on PYTHONPATH:
  it returned <stub>\torch\lib and put it first on PATH.
  Not yet run on a WoA runner; verify with a test shard that the cuDNN
  tests (e.g. test_cpp_api_parity, test_cuda) no longer crash.

Authored with an AI assistant (Claude Code); reviewed by the committer.

Co-authored-by: nkhasbag <[email protected]>
Co-authored-by: Claude Sonnet 5.5 <[email protected]>

## Linked issue or supporting maintainer

Fixes #203660
Fixes: #203725

## Summary (human written only)

Since #202206 removed the preload of every DLL in torch\lib, Windows wheels that bundle cuDNN crash on first cuDNN use when no cuDNN is on PATH with error Invalid handle. Cannot load symbol cudnnGetVersion and the process exits with 0xC0000409.

This hit every CUDA test shard of NVIDIA's [Windows on Arm CI](https://github.com/NVIDIA/pytorch-windows-ci/actions/runs/41810565607/job/126556054590#step:20:181).

Windows x86 CI did not run into this failure because those workflows follow upstream and prepend $PATH with cuda and cudnn path. This is ok for CI workflows but should not become a requirement for developers when using torch wheels.

This PR restores a cuDNN-only preload without bringing back #199894

## Agent details (if applicable)

> Drafted with Claude Code; I reviewed the change and ran the tests below.
>
> **Change:** at the end of `_load_dll_libraries()`, `LoadLibraryExW` each `torch\lib\cudnn*.dll` by full path with `LOAD_LIBRARY_SEARCH_DEFAULT_DIRS | LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR` (the flags the pre-#202206 loop used). A failed load emits a warning instead of raising.
>
> **Why no unit test:** the failure depends on process-wide DLL state and on PATH contents at process start; a meaningful test needs a fresh Windows process with cuDNN removed from PATH and a wheel that bundles cuDNN. Verified manually on Windows on Arm:
>
> ```
> where.exe cudnn64_9.dll   # not found
> python -c "import torch,torch.nn as nn; x=torch.randn(1,3,8,8,device='cuda'); print(nn.Conv2d(3,4,3).cuda()(x).shape)"
> ```
>
> - Before: `Invalid handle. Cannot load symbol cudnnGetVersion`, exit -1073740791
> - After: `torch.Size([1, 4, 6, 6])`, `torch.backends.cudnn.version() == 92600`, all 10 `cudnn*.dll` loaded from `torch\lib`; Conv2d+BatchNorm2d, 2-layer LSTM, and SDPA (`CUDNN_ATTENTION`) forward/backward pass, no preload warnings.
>

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Pull Request resolved: #203663
Approved by: https://github.com/atalman

Co-authored-by: Claude Opus 5.5 <[email protected]>

## Linked issue or supporting maintainer

Part of pytorch#199894. Supersedes pytorch#200856 and pytorch#199925: without the preload there is no list of test-only DLLs to maintain.

## BC-breaking?

No for the supported configurations. `import torch` no longer preloads every DLL in `torch/lib`; libraries that are loaded on demand are now loaded only on demand, and the `PATH` fallback for systems without `AddDllDirectory` (pre Windows 8 without KB2533623) is gone.

## Summary (human written only)

On Windows we are preloading all libraries in torch/lib. This is somewhat costly and leads to occasional problems. Furthermore, it is likely no longer necessary because the loading code has become smarter and is now able to load dependencies on demand. This PR is here to test that hypothesis in CI.

## Agent details (if applicable)

Analysis and change prepared with Claude Code, reviewed by me. The commit message carries the full reasoning. Agent notes:

The Windows loader has preloaded every DLL in `torch/lib` since pytorch#35362, because `caffe2_nvrtc.dll` was loaded by name from `CUDAHooks.cpp` and plain `LoadLibraryW` did not search directories registered with `AddDllDirectory`. Two later changes made that moot: pytorch#45674 (2020-10) switched CUDA builds to the in-tree LazyNVRTC, so `caffe2_nvrtc.dll` is only loaded by name on ROCm, and pytorch#49781 (2021-01) moved `at::DynamicLibrary` to `LoadLibraryExW` with `LOAD_LIBRARY_SEARCH_DEFAULT_DIRS`, which searches what `os.add_dll_directory` registers. Meanwhile the preload keeps turning on-demand libraries into import-time failures (pytorch#199894, pytorch#179024, pytorch#182123). The glob only ever preloaded torch's own DLLs with the default search flags; the NVIDIA wheel directories come from the cuda-pathfinder loop (and, on CI, from the toolkit bin dir fallback), which this PR does not touch.

Tested on hardware, since trunk has had no Windows CUDA test shards since pytorch#139336: Windows 11 VM with an RTX 2060 (driver 610.88), 2026-10-26 cu132 nightly wheel, `torch/__init__.py` replaced by this PR's version (hash-checked against the base commit). Results:

- With the stock cuda-pathfinder 1.8.4 the import fails on a clean machine with and without this change, for a reason outside this PR (below). The failure point moves from a `WinError 126` on `shm.dll` in the glob to "DLL load failed while importing _C".
- With a per-library `try` in the pathfinder loop (not part of this PR), import, `torch.cuda.is_available()`, cuDNN conv2d, cuBLAS matmul, cuFFT, cuRAND, cuSOLVER and a jiterator kernel (NVRTC) all pass with the glob removed. 8 of 13 `torch/lib` DLLs are resident afterwards; `caffe2_nvrtc`, `torch_global_deps`, `nvToolsExt64_1`, `libiompstubs5md` and `torch.dll` were never needed.
- The pytorch#199894 mechanism reproduces: a broken stray `zz_broken_test.dll` in `torch/lib` aborts `import torch` with the glob (WinError 193) and is ignored without it.

Found on the way, independent of this PR: the stock cu132 Windows nightly does not import on a clean machine. `nvidia-cuda-cupti` 13.2.86 ships `cupti64_2026.1.2.dll`, which cuda-pathfinder 1.8.4 does not know; the pathfinder loop in `torch/__init__.py` is one `try` around all eleven libraries, so the CUPTI miss also skips cuDNN, `nvidia\cudnn\bin` is never registered, and `cudnn64_9.dll` (a static import of `torch_python.dll` and `torch_cuda.dll`) cannot be found. CUPTI itself still resolves, because a later library in the loop registers the shared `nvidia\cu13\bin` directory. CI does not see this: the Windows CUDA wheel smoke test runs on a T4 with the CUDA toolkit and cuDNN installed under Program Files, and `torch/__init__.py` adds that directory to the search path. A per-library `try` fixes the import with a warning; a pathfinder release that knows the name fixes it silently.

CI on this PR: the full CPU suite on the 12 `win-vs2022-cpu-py3` shards, the `win-vs2022-cuda13.2-py3` build, and the `binaries_wheel` smoke tests for every Python version (CUDA wheels on a T4: import, CUDA tensor, magma, cuDNN, RNN and CNN smoke; XPU wheels import on CPU runners). Not covered: the full CUDA test suite on Windows.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Pull Request resolved: pytorch#202206
Approved by: https://github.com/atalman

## Linked issue or supporting maintainer

Fixes pytorch#203660
Fixes: pytorch#203725

## Summary (human written only)

Since pytorch#202206 removed the preload of every DLL in torch\lib, Windows wheels that bundle cuDNN crash on first cuDNN use when no cuDNN is on PATH with error Invalid handle. Cannot load symbol cudnnGetVersion and the process exits with 0xC0000409.

This hit every CUDA test shard of NVIDIA's [Windows on Arm CI](https://github.com/NVIDIA/pytorch-windows-ci/actions/runs/41810565607/job/126556054590#step:20:181).

Windows x86 CI did not run into this failure because those workflows follow upstream and prepend $PATH with cuda and cudnn path. This is ok for CI workflows but should not become a requirement for developers when using torch wheels.

This PR restores a cuDNN-only preload without bringing back pytorch#199894

## Agent details (if applicable)

> Drafted with Claude Code; I reviewed the change and ran the tests below.
>
> **Change:** at the end of `_load_dll_libraries()`, `LoadLibraryExW` each `torch\lib\cudnn*.dll` by full path with `LOAD_LIBRARY_SEARCH_DEFAULT_DIRS | LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR` (the flags the pre-pytorch#202206 loop used). A failed load emits a warning instead of raising.
>
> **Why no unit test:** the failure depends on process-wide DLL state and on PATH contents at process start; a meaningful test needs a fresh Windows process with cuDNN removed from PATH and a wheel that bundles cuDNN. Verified manually on Windows on Arm:
>
> ```
> where.exe cudnn64_9.dll   # not found
> python -c "import torch,torch.nn as nn; x=torch.randn(1,3,8,8,device='cuda'); print(nn.Conv2d(3,4,3).cuda()(x).shape)"
> ```
>
> - Before: `Invalid handle. Cannot load symbol cudnnGetVersion`, exit -1073740791
> - After: `torch.Size([1, 4, 6, 6])`, `torch.backends.cudnn.version() == 92600`, all 10 `cudnn*.dll` loaded from `torch\lib`; Conv2d+BatchNorm2d, 2-layer LSTM, and SDPA (`CUDNN_ATTENTION`) forward/backward pass, no preload warnings.
>

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Pull Request resolved: pytorch#203663
Approved by: https://github.com/atalman

Co-authored-by: Claude Opus 5.5 <[email protected]>